Posts tagged 'freejava'
Being a handhelds.org guy I talked to Andrew Haley at the Oldenburg DevJam about how feasible running GCJ on ARM would be and what needs to be done to make it happen. Incidentally Tom Tromey had given an overview on the same topic on IRC a few days before. So, thanks to Tom I wasn't totally clueless ;)
Anyways, here's a short summary:
- GCJ is the production quality (just have a look at how many packages Fedora ships use GCJ) runtime of choice ATM. We want this on ARM as well.
- The ARM port of GCJ isn't finished. Code that has been compiled to native binaries/libraries using the BC ABI should run fine. The interpreter, however, needs some work to be fully usable.
- For the interpreter to work closure support would have to be added to libffi. Lack of closure support is also why DotGNU Portable.NET can't run Gtk# applications on ARM yet. (Making pnet/gtk# work on ARM was one of the Summer of Code projects mentored by handhelds.org).
- Some platform specifics in libjava (for locks, stack traces, turning null pointer dereference into a Java exception, ...) will have to be written.
- Versions of boehm gc earlier than 6.6 won't work properly on ARM.
Andrew also pointed out that Java classes compiled to native code add significantly to the space requirements of the class library. Michael Koch and me had blogged about possible solutions to this issue before.
That's it for now. As usual, any corrections/suggestions are welcome. Oh, I should note that in order to work on this myself I'd have to learn a *lot*, which doesn't mean it won't happen but don't hold your breath on it...
I'm afraid I can't push ('monotone sync' actually) to the OpenEmbedded repository right now, since monotone decided to screw itself over and fail with an invariant violation on 'monotone merge'. If you want to build Classpath 0.17 with OE just rename the .bb: 'mv packages/classpath/classpath_0.16.bb packages/classpath/classpath_0.17.bb'.
While I've been on a work and university deadlines induced hiatus a lot of things have happened in the Free Software world. One of those is that the free (as in beer) BitKeeper client is now history and OpenEmbedded switched to monotone. After a bit of struggling with monotone (it's dead slow - 80mins for an initial pull on a P4 2.4GHz, much longer on older hardware) I now have a working OpenEmbedded environment again.
I've upgraded GNU Classpath, JamVM, and SableVM to current versions. Binary packages for Familiar 0.8.x are available here. The dependencies are against more recent packages than what's in Familiar 0.8.2. Try --force-depends to install them - YMMV.
For those who are wondering, I have no plans to add SableVM SDK to OpenEmbedded or ship it as a package for Familiar, since it violates a couple of common distribution rules (and the FHS?). And on embedded devices (which are low on flash space) it doesn't make sense to ship duplicate binaries anyway . Fine grained packaging and sharing binaries/libraries among applications is the rule there.
In related news, I had to remove the included external libraries from the sablevm source tree and patch out any references to them from the Makefile.am's to make autoreconf work with it (That's necessary to replace certain macros with ones that work in a cross compilation environment). I highly recommend running autoreconf to sanity check the autotools input files before releasing stuff like that.
I'd like to point out one more idea in addition to Michael's list.
4) Supporting a finer grained packaging.
What do I mean by this? For an application specific runtime environment it's rather easy to identify stuff you don't want. It's very unlikely that you'll need AWT/Swing on a headless webserver. Following Michael's strategy 1), you'll build classpath with --disable-gtk-peer, possibly remove unused classes from glibj.zip, and you're finished.
However, this doesn't work too well for distributions (like Familiar) which aim to provide a universally usable set of packages. This "one-size-fits-all" approach sounds like it has to collid with the aim of consuming as little precious flash space as possible, doesn't it?
Well, the easy way out - packaging different build configurations - isn't an option really, since that would result in conflicting packages and a general maintenance nightmare.
A more clever way is to use one build time configuration covering a wide range of use cases and to split the result into as many packages as reasonably possible. E.g., the current kernel packaging code in OpenEmbedded creates one package per kernel module. The same goes for GStreamer modules and glibc localedata just to name a few. This also helps reduce runtime dependencies for core functionality of a given software component (which isn't a new idea of course if you look at gnuplot in debian for example).
Obviously, I'd like GNU Classpath to support something similar. The native libraries (libgtkpeer.so in particular) can be packaged separately already. What's left is one big (in embedded terms rather giant) glibj.zip. Splitting that up isn't a trivial task due to partly less than obvious (java) package interdependencies etc.
Any pointers as to how this could be accomplished would be appreciated (packaging AWT/Swing separately is what users request most frequently btw).
OpenEmbedded is a cross compilation aware build system (consisting of a set of tools and package description files) aimed at building entire (currently Linux based) distributions from sources. Examples for distributions using it today are Familiar and OpenZaurus.
So what's in already?
- GNU Classpath (built with jikes)
- fastjar (available at build time for jar creation)
- Jikes (available both at build time and as a package)
- Kaffe (work in progress. builds but at least on ARM doesn't work yet.)
The road ahead obviously includes cross compilation to native code using gcj. Basically it should be as simple as enabling gcj in the gcc-cross build, but I haven't got to looking into that closely yet.
The issues with SableVM I mentioned earlier appear to have been fixed in SableVM 1.11.x. The apparently ARM specific random crashes don't seem to happen either. Good job guys!
JamVM 1.3.0 is out.
JamVM running on an iPAQ H3800.
A simple demo application using AWT and Gtk+ peers.
Actually plotting a function.
And another one.
It is kind of sad to hear that "the AWT/Swing in 1.1.10 and current staging are horribly broken".
In other news, JamVM 1.2.5 appears to work fine with GNU Classpath 0.14 (at least for AWT applications). This is the first JVM to run AWT apps flawlessly on my iPAQ (and will be the first free one to do so in Familiar as part of the next release).