Have proxies generated by ByteBuddy to conform to legacy naming strategies
Description
Activity
Steve Ebersole April 17, 2018 at 5:19 PM
Just a clarification... we don't really "encourage people to move on [to the new naming scheme]". Using the name of generated classes for matching, we all agree, is a bad idea - and more importantly, it is not supported. Here, e.g., it would have been far better (and just as easy) to see if the thing implemented HibernateProxy (which does not require linking to Hibernate, btw).
Sanne Grinovero April 17, 2018 at 5:16 PM
We chatted about this on IRC. Conclusion:
Hibernate ORM 5.3 will use the new naming scheme by default to encourage people to move on
An opt-in setting is made available to make it use "legacy compatible classnames"
When such option is enabled a WARN is logged via a new
UnsupportedLogger
Sanne Grinovero April 17, 2018 at 4:11 PM
ok right that's trivial then, I've introduced the property.
But are you suggesting that by default it should not use the backwards compatible (legacy) naming scheme? You want me to have people need to explicitly opt in, and log a WARN ?
I was initially planning to simply change the naming scheme to avoid trouble for anyone - and at the same time suggest to the Spring team that they shouldn't rely on this in ORM6 - yet not make explicit plans to break it either.
Steve Ebersole April 17, 2018 at 11:48 AM
any thoughts on my last comment?
I should have been more explicit on how... those 2 "sources" of config properties are available via Environment#getProperties
Steve Ebersole April 16, 2018 at 1:28 PM
Yes, but BytecodeProvider itself is resolved statically. See org.hibernate.cfg.Environment#BYTECODE_PROVIDER_INSTANCE. So effectively, atm, one can only chose a BytecodeProvider via:
System property
`/hibernate.properties`
So having a static config setting for BytecodeProvider is perfectly reasonable.
We should take in consideration the suggestion at https://jira.spring.io/browse/SPR-16569?focusedCommentId=157776&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-157776
Essentially it seems that proxies being generated now by Byte Buddy can't be recognized by Spring as proxies, as they used to look for "$$" in the generated classnames.
Would be great to be able to restore the naming convention, at least for the foreseable future. I'm not sure if we should commit on that naming strategy for the long term, let's talk about that.
My primary concern for the long term is that this would disable "short string representation" for the class metadata in the JVM; I realize this might sound far fetched as there's a lot more fat that should be cut first, but since we're aggressively trimming in such areas, such names being compact might become a priority too.