Post a Comment
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...
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?
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.
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.
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
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.



