Posts tagged 'classpath'

Oldenburg Linux Developers Meeting 2005

I received an invitation from Joey a while ago and accepted (and forgot to blog about it). I'll attend the meeting from Wednesday to Sunday. Although I'm not a kernel hacker I plan to meet some friends from the GPE project and other nice people there.

And if the GNU Classpath distro DevJam takes place there, it will be even more fun!

GNU Classpath 0.17

It turns out I missed the 0.17 release, probably because I didn't expect a new release so soon. Rock on, guys! Updated packages are available at the same location as before.

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

Reduzing the Size of GNU classpath's Runtime jar

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

Current SableVM Confirmed Broken. JamVM works!

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