RFR: JEP 359-Records: reflection code

[Maurizio Cimadamore]

> If the code is kept this way I suggest at least replacing assert with 
> a runtime exception (throw new AssertionError). E.g. I'm fine with 
> assert keywords when it comes to checking invariants that are under 
> control of the implementation (in which case, you run tests with 
> assertion enabled to shake possible issues); but in this case the 
> invariant depends on what names string the client has passed to the 
> BSM, so I think some real validation is in order here.

My bad - there is a real validation, in the main BSM code:

if (nameList.size() != getterList.size())
  342                     throw new IllegalArgumentException("Name list and accessor list do not match");


So, the plain assert is fine in the toString impl.

Maurizio


> Maurizio
>
>
> On 22/10/2019 03:40, Vicente Romero wrote:
>>
>>
>> On 10/21/19 6:32 PM, Maurizio Cimadamore wrote:
>>>
>>> On 21/10/2019 23:02, Remi Forax wrote:
>>>> - the same call works for equals/hashCode and toString, so 
>>>> depending on the methods some arguments are not used or not
>>>
>>> I too found this a bit odd when looking at the javac code - it took 
>>> me sometime to figure out what was going on.
>>>
>>> The question I have here is - is the decision of having a single 
>>> point a deliberate decision that we think it's going to pay off in 
>>> the long run? 
>>
>> it was a deliberate decision, the first implementation actually had 
>> different bootstrap methods but then we got a table with three 
>> bootstrap methods per every humble record, so having only one 
>> bootstrap method is a space gain.
>>> Or was it more a way to quickly bootstrap the javac implementation? 
>>> If the latter, we should probably revert to one bootstrap per Object 
>>> method.
>>>
>>> Maurizio
>>>
>> Vicente