On 15.11.2017 6:19, Paul Sandoz wrote:
On 10 Nov 2017, at 01:36, stanislav lukyanov <stanislav.lukya...@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?
TBD_Minor would mean an update release, right?
I think it can't be a TBD_Minor then since it is technically a
specification change and should happen in a Java SE release (maybe 11?),
but maybe I'm wrong.
Anyway, as long as that's logged and not completely forgotten, I'm happy :)
Thanks,
Stas
<...>
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.
