libgcj maintenance for 4.0.x branch

[Tom Tromey]

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

David> How does this differ from the rules for C, C++ and the C++
David> library?

David> If it is different, why?  And isn't it really some the SC
David> should decide?

Perhaps the SC or the RM will decide, but we can provide a
recommendation.  The message I've understood is that we're basically
free to control our own destiny, as java is not release critical.

One reason things could be different for libgcj, as opposed to, say,
libstdc++, is that we're in a different state of maturity.  Right now
we're doing about one major release per year.  However, the class
library is changing much more rapidly than this.

The proposed rule here is actually fairly conservative, perhaps overly
so.  "Link compatible" means that we can't add new non-static methods,
for instance.  I take this to mean we won't even break (link-wise)
things that users shouldn't be using -- say random classes in gnu.*.
New packages and the like rarely cause trouble (apart from increasing
size of libgcj.so).

Starting with 4.1 I would like to see a much less conservative rule,
namely that we only promise compatibility if you use
-findirect-dispatch.  (And in a similar vein I'd like to do the Big
Classpath Merge, so we can track the library more aggressively.)

In the 3.4 series we barely did anything after the first release.
This caused a few complaints, but was generally appropriate, I
thought, given our plans for 4.0.  Nowadays we're getting more users
and it seems better to deliver something more up-to-date when
possible.

Tom