GNU Jaxp patch

[Bryce McKinlay]

Tom Tromey wrote:

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

We need to concentrate on the BC-ABI as the single, supported ABI for 
Java applications. Outside, perhaps, things like small, embedded 
applications, there isn't really a great deal of use for the old ABI, 
and it will greatly simplify maintenance to stop making compromises for 
the sake of it.

That is not to say we should go and immediately delete all the old ABI 
code, but anyone who wants to use it once we make BC the default needs 
to recognise that they're on their own and better know what they're doing!

>I'm not averse to something more ad hoc, like '--without-xml',
>'--without-awt', etc. 
>
I'd like to see a more general solution for building custom libgcj's for 
static application deployment. Putting in a configure switch for 
everything might just end up being a maintenance burden for something 
that isn't particularly useful. For a regular shared library deployment 
of libgcj, the idea is to replace the JVMs functionality, thus we always 
want to include everything.

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

I'd be happy to see libgcj split, as long as it is transparent for 
users. Any solution that improves performance and ease-of-use - 
particularly for end users but also for Classpath developers -  would be 
worthwhile. With the new ABI, splitting out parts of libgcj should 
become quite possible, and removing the old ABI from the equation gives 
us more freedom to work out what is the best way to do it.

Bryce