Submitted by Bryan Varner, one of the core developers of the stalled port of Java 1.4 port to BeOS R5 has an interesting post on his blog. Recently he met up with Ian Murdock of Sun at a local Java Users Group, and as a result he is now looking to restart the port, this time for Haiku.
Interesting indeed…
I hope something (anything!) comes out of this
While I’m not a Java dev or advocate myself, I certain can see the usefulness of a fully-functional Java port for BeOS/Haiku.
It’s one of those things that helps people “Feel Good” about Haiku as a real future OS option for the masses.
Sun probably has plenty to gain marketing/PR wise, and really, very little to lose…
Although the work is big, now both Haiku and Java being open-source, I believe the porting of Java will not only improve the appeal of adopting Haiku, but really help on the improval of Haiku’s codebase.
This is good, this is really good. Can’t believe there’s so much bubbling the Haiku community right now, even though blabbering and delivering is hardly the same thing.
I would definitely say that it’d be a good deal for SUN PR wise to help Haiku… and as a sideeffect, I’m sure that Microsoft (in the longer run) would tremble a lot more from Haikus presence than any *Nix presence (excluded OSX) on the market.
I’ve waited 5 years for things to start happening for real, now it seems so many pieces of the pussle just seem to fit.
Am I the only one who actually feel hope about having fun using a system again?
Are you saving to buy a Wii?
Am I the only one who actually feel hope about having fun using a system again?
Certainly not. There are those of us (myself included) who bought a copy of BeOS R5 in the year before the big sale to Palm who are eagerly awaiting a faithful open-source evolution of the OS. I still use my R5 Pro on a Dell CPi laptop mostly for nostalgia…the day I get to run Haiku R1 final on my fairly modern desktop will be a joyous one indeed.
this is for real, it could be really good news.
Oh, it’s real.
It’s very real.
Boy, I don’t envy anyone attempting that Java port. What a bear. That could take another 3 years if it’s just a few people working on it in their spare time.
Not too many have been talking about a Mono port, but that would also open the door to some nice development environments (SharpDevelop and MonoDevelop) and many other programming languages for Haiku. I haven’t read about a freely available Java compiler that is up-to-date with generics, etc. but at least IKVM could be used to get the Java bytecode running under Mono’s CLR.
In the list of never-finished-so-never-released stuff for BeOS/Zeta I saw a mostly working port of a .NET stack (another one than mono)… shame. (oh well, not so much I suppose.)
I have to assume you’re referring to Portable.NET?
http://bebits.com/app/4072
It’s not really meant to compete with Mono anyway…
> I have to assume you’re referring to Portable.NET?
Portable.Net compiles fairly painlessly under R5 under Intel (never tried PPC, but I assume that *might* work too.) But you have some BIG caveats along with that. The native threading has to be disabled currently; it could be reenabled if someone wrote a handler for it – I just didn’t get a chance due to lack of time. The Garbage Collector is also disabled due to a library dependency I didn’t get a chance to resolve. The version on BeBits was fairly complete. I spoke to the developer and he’d done more work – I believe he had threading working. At this point I put down the compiler not wishing to duplicate effort – left it at the 0.7.4 release minus the features I mentioned, and looked at getting GUI working. Here is where things got unstuck. I found that whilst I could get the GUI wrapper to work (as I used one I’d written for PASCAL a few years previously that was known to work) any time Portable.Net tried to call a delegate that mapped to a native function, it went caboom if it passed back any variables. Ulitimately I gave up at this point. I *could* just be my lack of Portable.Net experience, but it actually seemed like memory protection issues (segment violations where happeneing when accessing the variables passed to the delegates in the native code.) It all worked okay in a single threaded world, but multithreaded (passing data from DotNet delegate to a wrapped BWindow – probably across a thread boundary) just bombed – or worked once sometimes but never a second time. This DID work from in FPC apps though (i.e. all native code), as it was the basis of the first GUI port to Free Pascal (before the current one went ahead.)
Dunno. Didn’t get enough time to look into it and I no longer have the source under BeOS because I forgot about it being on my BeOS partition before I resized my Windows partitions using Partition magic.. lol. all gone.
Edited 2007-06-29 06:01
Yeah, it’s a bear alright.
Much of the class library code for 1.4.1 will be reusable on a current port though, so the platform abstraction is farily well along. It’s not done, it’s not quite -near- done, but I’ve been able to run some pretty heavy JDK 1.4 apps on BeOS R5.
Would I be correct in assuming the bulk of what’s not done has to do with AWT/Swing and networking?
For those interested in Java on BeOS:
http://video.google.com/videosearch?q=java+beos
Networking is actually fairly complete.
I’ve not done any gap analysis on it, but we were able to run all sorts of net applications on R5 net_server. Surely BONE was in a better state. 🙂
AWT is mostly done. Keyboard handling isn’t quite up to snuff — I was working on that when we finally sorta ‘let go’ last time… almost two years ago now.
Swing itself is written in Java, so it merely depends on the AWT and a few other key parts being properly finished off.
Java2D – the graphics subsystem, is heavily stubbed at this point. I clearly remember what we had to do in order to get things working, and I’m positive it wouldn’t take me (or anyone else who might understand what we were doing) very long to start filling out our non-BDirectWindow implementation. The use of BDirectWindow is still something I dream about (and we could acheive) – but I think at this point we’d be better off using some of the private API’s in Haiku to avoid as much of the BBitmap IPC as possible.
Anyhow, networking — no.
The biggest gaps are in AWT subsystems. KeyEvent generation, FocusHandler, and Java2D.
There were also stability problems imposed by the protect_mem issues.
The biggest problem with moving to the OpenJDK: We’re two or three major releases behind, and a lot has happened in the HotSpot VM since 1.4.1. Our tree won’t merge easily.
Good to see the hard work you did previously wasn’t in vain.