Arrays.copyOf does not work with value type arrays

Tobias Hartmann tobias.hartmann at
Thu Mar 16 09:58:55 UTC 2017

Thanks John and Mr. Simms for the detailed answer!

I'll leave this for now.

Best regards,

On 15.03.2017 18:48, John Rose wrote:
> On Mar 15, 2017, at 7:51 AM, Tobias Hartmann <tobias.hartmann at> wrote:
>> Hi,
>> I'm looking into C2 intrinsic support for value types and noticed that below code fails with:
>> Exception in thread "main" java.lang.BootstrapMethodError: call site initialization exception
>> 	at java.lang.invoke.CallSite.makeSite(
>> 	at java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(
>> 	at java.lang.invoke.MethodHandleNatives.linkCallSite(
>> 	at Test.main(
>> Caused by: java.lang.ClassNotFoundException: java/util/Arrays$copyOf$433071630$${QPoint;}
>> 	at java.lang.Class.forName0(Native Method)
>> 	at java.lang.Class.forName(
>> 	at java.lang.invoke.GenericStaticDispatch.metafactory(
>> 	at java.lang.invoke.CallSite.makeSite(
>> 	... 3 more
>> Is this supposed to work with MVT1.0?
> This is not supposed to work in MVT1.0 because __ByValue and __Make keywords
> introduce source-level types not present in MVT1.0.  The type "array-of-Q-Point" is
> going to be confusing to existing library code, until it is properly generified.
> (The type "array-of-L-Point" would not be problematic, but it is undesirable since
> each Point is boxed as an L-Point.  Such are the tradeoffs of MVT1.0.)
> MVT1.0 allows the user to work with "flat" arrays of values ("array-of-Q-Foo")
> but *only* through method handles, not directly in source code.
> To get the source code story straightened out, we need to formulate the rules
> for distinguishing "array-of-Q-Foo" from "array-of-L-Foo".  The latter type, is
> relatively useless and perhaps can be omitted totally, but I think that legacy
> code might have an occasional need to work with it.  In any case it's an open
> issue, and MVT1.0 avoids it.
> — John

More information about the valhalla-dev mailing list