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, 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 ( in particular) can be packaged separately already. What's left is one big (in embedded terms rather giant) 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).