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


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

Regards

Bryce.



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