libgcj maintenance for 4.0.x branch

[David Daney]

Tom Tromey wrote:
>>>>>>"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.

Fine with me.
> 
> 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).

The C++ ABI is too brittle for this rule I think.  It seems possible 
that the best (and perhaps only) way to fix some things will be to break 
backwards compatibility.  If we adhere to this we would be in a position 
of saying we cannot fix a regression because it would break the rule.

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

Perhaps few complaints were made public.  I complain to myself about 
this often.  My current libgcj-3.4.3 has large portions back ported from 
4.0 (and large portions eliminated as well).

GCJ is becomming less of a toy.  That is good.

David Daney