Posts tagged 'classpath'

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.

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

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

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