Re: [hibernate-dev] HHH-9440 Support for Java 8: parameter names

Look at usages of Instantiator interface On Thu, May 5, 2016, 2:08 PM Lovro Pandzic <lovro.pandzic(a)gmail.com&gt; wrote: > Sorry for late reply. > > > Well you mentioned Java 8 parameters names in the subject. I have no >> idea what "Java 8 parameter names" might mean outside of the support added >> in Java 8 for named parameter binding. So if that's not what you mean, >> what do you mean? >> >> Based on some of your other replies, perhaps you are confusing >> "parameter names" (PreparedStatement) and "column names" (ResultSet)? >> > > I mean the Java 8 Parameter Names API - > https://docs.oracle.com/javase/tutorial/reflect/member/methodparameterref... > . > So the basic idea is, if you know to which fields to inject the value, > you also know into which parameter the value should be injected. > > I must say I'm not familiar with Hibernate ORM codebase so any clues > where to start looking would be helpful. Right now I'm searching for usages > of Class#newInstance and starting from there. > > On Thu, Mar 31, 2016 at 2:05 PM, Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> On Mon, Mar 28, 2016 at 1:22 PM Lovro Pandzic <lovro.pandzic(a)gmail.com&gt; >> wrote: >> >>> I am confused how you are "mind mapping" PreparedStatement parameters >>>> and entity construction into the same conversation. We are not >>>> instantiating entities based on PreparedStatement parameters.... >>>> >>> >>> I'm not sure I understand you, I haven't mentioned PreparedStatement >>> parameters anywhere. >>> >> >> Well you mentioned Java 8 parameters names in the subject. I have no >> idea what "Java 8 parameter names" might mean outside of the support added >> in Java 8 for named parameter binding. So if that's not what you mean, >> what do you mean? >> >> Based on some of your other replies, perhaps you are confusing >> "parameter names" (PreparedStatement) and "column names" (ResultSet)? >> >> >> What you propose is to delay the entity instantiation and create the >>>> entity instance from after we have the hydrated state. >>> >>> >>> Yes, the requirement for this to work is that before calling >>> constructor you have all arguments and target parameter names available. >>> >> >> Right, which precludes lazy loading; which is my point on the Jira. >> > >