AdapterMethodHandle not found

[Volker Simonis]

On Tue, May 7, 2013 at 3:10 AM, Pete Brunet <peter.brunet at oracle.com> wrote:

> I tried changing my ALT_BOOTDIR from my normal 64 bit 7u21 installation
> to the 7u80 tarball I extracted, but got:
> make[2]: *** No rule to make target
> `../../../build/windows-i586/btjars/addjsum.jar', needed by
> `../../../build/windows-i586/lib/classlist'.  Stop.
>
> FWIW, my ALT_JDK_IMPORT_PATH points at 7u80.
>
>
Using an IMPORT_JDK has become quite tricky and it seems that it only works
reliable if you use a build of the exact same version you are building as
import jdk.

Just yesterday I had a similar problem with JDK8 where I used a 4 weeks old
import jdk to build a brand new version of the 'jdk' forest. It failed
because during the build  the VM from the import JDK is used together with
the newly build jdk classes but there was a mismatch in the unsafe
primitives requested by the Unsafe class and those provided by the VM.

So the interface between the HotSpot VM and the class library has become
quite volatile (and it is still not documented anywhere:(


> I changed my ALT_BOOTDIR back to 7u21 and did a full build, not just
> jdk, and after a three hour build time all is well.
>
> Pete
>
> On 5/6/13 3:38 AM, Volker Simonis wrote:
> > What does "../../../../build/windows-i586/bin/java -version" return?
> > That must be HotSpot 24 (i.e. something like '..build 24.0-b34..').
> >
> > How did you specify your boot-jdk? Maybe you didn't really build a new
> > hotspot but imported it from the boot-jdk and that was too old?
> >
> > If you want you can compare your build logs with our nightly build
> > logs of jdk7u on windows
> > at:
> http://cr.openjdk.java.net/~simonis/ppc-aix-port/logs/NTAMD64/nightly/output-jdk7u-fastdebug.log.gz
> >
> > Regards
> > Volker
> >
> >
> > On Sat, May 4, 2013 at 5:40 AM, John Rose <john.r.rose at oracle.com>
> wrote:
> >> On May 3, 2013, at 8:42 AM, Pete Brunet <peter.brunet at oracle.com>
> wrote:
> >>
> >>> Error occurred during initialization of VM
> >>> java/lang/NoClassDefFoundError: java/lang/invoke/AdapterMethodHandle
> >> It's a micro-version mismatch, from running a down-rev JVM on an up-rev
> rt.jar (JDK).
> >>
> >> But I don't understand why your makefile is running an old JVM on a new
> rt.jar.  That's build voodoo, I presume.
> >>
> >> — John
>
>