AdapterMethodHandle not found

Pete Brunet peter.brunet at
Tue May 7 21:10:29 UTC 2013

If I clone the current code, where to I find the equivalent import?  I
have been going to and looking for the
highest numbered 7u directory, 7u80 in this case.  I just sorted the jdk
directory by date though and I see 7u40 has a more recent date.  But
that might not be reliable because the sort shows this order, starting
with most recent: 7u40, 7u22, 7u23, 7u45, 7u18, 7u19, ...


On 5/7/13 3:13 PM, Kelly O'Hair wrote:
> On May 7, 2013, at 1:59 AM, Volker Simonis wrote:
>> On Tue, May 7, 2013 at 3:10 AM, Pete Brunet <peter.brunet at> 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.
> That IS the way IMPORT_JDK is defined, it must be a recent JDK build, anything else can be unreliable.
> Any flag day changes (like jdk<->vm interface changes) will mess you up.
> I thought that was well documented somewhere.
> -kto
>> 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 ' 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:
>>>> Regards
>>>> Volker
>>>> On Sat, May 4, 2013 at 5:40 AM, John Rose <john.r.rose at>
>>> wrote:
>>>>> On May 3, 2013, at 8:42 AM, Pete Brunet <peter.brunet at>
>>> 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

More information about the build-dev mailing list