Re: areas of divergence

[Tom Tromey]

>>>>> "Mark" == Mark Wielaard <address@hidden> writes:

>> gnu.java.net
>> java.net.URLClassLoader
>> We have some additional protocol handlers (core, gcjlib), but also
>> some divergences in file, jar, and http.  These need to be
>> investigated, as I don't think there is a good reason to diverge
>> here.

Mark> What we should probably do is split out the inner-class URLLoaders into
Mark> their own (package private) classes. And have a VMURLClassLoader through
Mark> which a runtime can register its own special URLLoaders (like the
Mark> gcjlib: and core: handlers of libgcj).

Yeah, I agree.  I filed PR 22579 for this.

>> gnu.java.locale
>> java.text
>> java.util
>> We're still using the old locale framework.  The only reason for
>> this is that I didn't want to do too much in the merge.  I hope to
>> look into this soon.

FWIW I started fixing this.  I'm just debugging some test failures.

>> gnu.java.rmi.rmic
>> Classpath doesn't have rmic in the tree any more.  And the rmic in
>> classpath-tools now uses ASM.  I'm not sure what we want to do
>> about this.  Removing it would mean stepping back a bit from our
>> completeness goal; OTOH merging in tools would mean handling ASM
>> somehow ...

Mark> We probably should make separate releases of GNU Classpath Tools on day.
Mark> These should of course also come with native gcj-compiled versions of
Mark> each tool. Just like we do now for gjdoc.

The issue for gcj is that we've historically shipped the tools.  It is
really part of our vision (which is really Per's original vision) of
supplying a complete toolchain.

I think we should do as Bryce suggests and include ASM in our builds
(though not in libgcj).

Mark> Do you have any guidelines for "keeping the big merge in sync"?
Mark> When is a new "overlay" version tagged and moved into the gcc tree?
Mark> Could/Should we coordinate that with GNU Classpath developer snapshot
Mark> releases? And how do we handle small (emergency) divergences that pop up
Mark> in the embedded classpath dir inside the gcc tree?

I put some guidelines about this into libjava/HACKING, but I have a
few more to add.

I think we should tag classpath when we do the import, for
traceability.  I did that with this import FWIW.

For emergencies I think we can just check in patches to
libjava/classpath/, but we need to make sure we have some long term
fix as well -- I don't want hacks and divergences accumulating there.
We already have one of these ... unfortunately for a bug I can't
reproduce myself :-(

I think importing Classpath releases would make sense.  Some
coordination is needed when gcc releases are looming.

Tom