GNU Jaxp patch

[Tom Tromey]

>>>>> "David" == David Daney <ddaney@avtrex.com> writes:

David> Currently I am using a hacked up libgcj.so that has all of AWT and RMI
David> and most javax removed from it.  Now I may be removing XML things as
David> well.

David> Having said all that, I am not sure what the best solution is.

David> Is it possible to either:

David> Break libgcj into several shared objects that are loaded on demand by
David> some dynamic library trickery.

David> Add more build time switches to turn off things like ATW, RMI, XML, etc.

Yeah, good questions.

On the GUI branch, libgcj.so has been split into a number of different
files, to speed rebuild times.  Things largely break down by package,
though there are a few little exceptions like AWTPermission (referred
to by SecurityManager).

I think it isn't out of the question to pull this to the trunk, or
perhaps to use something like this to make it possible to disable
chunks of the library.

It does seem difficult to satisfy all the needs we know of though.

For instance, we could split libgcj into several smaller libraries and
use the not-yet-written versioned directory scheme to make them
invisible to the end user (a request for java.awt.foo would load the
part of libgcj in the magic install directory).

But, this messes up two sets of users: people who want static linking
and people who want old-style C++ ABI linking and who use classes that
have been split off.

The former class of users have been in a sort of de facto hell (I
mean, do-it-yourself paradise :-) for a long time.  (Not to minimize
their struggle.)

The latter users would have to start adding "-l-java-awt", etc, to
their link lines (which is worse than it sounds since first of all it
introduces a version dependency and second it means we have trouble
renaming things in the future).

Per had a plan to solve all this, way back, but as I recall it
involved linker hacking.


I'm not averse to something more ad hoc, like '--without-xml',
'--without-awt', etc.  This has the problem that library
interdependencies do exist, and we can expect more in the future.
But, it isn't as difficult for us to change around configure switches
from release to release.  And at least at present a lot of these
things do just drop out.  Some dependencies (doesn't javax.imageio
rely on jaxp?) can be handled by having configure error out if the
user makes an invalid request of it.


Any other thoughts?


There's still the somewhat open question of whether "one big
libgcj.so" is good for anybody really.  Not all java apps use all this
stuff, having it in separate libraries may save us something.  I
haven't done the measurements though, and it could go either way.

Tom