This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GNU Jaxp patch


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]