This is the mail archive of the java@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: libgcj maintenance for 4.0.x branch


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


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