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: Binary Compatibility


Tom Tromey writes:
 > >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
 > 
 > Andrew> Before we do anything else, I think we need a Binary
 > Andrew> Compatibility Testsuite.
 > 
 > Great idea.  There are a few tests for this sort of thing in Jacks.
 > However, I don't think they are exhaustive.

I suppose (darn it!) that I'll have to write this stuff in dejaGNU. 

The trouble at the moment is that I'm not sure that I understand all
the summary items in that table.  I guess I'll write a test case for
each of the items that I *do* understand and ask on the list for
clarification of the others.

 > Andrew> One question: do we think that Binary Compatibility issues will arise
 > Andrew> when referencing compiled Java code from CNI C++ code?  Personally, I
 > Andrew> think that such issues are outside the scope of Java binary
 > Andrew> compatibility, so CNI code can continue to reference Java methods as
 > Andrew> at present.
 > 
 > Unfortunately, I think it does matter.
 > 
 > First, I think one of our goals is to be able to actually promise
 > binary compatibility to our users. One thing this means to me is
 > that a third party could ship a library compiled with e.g.) gcj
 > 3.5, and still expect it to work without recompilation with gcj
 > 3.6.
 > 
 > If a library like this contains any CNI code, that goal will only
 > be achievable if g++ also implements the binary compatibility ABI.
 > For instance the size of some base class might change, or a new
 > virtual function added somewhere in the core classes.  (As a
 > thought experiment, what if we add a new field and virtual method
 > to Object?)

Oh, alright.  I see what you mean.

We could perhaps limit what kinds of access are permitted from CNI
code.  No access to static data fields, for example.  That might work.

 > Another choice would be to simply require people wanting this
 > feature to use JNI, which does make these promises.  This isn't
 > entirely unreasonable.
 > 
 > I suspect the decision will lie with the g++ maintainers anyway.
 > Would they even accept a change like this?

In my experience they've been very helpful.  If we say "look, gcj
really needs this" they'll probably accept it.  Although my experience
with null pointer checking wasn't good, I grant you...

Andrew.


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