RFR 8187742 Minimal set of bootstrap methods for dynamic constants

[Paul Sandoz]

> On 10 Nov 2017, at 01:36, stanislav lukyanov <stanislav.lukyanov at oracle.com> wrote:
> 
> On 10.11.2017 0:13, Paul Sandoz wrote:
>> <...>
>> I would prefer to follow up later on with more non-normative explanatory text. It will take some careful crafting and i don’t want that to side-track the review for the moment (including guidance on what forms of computed constants are acceptable).
> Fair. Does it make sense to add a sub-task for this to JDK-8185992 to keep it on the radar?

You would mind adding a sub-task with a tbd minor target?


>> <...>
>> 
>> And adjusted the invoke method:
>> 
>> * @param args the arguments to pass to the method handle, as if with
>> * {@link MethodHandle#invokeWithArguments}.  Each argument may be
>> * {@code null}.
>> ...
>> * @throws NullPointerException if {@code args} is {@code null}
>> * (each argument of {@code args} may be {@code null}).
> I think the `@throws NPE` is not needed, at least not from the normative perspective.
> The class-level text about NPE doesn't assume anything about the contents of objects passed to the methods,
> and the second part of the `@param args` already clarifies the behavior for this particular case.
> Arguably having this `@throws` might improve clarity, but I would rather remove it.

Ok, if you are fine with that i will remove it.


>> 
>> We have been fleshing out the NPE behaviour because we know you will log bugs against us later on if we don’t :-)
> Yep, that's sounds familiar :)
> 
> <...>
> 
> Thanks for the updates!
> 
> Also, javac isn't going to use `::primitiveClass` instead of `getstatic Integer.TYPE` to load int.class, right?
> If it is, int.class probably needs to be changed to Integer.TYPE in sun.invoke.util.Wrapper to avoid cycles.
> 

Yes, i noticed that too :-)

There are no plans in this patch to update javac code generation for primitive classes but if we do we may need to modify the wrapper implementation as you point out. There are might other areas within the base module (specifically in j.l.invoke) where referring to say int.class may cause class initialization issues early in the startup. That’s awkward (just like we cannot use lambda expressions in certain cases), we might need to retain the old translation strategy just for code within the base module or support a compilation error.

Paul.