[PROPOSAL][JDK10] Introduce Executable.getParameterType(index)

[Claes Redestad]

On 2017-11-03 14:17, Alan Bateman wrote:
> On 03/11/2017 08:11, Christoph Dreis wrote:
>> Hi John,
>>
>>>> this has a bigger impact on the overall footprint of 
>>>> Method/Executable objects. What are your thoughts on this?
>>> The footprint is probably about the same.  Small List.of values
>>> do not contain arrays, and may be smaller than arrays with the
>>> same number of elements, since they do not have a length field.
>>> And, indeed, methods typically have a small number of parameters.
>> Ah, so you would remove the current array field completely and 
>> replace it with the immutable List, right?
>> In that case I said nothing. I was thinking of a field on top.
>>
> The VM creates Method objects and sets the fields, including 
> parameterTypes, directly so I think removing it would require more 
> work than it initially looks. If you add a field then it does increase 
> the footprint a bit. Alternatively, have the method could use a 
> ImmutableCollection.ListN like implementation that is backed by the 
> array and doesn't scan it for nulls at create time, this wouldn't be 
> completely allocation free of course.

While it would be pretty sweet if we could train the VM to use List.of 
as appropriate (might be applicable in a number of places where we want 
to communicate immutable array-like data from the VM), it should be 
pretty straightforward to change the interaction so that the VM calls a 
private method that takes the parameter array and turns it into a List.

My guess is that the superfluous null checking will be hardly measurable 
even in micros.

> In any case, the proposed API does look reasonable although it 
> deviations from the usual conventions in java.lang.reflect.

I agree the getParameterType(index) method should still up for 
consideration if we can't act on the more elegant proposal to turn 
things into Lists in a reasonable time-frame.

/Claes