This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Untimed resolve ?
- From: Martin Vechev <martin at fadata dot bg>
- To: tromey at redhat dot com
- Cc: java at gcc dot gnu dot org
- Date: Thu, 02 Jan 2003 18:38:27 +0200
- Subject: Re: Untimed resolve ?
- References: <5.1.0.14.0.20021227193130.02e0aa40@mail.fadata.bg><5.1.0.14.0.20021227193130.02e0aa40@mail.fadata.bg>
Yes, I agree, that is what the specification says. I was just thinking
that resolving everything in the constant pool at link stage is not optimal
since the entry might never be used.
Martin.
At 15:50 30.12.2002 'ã.'Conve -0700, you wrote:
>>>>> "Martin" == Martin Vechev <martin@fadata.bg> writes:
Martin> System.out.println("loaded.");
Martin> new X();
Martin> At the end of loading the X class it also resolves it, which
Martin> seems incorrect. Shouldn't it rich the actual 'new' bytecode
Martin> and then throw NoClassDefFoundError.
I don't think this is a requirement.
See JVMS 1st Ed, section 2.16.1:
Linking involves verification, preparation, and (optionally)
resolution.
Later in that section it discusses the possibility of lazily-resolving
and eagerly-resolving runtimes.
At this point I don't think there is a bug here, just a difference. I
believe code relying on one particular implementation here is not
well-defined.
Tom