This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
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.