[hibernate-dev] Making BytecodeProvider no longer be ClassLoader-wide config

[Steve Ebersole]

I started playing around with possibly removing the need for
BytecodeProvider to be configured per-ClassLoader[1].  In fact I got a
working solution for allowing all 3 remaining ClassLoader-wide settings
per-application:


   1. Whether to handle binary/lob data via streams - I was able to make
   this one part of SessionFactoryOptions
   2. Which BytecodeProvider to use.
   3. Whether to use that BytecodeProvider's ReflectionOptimizer

(2) and (3) currently had to be defined on MetadataBuilderOptions because
of the way Metadata is built (it accesses these values way too early).
Ultimately these would be moved to SessionFactoryOptions as well.

However, there is a catch which I have documented[2] and would like to get
everyone's feedback.  Currently I lean towards simply deprecating these
methods on Environment and planning on fixing these in 6.0.  That's what I
will plan unless there is a consensus for the other option.


[1] Earlier I mistakenly said per-VM, but its simply static methods so it
is really per-ClassLoader unless of course the setting is defined as a Java
env var

[2]
https://hibernate.atlassian.net/browse/HHH-12193?focusedCommentId=100814&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-100814


On Fri, Dec 29, 2017 at 2:34 PM Steve Ebersole <steve at hibernate.org> wrote:

> On Fri, Dec 22, 2017 at 5:33 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>>
>> * When using ByteBuddy as the byte code provider, I still needed to have
>>> Javassist around, as it's used in ClassFileArchiveEntryHandler. I
>>> understand that eventually this should be using Jandex, but I'm wondering
>>> whether we could (temporarily) change it to use ASM instead of Javassist
>>> (at least when using ByteBuddy as byte code provider, which is based on
>>> ASM), so people don't need to have Javassist *and* ByteBuddy when using
>>> the
>>> latter as byte code provider? This seems desirable esp. once we move to
>>> ByteBuddy by default.
>>>
>>
>> Yes, Sanne brought this up in Paris and it is something I will look at
>> prior to a 5.3.0.Final
>>
>
> Actually this is different than what Sanne brought up.  I actually cannot
> reproduce what Sanne is reporting.  If I had to guess he was not specifying
> the bytecode provider to use "globally".  This is a special kind of setting
> (we used to have a few) that can only be specified per-VM : either as a
> root `hibernate.properties` or as a System property.  It has to do with how
> Hibernate builds its mapping model, specifically
> `org.hibernate.mapping.Component`.  Given the redesign of the bootstrap
> process we may actually be able to remove that "VM wide" requirement.  I'll
> look into that for 5.3.  BTW Sanne, I created a repo[1] showing that this
> does indeed work when specified "properly".
>


> [1] https://github.com/sebersole/orm-bytebuddy-no-javassist
>