According to a news post on the Haiku project website, a new port team is being formed to bring Java technologies to the Haiku platform. The goal of the Haiku Java Team is to port OpenJDK to Haiku, and they would like to see the port included within the structure of Sun's OpenJDK project. The Haiku developers have already been in contact with members of the OpenJDK Porters Group to pursue their objective, and a formal proposal has also been submitted for consideration by the OpenJDK project. The Haiku Java Team is an initiative lead by Bryan Varner, who together with Andrew Bachmann worked on the port of Java to BeOS in the past (demo video).

In the beginning of this effort I thought: Oh, great, we'll have an open source BeOS. Nowadays - 8 years after the last version of BeOS - with the huge progresses being made by Gnome and KDE, it seems absurd to have an operating system that considers itself as copy of BeOS 5.03 ...

I was very fond of BeOS then, even used it as my main OS. BTW: Since that time - the time BeOS died - I swore to myself never ever to use a proprietary OS (Windows, Mac etc.) again. And I haven't and I won't.

Haiku isn't a copy of R5, it is a re-implementation ( yes, VERY similar ).

Haiku, however, will evolve surprisingly rapidly when official Alpha releases start.

The issue now is that not all developers are knowledgeable enough about Haiku's under-pinnings ( mostly in relation to bugs ) to comfortably implement features they want added or changes they want made.

I, for one, have been watching the source repos for years waiting for a certain level of not just completeness but code stagnation so that my code can be properly targeted for the first beta.

I have, as yet, not submitted any code to Haiku and am not a member, but I fully expect this to change in this year. What I want to do with Haiku is very involved and requires a relatively stable code base to be present in certain system libraries and the kernel ( as I will be trying to submit changes to those areas ).

One thing I considered was adding a server-mode instead of limiting to either kernel or user-mode. server-mode processes could directly expose shared memory ( through a AutoLocker/SafeBounds/FastMath object, or something similar ).

server-mode processes would also always have their dependencies met by the kernel, so starting the media_server would cause the media_addon_server to load at the most proper time, etc...

The mode would also address some porting issues from Linux (IPC improvements), and could boost the performance DRAMATICALLY for the app_server. Imagine a button drawing directly into the frame-buffer rather than sending the drawing commands to the app_server which then would draw into the frame-buffer.

Of course, the back-end work is massive to get the full benefits, but I think it is something I might try.

As you see though, getting back on topic, Haiku offers SO much more than BeOS ever did! I can only say hooray for the excellent developers who have kept the project going ( and considering their numbers, have made super-human-like progress ).

Time will show Haiku to be going the right way instead of the easy way, and quality will be unmatched in any OS ( maybe we will finally have an OS better than OS/2 !! ).