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).

At first Be tries to port Java to BeOS. They wanted it with Be together. But Java was closed source, Be died and the code was lost.

Then some of Beunited and Zeta tried together port Java to BeOS and Zeta. But Java was still ClosedSource. They have already successfully run JEdit on Zeta.
But again, Zeta died and BeUnited stops its activity and the already ported code is lost.

Now it is different. OpenJDK is OpenSource. Anybody who want can help to port. And if the current people stoped the porting, every other people can continue the port.

So, I don't know when the port is completly ported, or if it will ever be, but I think it will be more ported then ever of Java to BeOS/Haiku/Zeta.
This time it will be a success!

The beunited effort was completely independent of anything Zeta related. We were targeting BeOS R5.0.3. Any cooperation between beunited and YelloTab was purely window-dressing and press-releases. I for one, never actually received my promised 'free' license to Zeta in the mail. In fact, I've never installed, nor tried Zeta.

That said, it should have worked on Zeta. It ran just fine on R5.

But now that both projects open source -- "they" can't take it from us.

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.

The stone age encompassed 2000? Uh, no - unless you forgot a few more zeros at the end.

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.

I believe the appropriate sentiment is: I hope the door didn't hit you on the way out. The BeOS community certainly isn't diminished by the absence of people who choose operating systems based on political concerns, rather than practical merits.

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 !! ).

I like both Operating Systems. But I think it would be interesting, on which of the two Operating Systems a actual Java runs first.
ReactOS needs only support the Windows-Java and Haiku needs additional a port to its platform.

On the other side, in some areas Haiku is already more advanced then ReactOS, I think.
For example in some screenshots the screen-resolution is much higher in Haiku then on ReactOS-screenhsots. Wide-Screen driver seems not supported currently on ReactOS.
Addistional it is possible to move on Haiku full windows (not only outline like on ReactOS) and that a lot of faster.

So, it would be interesting, which of the two Operating Systems will at first running a modern Java.

Well, Haiku is still alpha so I'd say the reason you don't see ISOs is to prevent people from trying it, saying it sucks, and never trying it again. It does run on real hardware (not mine unfortunately). Plus I've never seen a BeOS install/live cd in the ISO format, it's always .bin/.cue due to some shortcomings in ISO.

Also, Haiku is as easy to install as the BeOS, so writing an installer would be fairly straight-forward. Here's the manual process from BeOS (or an install/live CD):
1) Format a BFS partition.
2) Mount the Haiku drive image.
3) Copy the files.

1. That is a very lame excuse. I brought the topic up on of the Haiku lists, but apparently noone cares about people actually wanting to use it.

2. The shortcomings of ISO can easily be overcome. See Linux for example. There is a way to start a Linux installation from pure DOS. The same should be true to BeOS/Haiku. Don't blame it on ISO.

3. People want to try out Haiku - and most of them DON'T have a BeOS installation. So be prepared for these people and help them. Let them try Haiku - they can help you in giving you valuable information about compatible/incompatible hardware etc. p.p. Work with them and involve them!

1) It's not ready for people to actually use it. I know, I know, seems a bit strange... but we still can't compile Haiku with Haiku (yet).

2 & 3) You can build AND install to a spare partition from Linux. No BeOS pre-requisite exists. There is information in the developer docs on the haiku-os.org website that mentions ways to do this. Asking on a mailing list will get multiple, helpful responses.

1. That is a very lame excuse. I brought the topic up on of the Haiku lists, but apparently noone cares about people actually wanting to use it.

That's a lazy bit of mischaracterization. Considering that it is, in fact, quite easy to install Haiku on real hardware - if you can't figure it out, then perhaps you shouldn't be trying out pre-alpha software?

2. The shortcomings of ISO can easily be overcome. See Linux for example.

Um, there was nothing *to* overcome in order to install Linux from ISO filesystems. Do you actually have any understanding of why BeOS can't be installed from an ISO filesystem, or are you just assuming that it's trivially-easy because it can be done with Linux?

I know that ordinary ISO contains a FAT32/FAT16 compliant filesystem. ISO9660 compliant means a FAT32 system and since BeOS uses BeFS - a filesystem that stores a lot of the file info in different places such as attributes - it is not ISO compliant. Well, I thought of a wrapper e.g. in order to use BFS and be compliant with ISO9660. It should somehow be possible since one was able to 1. boot BeOS from DOS and 2. was able to boot a BFS file inside a FAT filesystem.

