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: invokespecial on abstract method


Bryce McKinlay writes:
 > On Friday, Oct 3, 2003, at 04:33 Pacific/Auckland, Andrew Haley wrote:
 > 
 > > Christian Stuellenberg writes:
 > >>
 > >> An invokespecial to an abstract method should throw a
 > >> java.lang.AbstractMethodError at execution time (as e.g. an JVM-1.3
 > >> does), but I'm not able to compile this with gcj.
 > >
 > > I'm in favour of errors being detected early.  One of the features of
 > > gcj, and it's arguable whether it's good or bad, is that we get errors
 > > for missing methods at link time.
 > 
 > Although early link errors are nice in theory, in practice a great many 
 > .jars are linked against various classes that may not be present on the 
 > system at runtime. In order to compile and run these .jars, GCJ needs 
 > to be able to defer the linkage until actual use, as per the JLS spec - 
 > hence one of the reasons for the BC-ABI.

Right.  But that leads to the nasty problem of runtime errors.  Sure,
we have to permit this, but it in no way represents good software
engineering practice.

That's why I said "it's arguable".  

 > Weighing it up, the problem of not being able to compile bytecode
 > due to missing classes is a much bigger one than getting a
 > ClassNotFoundException at runtime because you forgot to link
 > something in.

Well, maybe.  If you were doing something critical that had to run
24/7 maybe you'd think differently.

 > Java developers are quite capable of making sure all needed classes
 > get into their distributed .jars, and this is no different to
 > making sure those classes get into a binary.

 > I'm sure it wouldn't be hard for Sun to make their VM fully
 > evaluate all linkage before running anything, if they wanted to do
 > that. But by design, Java doesn't.

Right.  But *we* can support both models -- early or late binding.
Another gold star in gcj's favour.

Andrew.


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