Bringing OSGi into discussion again
Submitted by Farok on Mon, 04/12/2010 - 19:40.
Hello,
last time I did some research on the internet about whether there are some Java based operating systems out there. Finally I got to this one which looks most interesting to me, but it seems not to be developed very actively (just look at the last post times of the forums). As I'm an extreme OSGi enthusiast I looked for OSGi support at first, but all I saw was some few year old post about licencing issues with R3. Nowadays there is R4, which is published under EPL, and as far as I know this licence should be compatible with LGPL, or isn't it? When it is, I would really like you to consider using OSGi for JNode, as it would provide a straight-forward and standardized way of handling and deploying plugins as Jnode currently does in an IMHO quite strange way, adapting some things from OSGi and leaving out others. I don't know much about how JNode works exactly and actually I'm not the first who wants to see OSGi in JNode, but I think it could push JNode alot and could bring a lot of additional clearity having all the components, except some core components in order to boot and run some OSGi framework, in bundles.
rgds Farok
- Login to post comments
OSGi and Java-based operating system (+)
Dear Farok,
OSGi is "the module system for Java". It may be the most mature module technology. It makes sense to me to build an operating system from Java and OSGi. That is what I have always wanted. That is what I am pursuing.
I have watched as JNode has become more and more monolithic, less and less modular. Parts of JNode, such as the Command API, could be platform independent, and should be. But it is not yet possible to build the Command API apart from the entire operating system.
JNode should be honored for its accomplishment. It proves that it is possible to write an operating system with 99.9% Java.
Meanwhile, IBM has released a commercial product called WebSphere Application Server Hypervisor Edition. It is optimized for cloud computing with VMware ESX. It is Java and OSGi. IBM does not called it a Java-based operating system, but that's exactly what it is. Like JNode, it is 99.9% Java. They started with a GNU/Linux distribution and removed all of the excess "baggage". They use an off-the-shelf IBM JDK. When you boot up the OS, everything that can be done in Java is done in Java. The user interface is web-based, of course, a web application called the "administrative console".
I am not now nor have I ever been an employee of IBM. I just want to point out the fact that Java plus OSGi is a good idea. Just look at the large library of existing modules from Eclipse, Geronimo, Rational, WebSphere, etc. It is not just a good idea, no, it is a demonstration of the kind of modular and version-aware thinking that is required for an operating system.
I will say it one more time. Members of an operating system project cannot build every component that will ever be needed, and should not. Members of an operating system project should build the absolute minimum framework that enables other people to build and run their own components. My two cents.
Thanks,
Maybe introduce standard services...
I have looked at the JNode source code for quite a while now, and saw that it might be very difficult when not impossible for me alone to rewrite those plugin parts of jnode to use OSGi. The plugin system is started in the first method call after having initialized the vm, all the drivers use the jnode plugin system and the whole build process seems to depend on plugins. One short-term approach would be introduing OSGi as a plugin itself and provide standard bundles which provide services to communicate with the JNode base system. Of course this isn't that nice and clean either, but then switching over to a "native" OSGi support would not require to do any modifications on the bundles except those services that connected the OSGi world with JNode. When standardizing this services you may get some Java OSGi OS Standards, which would be nice, when you want to run your apps on some other java osgi based distro (there aren't much of them yet, though). I think the service model is very nice to be used in an operating system, as this way all different divers and apps can communicate between each other easily, without using loopback networks or common config files or memory. Just think of a standard address book service all address book frontents can access (maybe after the user gives the permission). This is the only way I can imagine that is most document oriented as possible. You don't really have applications anymore, you just have plugins for your operating system itself, making it capable of coping with any kind of content in any kind of presention the user likes. On this base the user could easily switch between all those different desktop environments for java outthere, e.g. Project Looking Glass if he likes it, or a custom environment for this kind of operating system. This way it would be very easy for developers to write their own desktop environments and publish them, e.g. trying out to introduce a window-less design, without writing all the backend logic, e.g. for reading some file types or storing address book information, again, as it is done with GNOME and KDE for instance. I could go on for hours what immense opportunities this would give the JNode project.
Wish list for a platform-independent command interface
What do I want? Out of the box, I have always wanted a basic user interface to listen on standard TELNET port 23 (eventually standard secure shell port 22). When I connect with PuTTY, for example, I want my user interface to provide a very long list of high quality commands. I want each command to be compiled separately, jar'd separately, a standard, off-the-shelf OSGi-compatible plug-in, each command to be developed and contributed by a completely different community, if possible. A command should depend upon off-the-shelf, preexisting, production-quality modules, whenever possible. This follows the highly distributed development style of AIX, CP/M, DOS, i5/OS, Linux and Windows.
Ant has a command API. I want every possible Ant command to be automatically available from the command line.
Maven has a command API. I want every possible Maven command to be automatically available from the command line.
JNode has a command API. (I don't like it because it cannot be separated from JNode. I want to run a platform-independent, Java-based operating system, for example, on top of a foreign OS, such as AIX, i5/OS Linux and Windows.)
Apache Felix has a command API called Command Service/TUI. (It is incomplete. But at least, the Felix command API is a separate module without dependencies.)
Knopplerfish has a command API. (It is incomplete.)
Geronimo GShell has a command API. (It is incomplete. But at least it can listen on standard TELNET port 23!)
The CjOS project has a Command API. (I don't like it because its plug-in system does not use multiple classloaders like OSGi.)
Just like AIX, CP/M, DOS, i5/OS, Linux and Windows, I want redirection and piping to be written into the command API so that anyone who wants to can write their own shell. Just like these, I want the called command to parse its own arguments, possibly with a command line parsing library. But unlike these, I want to run a command either (a) using the current thread, (b) in a separate process, (c) a separate thread, (d) an isolate.
And if that were not enough, I want to easily connect to my platform-independent operating system using Remote Systems Explorer of Eclipse. A module system, such as OSGi, is fundamental for structural components. A modular approach, embracing separately compiled, independently developed, versioned modules, is critically important.