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

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.