Investigate allowing registry-scoped declaration of BytecodeProvider

Description

Historically this is a VM-wide setting. With the split in boot-strapping into the registry phase prior to any MetadataSources processing, it is possible we could make this scoped to the registry.

We should at at least investigate if that works.

Possibly org.hibernate.cfg.Environment#useReflectionOptimizer and org.hibernate.cfg.Environment#useStreamsForBinary as well.

Environment

None

Activity

Show:
Steve Ebersole
December 30, 2017, 5:05 PM

In my working solution for this, I was able to simply deprecate org.hibernate.cfg.Environment#useStreamsForBinary and org.hibernate.cfg.Environment#useReflectionOptimizer. They are simple boolean flags, so they are not expensive to keep around.

Ideally we'd simply remove org.hibernate.cfg.Environment#getBytecodeProvider. It is potentially expensive to hold around another instance of a BytecodeProvider that is just not used.

Another concern with leaving any of them is that they are all return potentially incorrect information. Since they are all static methods, they all are still VM-wide. However, this work allows these values to be scoped to a specific Metadata/SessionFactory.

To me the only real options are to either:

  1. Leave these as VM-scoped (exposed statically from Environment) and deprecate the methods with an eye on fixing this in 6.0, or

  2. Drop the methods from Environment

Assignee

Unassigned

Reporter

Steve Ebersole

Fix versions

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Priority

Major
Configure