Please do not make the mistake I've seen in so many projects of running right at coding without the Analysis Model and Design Model having been completed, at least in rough form. You'll get an explosion of classes which an OS project cannot afford. I don't mean to preach, I just know that it's one of the most common ways to butcher a project and if good OO design is being applied here than my apologies. I am very interested in this OS, as javaos is really a thin-client OS and doesn't meet the needs of anything heavier.
On another note, More discussion should be had re: Object store vs. file system, in that if you are going to support other file systems, then that's going to complicate the notion of orthogonal persistence without some serious work on abstracting those legacy file systems.
Sincerely, Christian Gruber Sun Microsystems - NAFO Customer Engineering (905) 477-0437 ext 359 Christian.Gruber@opcom.canada.sun.com.
The explosion of classes Christian is talking about is a natural phenomenon one can see happening, e.g. with java.. But then, why isn't this considered as a real problem at Sun? The answer has to do with OOAD and its counterpart, upgrades, which is considered a Bad Thing[tm] most of the time, since it breaks specification and implementation promises. On the other hand, java. upgrades always had the nice side effect of deepening the namespace hierarchy, thus making it not only richer but also more understandable for humans. There is an analogy between namespaces and Usenet newsgroups.
We have to see the complete picture. To quote Robert C. Martin:
__"One wayward thought, deep in the bowels of design, caused a major restructuring of the analysis of the project. This is typical of nearly all analysis and design efforts. The successful design and analysis of software is always punctuated with revolutions of thought and major upheavals of design strategy. This cannot, and should not, be avoided; these very upheavals cause the greatest improvements in our designs. Development environments that are not flexible enough to accept the inherent instability of the design process must consign themselves to mediocrity and failure."__ (from: "Designing Object-Oriented C++ Applications Using The Booch Method", p. 460)
Is the JOS environment flexible enough? Noone knows, but we can try to improve our chances. We have the Bazaar, we have WikiWeb, and we will try to overcome shortcomings in our tools (e.g. Java) by providing our own solutions.
[Stepping from the soapbox] --RalfStephan
Is it a good practice to develop a internet-centric OS. This violates the concept of harware-independency. I found jos.org while searching for a OS for a planned generation of PDA's (probably not-connected most of the time). Any comments?
Kai, this is an interesting issue. One of the advantages of an JavaOS like JOS is on the one hand a small memory footprint which offers the combination of OOP for PDA like devices and on the other hand a huge amount of programs which could run on such a device and would be produced by 3. party programmers. So in my opinion JOS should do both run on unconnected but also on devices which are connected to the internet. In this manner it may run on mobile devices. Maybe JOS can find its way to such consumer electronic- would be great if this would be possible. If I understand it right, work for the Kernel is GNU-work and must be open to the community where as work for specific device drivers could be closed, is this right? If so this could interest companies to participate here since JOS (although standartisation work for Java is in the beginning, right?) would follow an open standard and in communication technology the time is over where companies neglect open standards.
I think that an explicit line about internationalizability should be added to the Goal. JOS should be designed from the bottom up to handle non-Roman characters and variable text-directionality (i.e. not just left-to-right top-down). See UserInterfaceRequirements page for further discussion. The fact that Java uses Unicode does not in itself solve all of the issues.
Many places where, for economic reasons, a free OS would be particularly attractive use non-Western writing systems.
I'd be very interested in seeing as a next step - a demonstration of being able to create a boot floppy that will load RTEMS into memory and do something very simple, like display "hello world" on the screen (forgetting about including a Java VM at first). Once that was done, then we could take the next step of grafting a VM onto RTEMS.
Barry, The archives for the kernel list would best help explain the current status. It is best to read from the bottom up? (in reverse historical order) http://www.spin.de/osproject/archive/jos-kernel-archive/date.html
Based on the Wiki pages, I got the impression not much was happening, but in the mailing list archive I see talk about the very thing I mentioned above.
--Barry Pederson, 5/2/98