ISO does NOT contain a FAT32/FAT16 compliant filesystem anymore than it contains a Mac HFS/HFS+ compliant filesystem: ISO 9660 (perhaps that's what you're doing a shortcut for) actually, to some extent, supports extended attributes, and there are extensions to ISO 9660 (Rockridge extensions) that support longer filenames than the old lowest common denominator mutation, file version numbers, etc. but it isn't enough of extended attribute support for the richness that BFS supports. Sure, you could do the wrapper, but why, when the El Torito boot specification exists for x86 machines, and works well? There's no reason not to use it, and to use some bastardized ISO 9660 extension. Hybrid CD's have been made for longer than BeOS existed: I distinctly remember such titles going through the premastering department I worked in, that were commonly combination of standard PC ISO 9660 titles with Mac OS volume images on the same disc.

Booting BeOS from DOS definitely doesn't at all work the way you would seem to imply: it can most accurately be thought of as using a BIOS boot loader to load a bootsector from a file, and has absolutely nothing to do with being able to read BeOS formatted images and interpret them from within DOS. From there, it was a translation layer of BeOS itself that was essentially using a FAT16/FAT32 abstraction layer below the BFS driver level such that the BFS driver when it requested a block, got back a relative offset block returned from a lower level FAT filesystem driver.

Until Haiku is out of the pre-alpha state where it can't (at this time) build itself due to an incomplete VM subsystem, it's probably wisest to leave it at a state where the common user like yourself won't find it easy to install, but whine when it doesn't do this, that, or the other thing, etc. because if it's too easy to install, those without enough motivation and knowledge and diligence will only whine, as opposed to providing useful bug reports. Whether that theory is most correct entirely depends on the users, but at this point, with the holes that still need to be plugged, if you can't install it as-is, you're honestly not technically competent enough to be of any real value in the development and testing.

ISO9660 and FAT32 are old and they suck. That's what they have in common. Neither is of much use to Haiku, except ISO9660 for hosting the primary Haiku boot loader.

Haiku is not yet publicly(!) available as CD image for a couple of reasons:

(1: The project does not want to release pre-alpha quality.)

2: Haiku needs a BFS filesystem to boot/run from. ISO9660 is not enough by itself.

3: A bootable CD can not consist of a single BFS data track. I think bootable CDs need at least one ISO9660, or I suppose UDF, physical data track. I could be wrong though.

4: BeOS came on pressed CDs with 3 physical data tracks: one short ISO9660 track for the primary boot code, one BFS track for BeOS/Intel and a third BFS track for BeOS for PowerPC. I'm not aware of a multi-track image format that is not tied to a specific burner application (and platform). Distributing tracks separately is bound to confuse people and a multi-track Haiku image has got to be burnable with most any burner application or its a very bad idea to use that certain format.

5: BeOS install CDs were always "live" (but read-only). Making a stripped down, non-live Haiku installer just to be able to distribute a simple, single-track ISO is -not- an option.

6: Haiku has not yet, AFAIK, been given support for running off UDF (it may have to be extended with BFS-like features) or running off a BFS filesystem-in-a-file on an ISO9660 or UDF filesystem. One of these two solutions are possible. I'm guessing the latter is the most likely. Once there, distributing a Haiku "ISO" should be easy and hopefully the system is ready for alpha release by then.

It -is- possible to make a bootable Haiku CD currently and there is an installer application but there is no decent partitioning tool yet and the seek latencies of most CD devices coupled with multithreaded access to the CD's BFS track makes the actual boot take a very long time. This needs some work before its released.

I think that there is a need for a team to just write an installer. People aren't going to like it even if Haiku is at Release candidate 3 1.0. They are going to like the simplicity or not. You don't create a fan-base by waiting forever for a perfect product. People want to see a different OS on their computer, if it's good, they will wait.

And yes, I am sure it is easy to install Haiku if you have done it before. I have, but that is because I used my BeOS 4.5 CD to partition it, etc. It's just not easy for everyone.

I might have missed this, but where is my ISO where I can install the OS and run Be applications without virtual machines?

I think I'd focus on that first.

You do realise that Haiku is an open source project, and there fore, it done by volunteers in areas which tickle their fancy? there is no over arching development policy - people do things in their own time. At the end of the day, this isn't their job, its their hobby. Not to sound rude, but they don't owe you anything.

Yes, it would be nice if they all 'just focused' on something, but not everyone has the skills, ability or inclination in a certain area. Someone might be able to programme but it doesn't mean they necessarily have the ability to write the really low level code required. People help where they can, and we should be thankful for what ever contribution they make to a given project.

Getting the proposal represented to the OpenJDK announce list has been a team effort, involving many people behind the scenes for more months than I'd care to admit to.

This accomplishment belongs to the project as a whole, not an individual to abuse as a soap box. In fact, all of this has been accomplished in a time of transition, with a great amount of collaboration from many individuals in the Haiku project with vastly different talents and skill sets.

My blog post merely celebrates this occasion by reflecting on the failures of the past and rejoicing that the hurdles we ran into no longer exist. It's my own personal celebration. It has no relevance to the future of the Haiku Java Team, and as such it has no place here.

