JNode has released a new intermediate version of JNode reflecting the current state of development. This release contains USB support, TCP support, various filesystems improvements, initial GUI toolkit,
significant performance improvements and lots of bug-fixes.
JNode 0.1.5 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
this projuect is really picking up steam. i think they are doing great work and i can’t wait till the gui is more developed.
One interesting thing about JNode is that it apparently does not use the system’s MMU hardware for protection. Instead, it uses the fact that Java programs are automatically memory-safe. This is a very cool and allows for some powerful features:
1) Very low-overhead, fine-grained sharing. Current systems can share memory between domains at the page-level. However, a lot of code and data structures are necessary to support this sharing, which makes the VM very complex and requires significant amounts of memory. Using a safe language, you can enable sharing at the level of individual objects, while still remaining fully protected from errant processes. The VM becomes an order of magnitude less complex as well.
2) Very low-overhead system calls. Processing a system call on a Pentium 4 requires hundreds of clock cycles. A regular function call requires less than a dozen cycles, and zero cycles if it is a simple function that can be inlined (like getpid()). Using a safe language, there no longer needs to be a seperation between kernel memory space and user memory space, so system calls can become as cheap as a regular function call.
3) It allows the advantages of OS servers without the overhead. Consider a GUI system. You’ve got two options: you can either put it into the kernel, or implement it as a seperate server. You have to make this seperation because otherwise applications could corrupt the internal data structures of the GUI system. If you put it into the kernel, you open yourself up to instability, and have to deal with the hundreds of clock cycles overhead for system calls. If you put it into a server, you have to deal with the overhead of IPC (typically twice or thrice that of a system call). Using a safe language, you can implement the GUI (indeed, the entire OS) as a library. Applications can call the library with only the overhead of a function call, yet they can’t corrupt the internal data structures of the GUI system. Indeed, you can apply this logic to the entire system, constructing “servers” as lightweight threads communicating via shared objects. Unlike with the heavyweight servers found in microkernels, the IPC overhead would be very minimal, basically just copying pointers-to-objects to a message queue.
The performance overhead of using a safe language depends on the language and the type of code you write with it. Really, the only fixed overhead for a safe language is range-checking, type-checking, and some sort of automatic memory management (region inference or garbage collection). With advanced compilers, most of the checks get optimized away, so you get code that will perform 80-90% as good as well-written C. On the other hand, calls into the OS become an order of magnitude cheaper, and sharing becomes essentially free, so you’re likely to see a net performance *gain* from using a safe language. The BRiX project really seems to get this concept. They’re using a compiled safe language called Crush. Crush is a very interesting language because it draws a lot of concepts from Lisp (dynamic typing with optional type declarations, lambdas, multimethods, garbage collection, and a lot of the terminology) and other high-level features such as constraints into a language that is also suitable for low-level programming. They tout a net performance improvement and reduction of bloat as one of the advantages of using a theoretically slower and more bloated language!
It is good to see new OSs like JNode (not distributions of Linux)! Hope that 2004 will be a nice year for the people who like to see more OSs.
I wish you a happy new year!
That looks really, really cool. I’ve often thought about how clean an OS design would be if everything was written in a garbage collected language.
However, I have to question the wisdom of using Java for that language. It’s pretty good, don’t get me wrong, but Java has some flaws as a language. When GNU set out to build a great OS, they extended C. Why not do the same for Java? As they are clearly having to write their own JVM and maybe compilers (I can’t really tell), why not improve the language at the same time? Things I’d want to nail are:
* Lack of properties in the language. Their coding styles say “no public instance variables”. That’s so evil. I really really hate classes that are 99% getter/setter methods. What you want is like in D:
class Foo {
private:
int _a;
public:
int a() { return _a; }
int a(int value) { return _a = value; }
}
Foo f = new Foo();
f.a = 5;
print(f.a);
http://digitalmars.com/d/property.html
That way you start with instance variables (clean) and IF you find later you need a getter/setter, you can add it without changing the source.
* Really overengineered class libraries. Take inspiration from POSIX, not the Java class library. Short method names, a layered design. Don’t make me write 8 lines of code when what I really wanted could have been achieved with 1 if I didn’t have to wade through layers and layers of abstraction.
They are already making their own widget library. Why not start there, and provide equivalents later?
* Drop checked exceptions. I’ve never seen a codebase improved by checked exceptions. You simply get people putting “throws Exception” onto their methods. Worse, unless you catch and rethrow exceptions (which is lossy) it exposes implementation details – for instance, which XML parser you are using. Yuck. This would be a backwards compatible change to the language (if not the VM). When compiling for a target environment that doesn’t do optional exception declarations, just make every method throw Exception and you’re compatible again.
* Allow aliasing. Sorry, but “System.out.println” is too long, I’m lazy. I normally end up declaring a utility class that everything in my project inherits from which adds stuff that in another language would simply be imported – ugly I know, but “print(‘foo
‘);” is so much clearer and easier to read than “System.out.println(‘foo’);” – or it is to me at any rate.
Well, these are only some ideas. Java is a great language and it could be *really* great if it borrowed more ideas from D – essentially becoming a practical rather than a pure language.
I’m downloading the ISO now – I want to read the source too. Exciting stuff for sure!
If you correct the flaws in Java, you end up with Ruby. Ruby has the defect of being enough Smalltalk-like without a nearly enough big user base.
However, if anything in, say, JNode, is to be non-Java compatible, it risks low success. The OS is intended as a VM and the VM is written in Java, but how does that work regarding libraries? Does the VM use the same as the userland? I’d say no from what I’ve seen.
That’s a smart idea. Would that run using a java hardware processor ? That’s be even better.
Can we not start this here? It’s a waste of time and space. No one will force you to use JNode if it is ever a “useful” OS, okay? These arguments tit-for-tat over “real” OS versions are useless. Hobby OS has its place, okay? If you don’t think so, that is a perfectly legit opinion. Only please don’t waste other people’s time with that opinion.
Hmph. The class libraries, lovely long names, layers and layers of abstractions, and checked exceptions are the things I like most about Java. Yummy OO goodness. The CORBA stuff is ugly as sin though. All those underscores. Is that what you want more of?
assuming you can read, this is a JNode topic.
Give it a rest. Go back to /. where you’ll find plenty of GPL zealots to fight with and the management encourages your flame-bait tactics.
If you’ve got something to say about USE or SUGGESTIONS for JNode you’re welcome. Otherwise, piss off!
This is definately one of the coolest open source experimental projects out there in my lowly opinion. An OS written on this language level is an idea whose time has come. I wonder how far down it can scale? Something like this in an embedded device or Palm would be great.
Is there a downloadable zip file for all the project source, or do you have to go thru cvs for each file? Or are the sources included in the ISO Image somehow?
Looking thru a few files in the cvs links, the code seems impressive – very clear and concise and pretty well documented for open source.
It would be neat to see a brief history of the project posted on the site as well. Does it derive from any previous projects like JavaOS or Jos or JKernel?
I’d love to get involved with this.
to zambhala:
contact [email protected] they would love to have you on the team if u can code in java. they are looking for all the help they can get.
But their Java Desktop is nothing like this. This is a real Java OS.
I have spent much time researching and reading about Java operating systems. And essentially what you ARE doing is building a special type of VM. This is a VM that can communicate with hardware directly (in some sense) in order to offer certain abstractions and APIs to user software.
Libraries:
=======================
On the subject of libraries, MANY/MOST Java libraries are pure Java in the sense that they can be loaded by any 100% compliant JVM. HOWEVER, certain libraries rely on the existance of some physical hardware. e.g. java.net will rely on the presence of some sort of network connectivity (like a NIC) and java.awt will rely on the presence of some sort of graphics adapter (like a traditional video card). Libraries like this are “special” in the sense that they are not 100% pure java because they are somewhat hardware specific.
NOW this is where things get interesting. In a traditional Java implementation of something like the AWT or java.net libraries, the libraries are dependant on a specific API within the supporting OS. For example, AWT on a Windoes box will rely upon the NATIVE Win32 API. Obviously not all the AWT code relies on the Win32 API, but much does.
In something like a Java based OS you can decide when and where you will rely on NATIVE code. For example, you could write an AWT library with native code in it which will be compatible with X,Y, and Z graphics cards. (essentially putting the native graphics “driver” directly into the library) Probably not a good idea from a design point of view.
You would most likely seperate the actual graphics card driver from the library which will make use of it. BUT NOW, you can actually decide if the driver itself is native code or NOT NATIVE CODE. Thats right. You can actually implement a “platform neutral” device driver, in Java, that would work with this Java “OS”. The key is that you would simply be relying on some abstraction of memory/dma/busses, etc. Those would probably be implemented in native code. (But would probably simply implement some Java interface specified ahead of time, which the device driver would rely upon.)
So the point of this all above is that even though some KEY java libraries are hardware dependant, a Java OS has the capability of making use of non-hardware-dependant versions of those libraries, if they are written in such a way as to be able to use a particular driver interface.
Java Hardware:
=================================
I have thought alot about this as well. And although it does garner lots of cool points, it really doesnt garner many practical points. Let me explain.
1) Although some reasonable research HAS been done into Object Oriented Processor issues and design (by the likes of IBM, Sun, etc.), the issues are by no means closed. What that means is that it is NOT entirely clear how you would use your silicon to vastly improve the performance of your application. You can gain some performance improvements, true. Im not sure what the implact on non-OO code would be. Thus I dont think it would be feasible to build these suckers in silicon.
2) Within time I honestly believe IBM, Sun, Intel will themselves see the importance of building processors that are optimized to handle Object oriented code well. Their own processor designs will begin to handle Java code better, as a direct result. (because java is inherently object oriented) NOW, the term Object Oriented is somewhat nebulous and ultimately meaningless in the software world.. it has been watered down. But in terms of what an Object oriented application looks like to a processor, there are no two ways about it. An OO application is NOT a traditional application. You can read the literature as I did, but one simple example is that there tends to be a significantly greater percentage of method calls vs. non-methods in OO applications. If Intel wanted to make processors deal with OO code better, they could take advantage of such a fact by making their processors handle method calls more efficiently. Java would automatically benefit.
3) Current java hardware is for the embedded space. Honestly. It is not truely powerful. Not that it couldn’t run a Java OS. I believe that it could. But I think it would be more economical to make use of commodity processors (e.g. power4/5, athlon, pentium).
4) I believe it is most important for this project, from the hardware point of view, to support “modern” peripherals and interconnects. e.g. usb1&2, firewire, PCI, etc. DO NOT get bogged down in backward compatibility. Move forward.
5) Honestly, i dont care what OS a silly palm pilot runs. And it would be a shame if issues of the embedded space begin to constrain the potential of this OS project.
This project has so much potential.
The days of the MMU are numbered
Sincerely,
Ian Nieves
Shame on you…checked exceptions are very useful is they are actually used correctly. Some points you have are valid so I don’t believe this blanket statement applies to you, but most people who “hate” checked exception are people who “hate” having to build code that ventures off the happy path. I think one of the biggest problems with checked exceptions that turns people off is that people have a hard time differentiating between application excpections and system exceptions. Now not having to deal with checked exceptions does have its place (RAD, prototyping, etc.), but is systems [programmed] that need 6 sigma reliability, they are very useful.
Hi, I see a lot of people having a lot of ideas. Why don’t you come and help us coze we need a lot of help. I am implementing the JNode GUI and let me tell ya that it is a very HARD work. I am preaty much alone in this team so if you wanna help writing a nice WT library pls join us. About the GUI I can tell you that it is much more developed than it you know. if want to see it in action you can check out build it and run org.jnode.test.gui.AWT_WTTest which is a AWT program that we use to test the GUI outsid. this test program it uses only JNode widgets but it uses the AWT Grphics implementation from Sun. We have until now implemented the JNWindow, JNButton, JNLabel, JNCheckBox, JNPanel and JNRadioButton. We also have a multidesktop environment implemented and ofcourse the graphics server eventqueue. I am trying to implement the JNode GUI to be as close to AWT/SWING as possible so it would be easy for peoples to use JNode native widgets for their programs. The biggest problem we face is implementing the java.awt.Graphics(and Graphics2D) object which needs some very tricky stuff when it comes to clipping and drawString(). We have a true type fonts library and we want to use this to draw strings. What we really need is HELP from good java programmers. The GUI is very close to be fully functional but 1 programmer is too slow for such a task. SO COME HELP US!
I have a question that probably betrays a complete lack of understanding of Java GUI APIs, but is your widgets API compatible with Swing, SWT or any other standard Java API?
If it is AWT, I thought that the reasons that Swing and SWT were developed were because AWT was awkward for an application programmer to use. At the very least, all the Java GUI apps that I personally use are either Swing or SWT. Porting those apps to another API would probably require a rewrite, losing many advantages of using Java in the first place.
If this is one of those “you must crawl before you can walk” situations, I completely understand. Your OS would in theory allow both Swing and SWT to be implemented just as natively, and probably sharing a lot of low-level code as well. It seems like an interesting project.
* Lack of properties in the language.
I might be wrong, but I think thats “metadata” in 1.5
Short method names,
Short, and confusing. No, Control-C, Control-V, Full stop in Emacs (with JDEE), or TAB in almost any editor will bring up a list of methods/var names. A none-issue.
* Allow aliasing.
Sounds like “static imports”. I must admit to being unsure of this, again, leave it up to the editor.
JNode GUI (@ Valentin) AWT vs SWING
Swing is 100% Java and an extention to AWT (well a subset of anyway). Once AWT is implemented, you could grab the Swing classes from src.zip on you Java installed and use them.
Questions:
Do you currently/plan to work with other Open Source Java libary re-imeplementations (Classpath)?
Native code compilation – Will this keep the compiled objects over sessions (like .NET), or only for the one run time (like Java)?
Intresting project.
As you may know the AWT /SWING/SWT is based on native widgets. They use the so called peers to comunicate with the native OS GUI. So we need a NATIVE GUI first and than we can write peers for AWT/SWING/SWT. We don’t intend to write SWING again or AWT but to write our own GUI and graphics server that can be used by AWT/SWING through peer system. Of course the applications written to use the native GUI will be faster. The SWING needs just a few peers like Component/Container/fonts..etc and we allready have that so theoretical we could run SWING on JNode GUI right now but we are facing problems on the java.awt.Graphics implementation.This is more or less a leck of programmers problem. If we would have a fast and good implementation of Graphics than the GUI could be used at full power. The idea is that first we want to write the library and after that care for performance. We are aware of things we can do to improve performance on a factor of 1000% but here we also have the manpower problem. That’s why I am saying COME HELP US..not only with your advices(which are very helpfull) but also with your programmers skills. Wanna see a non $$$ great implemented OOP OS? here is your chance to give a hand.