Arrays.copyOf does not work with value type arrays
Tobias Hartmann
tobias.hartmann at oracle.com
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,
Tobias
On 15.03.2017 18:48, John Rose wrote:
> On Mar 15, 2017, at 7:51 AM, Tobias Hartmann <tobias.hartmann at oracle.com> 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(CallSite.java:347)
>> at java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:247)
>> at java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:237)
>> at Test.main(Test.java:23)
>> Caused by: java.lang.ClassNotFoundException: java/util/Arrays$copyOf$433071630$${QPoint;}
>> at java.lang.Class.forName0(Native Method)
>> at java.lang.Class.forName(Class.java:372)
>> at java.lang.invoke.GenericStaticDispatch.metafactory(GenericStaticDispatch.java:14)
>> at java.lang.invoke.CallSite.makeSite(CallSite.java:308)
>> ... 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