This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: invokespecial on abstract method
- From: Jeff Sturm <jsturm at one-point dot com>
- To: Bryce McKinlay <bryce at mckinlay dot net dot nz>
- Cc: Andrew Haley <aph at redhat dot com>, Christian Stuellenberg <gcj at stuellenberg dot de>, <java at gcc dot gnu dot org>
- Date: Fri, 3 Oct 2003 00:05:23 -0400 (EDT)
- Subject: Re: invokespecial on abstract method
On Fri, 3 Oct 2003, Bryce McKinlay wrote:
> > 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.
ant.jar is a fine example. No user can reasonably expect to have all the
external classes referenced by ant.jar on their system. Some of them are
proprietary and not freely available.
> 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.
I know this has been discussed before but I'll chime in once again to say
I can't agree more. Even if you can pull together all the classes you
need to completely link a large application before execution, you may have
eroded the startup time and memory size savings that are among the chief
advantages of using gcj in the first place!
A JIT can do well on such applications because it doesn't do more work
(compiling and linking) than necessary at any point of execution.
Jeff