libgcj maintenance for 4.0.x branch

Fri Apr 15 20:35:00 GMT 2005

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