RFR: JEP 359-Records: reflection code

[Brian Goetz]

I think there’s something in between “specific to records” and “general building block”. 

It definitely, 100% was intended to NOT be specific to records.  But, it is still not general, in the sense that no human user will ever call this API.  So it is (or should be) optimized for what makes sense from a runtime performance / class file impact perspective.  100% of the clients of this API will be compilers and frameworks.  It may well be used by Javac for value types, and could be used by other language compilers as well.  So that’s the target profile we’re aiming at.  

> On Oct 22, 2019, at 6:01 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> But, if this is meant to be a general building block, then I don't understand e.g. why we are unifying all the signatures. If a client wants hashCode, I think it is kind of a design flaw that (i) there's no such BSM with that name (the BSM is just called "bootstrap") and (ii) that there still a requirement to pass a 'name list', which is ignored by the BSM.
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20191022/3a21e544/attachment.html>