The JNode team has released version 0.2.3 of the JNode operating system. JNode is an open source [LGPL] operating system written completely in Java (with a very small assembler nano-kernel). New features and improvements in this release are many classpath patches, improvements in AWT, Swing and desktop support, various bugfixes in the JIT compiler, ISO9660 support, better support for testing JNode with Mauve (mauve plugins, invoker commands), and more. Screenshots are available.
Pretty interesting project. However, the font rendering blows big time.
Somehow, I doubt that is a high priority for them…
i wonder if apache’s harmony project and Jnode will do much knowledge swapping like it apears jnode does with classpath. this has the potential to be something rather good. though it suprises me they didnt take a very small kernel like NewOS and jsut build and entire jova susystem and user system around it instead of (from what i understand) using have as the low level language to interact with the hardware. or am i mistaken?
Harmony is currently a joke. It’s no where near as complete at gjc + classpath. I doubt there is much they can get from it.
The screenshots surprised me a little, I always thought JNode was some commercial OS filling a particular niche, and yet the screenshots looked like they were from a hobby OS. So I checked the site and it’s described as a simple to use Java operating system for personal use. Maybe I was confusing it with JBoss.
Anyway, this looks neat. Too bad it didn’t come sooner when I was looking for a Java based OS. I wonder what might come of this and whether it might rekindle my interest in Java. I’d be really sweet if this ran Java with Swing at a good speed.
And yeah, the font rendering isn’t very pretty yet; but there aught to be plenty of time to fix that later on when the more important parts of the OS are build right? I’m hoping for better fonts and a better theme than the metal theme the screenshots are sporting.
What would be the advantages of a java-based OS? A really quick java runtime environment? But wouldn’t the OS itself run slowly? I guess I’m confused as how to even get this running, since I didn’t think there were any Java compliers for a real machine language. And if it is just an OS written in java, compiled for a certian architecture, wouldn’t C++ be better for the job? I can’t find answers to any of this on the site (in a form I understand, at least).
As I understand it, the OS consists of a very small kernal compiled natively for the system that provides a vm and interfaces for drivers and userspace code written in java.
A couple of advantages to this could be
* Portability – port the native part of the kernel and all the userspace will run without even re-compiling.
* Consistancy – all your applications are written in the same language and use the same GUI toolkits etc.
While it would not suit all applications, those developing for and in a solely java environment could find it very useful.
And it looks like a really cool toy, too :]
The assembler nanokernel is mostly an entry point for interrupt handlers and also provides for initialisation (page tables etc) before the JVM is started during system boot.
Portability is an advantage if you have a JIT for the target architecure in the JNode JVM. Writting an efficient JIT requires an enormous effort, probably more than what is needed to port an OS like NetBSD to a new architecture.
The real advantage of Jnode is the possibility it presents to perform optimisations across the memory barrier and to finally get rid off the kernel space/user space seperation plagguing OS research since 1950.
There have been native Java compilers for years. The earliest I can remember is Symantec’s “Visual Café for Java” which was pulling off that particular trick in the late ninties. These days GCJ can compile to native code on all platforms supported by GCC (including Windows). Classpath hasn’t got stable Swing support yet, but you can use other toolkits like SWT, Qt or GTK.
As for writing an OS, most of what an OS does is reasonably high-level (if very complex): memory management, disk management, scheduling, network stacks, etc., can all be written in as high-level a language as you like. You only need the low-level stuff for initial bootstrapping and then to provide an interface to the hardware.
What would be the advantages of a java-based OS?
A few things come to mind:
You don’t need memory protection – everything can work in kernel space – there is much less overhead when switching between processes in multitasking, or when calling the kernel.
You can pass objects and ownership of objects between applications/kernel/drivers. This way there’s much less data copying.
Security – each applications, kernel module or driver works in it’s own sandbox. This is similar to microkernels without the overhead of costly context switches.
With a modern JIT compiler java code can be nearly as fast as native code.
P.S. This is purely theoretical, I am not familiar with JNode
Edited 2006-03-02 08:20
Memory Protection and other features that teorically decrease the overhead, really decrease it?
You don´t need memory protection, but the overhead of it is embedded in the JVM?
Pass an object has a overhead cost too! or not?
> Memory Protection and other features that teorically
> decrease the overhead, really decrease it?
>
> You don´t need memory protection, but the overhead of
> it is embedded in the JVM?
>
> Pass an object has a overhead cost too! or not?
Ehm, did you mean *increase* the overhead? Memory protection comes at a cost which can be avoided in “safe” languages, in terms of chip area (not that much since you’d want paging anyway for swapping), and more importantly context switching overhead. JNode doesn’t have to context-switch for “syscalls”, which are equal to function calls (how much this actually saves is unclear to me, since the main overhead of context switching comes from invalidated caches, which can occur here too).
On the other hand, Java adds other costs, like array-bounds checking and null-pointer checking. A good compiler can optimize lots of these away, but not all. In the end, one has to look at practical examples to see how heavy the different factors are.
I don’t think that JNode is the end of the road, but rather a proof of concept and a very practical implementation (since Java is so widespread). The next step are probably specification languages and formal verification, which can help avoiding bugs and make optimization easier (the above mentioned optimization of array bounds checking and null pointer checking are based on internally done verification, but without hints from the programmer this is a hard task). Another question which will be answered then is whether Java is a “good” language in the sense of easy verification.
I thought it was written in java ? Doesn’t this defeat the sole purpose of security ?
> I thought it was written in java ? Doesn’t this defeat
> the sole purpose of security ?
There are always inner parts of an OS which are “trusted”. If they were not written in assembler, they’d be written in Java with access to fake-native functions of the same power. Anyway, a bug in these functions can easily bring down the whole system. The key point is that such a trusted inner core cannot be avoided, but it can be kept small, be thoroughly tested, and most important, be non-extensible. It is usually the extensions to such inner core modules which cause problems, because they are less tested. See device drivers in Windows and Linux for example. In JNode, this inner core is kept so small that any drivers, OS extensions, and the like, live outside (bytecode compiler too, IIRC, at least it is possible). The only reason to extend this core are core features like SMP support, and that means it is or will soon be bug free.