Haiku seems like a great effort, but i find it odd that they want to have java, webkit, OSS, etc and the OS still doesn't even seem to be able to self-host yet.
I'd love to port many apps i have developed to it, specially audio apps, but the OS seems to be never ready... since years.. by the screens it always looks great, but then you go to irc or the forums and it seems it's still far far away of even hitting alpha?
What is it exactly going on?

I was hoping before the summer months but don't think it'll happen. Before Summer because I'm guessing they'll get GSoC students again this year and it'd be nice if they could help Haiku work towards Beta.

Unfortunately, everyone wants to do their own thing. You have people working on WebKit, Java, OSS, etc. instead of combining to focus on getting to Alpha. Meaning, creating an installer, fixing up some odds & ends and squishing the major bugs out there will get done at a slower pace. At Alpha may show up at the end of this year or sometime next year.

You just can't force people / programers who dedicate their spare time. They decide what they want to work on and do. Even if this will cause the OS to take longer to complete. That's life.

Hmmm.... a bounty would be nice. A bounty paying someone to create an installer that installs Haiku (from the CD) onto a blank partition (anyone can g-parted an create a blank partition, so no need to create a partitioning tool) and installs Grub if the user wishes.

Maybe what would be best is creating an installer that formats a partition, grabs the nightly build and dumps it on the newly created partition, then install Grub if the user wishes...hmmm....

Likewise with Haiku, by tackling huge efforts like this, we inevitably have to finish, revise, improve, and complete parts of the OS that have been or are missing, defunct, incomplete, etc.

It's very likely that the things that keep us from being self-hosting are the very things we'll need to overcome to port OpenJDK.

OpenJDK will inevitably attract new developers to the project. This means more people who are capable of fixing, fleshing out, and finishing things within Haiku itself -- even if it is for their own curious or selfish desires.

In the end, we all benefit.

Projects like WebKit and OpenJDK aren't just narrow-minded, one-trick ponies. They breed a larger community as well as improve the quality and quantity of code in Haiku.

An OS developed without concern for the applications ends up just being a big useless bucket of bits. An OS is the foundation for an application ecosystem, and like the natural world, it is beneficial to evolve things in parallel and adapt things as you go along, because what you first think will work often doesn't work as well as you thought it'd work.

Developing new applications alongside the OS at the same time gives more of a testing frameworks for the OS and also helps the application developers learn the platform's ins and outs. There are non BeOS 5.03 features that have been implemented (the Java port in the past comes to mind) that were added to the system precisely because they were needed, and BeOS 5.03 simply couldn't support them, and thus these features that were foreign to BeOS 5.03 are now native to Haiku, and greatly improve the system's value. If you look in the bug database for Haiku, you'll find a large number of filed bugs referencing other applications in development, even if they're only in mostly maintenance mode.

Not all application developers are capable of what's required to develop the OS itself for various reasons, but they have the time/energy/ability to work on the separate applications. Thus, they aren't taking away from the OS development as much as they're adding trees to the forest of the OS and the other applications to make it a much better habitat for all.

Good for Haiku. Bryan is it possible to run the old Java port on Haiku? Maybe take some screenshots of it running?

I really wish the team good luck, hopefully the OS wont feel like its 10 years old one day, to bad it looks like Win95 otherwise I would be more intrested in using it, it just doesnt attract me anymore by its look. I heard Stippi was sketching on a new more fresh look a year ago but it hasnt been shown in the light, right?

The funny truth is, a clone of the BeOS Installer has been written years ago. Really. It is even included in the Haiku image at /boot/beos/apps (but not in the Leaf menu). In Haiku as in BeOS, the job of the installer is to let you pick a partition, optionally initialize it with BFS and then simply copy all the files off of the CD onto the partition. This is done and the Installer is definitely not holding up the release of a CD image. DriveSetup, the app which lets you partition your harddrive is not finished yet, and it is one missing part, though people have mentioned that they would be happy to partition with GParted.

Really, the reason why we have not released anything yet in terms of "Here is R1 alpha as a CD image, go ahead and try it!", is that Haiku is just not stable enough. We had fixes in OpenBFS code just very recently. Our intended audience *at the moment* are people which understand and can follow the installation procedures outlined at our website.

It is very hard to undo a bad first impression. And that's just what Haiku would give most people at this time if they actually tried to use it for something more than tracking down bugs.

As for ports of WebKit, OpenJDK and so on being a distraction... it's what people here already said:

1) It's not the core developers working on those anyways.

2) Making these ports possible at all by fixing bugs in Haiku or completing the implementation will obviously help Haiku the OS itself.

P.S. We actually do care what people think, a lot, but we can't help it, we have to do what we think is best. :-)