5.3 finalization plan
by Steve Ebersole
In 2 weeks I will be releasing 5.3 CR2. I waned to start a unified
discussion about the remaining currently unresolved discussions and what
exactly we are going to do for 5.3 mainly in regards to compatibility with
an eye to 6.0
Cache region-name as exposed in API/SPI
This one is a "sneaky" compatibility concern. When discussing this, it
seems like we had a consensus that the way this should work is for the name
passed in to be un-prefixed. Unfortunately the current behavior is to
accept the qualified region name. IMO we should change this. However,
there is a big danger in that : it would introduce a run-time behavior
incompatibility, as opposed to a compile one, which in a way is worse. See
the new test I just added to master for examples of what I mean
- org.hibernate.test.cache.RegionNameTest
One option for compatibility is to introduce a new compatibility flag for
this. Something like "hibernate.cache.region_name_api_prefixed"
(true/false). Or a better way might be to accept either, and to avoid the
extra perf hit of add a new setting to disallow calls with the prefixed
name.
Also Sanne brought up the idea of ORM simply no longer dealing with prefix
(this is at odds with the current API/SPI calls as tested).
Other thoughts/ideas?
Caching
It was decided to include HHH-11356[1] (cache SPI redesign) in 5.3. See
the Jira for details.
Statistics (caching)
HHH-11356 redefines how regions and access strategies are structured,
related and accessed. I won't get too in to the details here (read the
Jira if interested) but that required changes to other code that uses the
SPI. Most of those are internal and were easy to adjust. However
Statistics, as a consumer of these regions and access strategies, also
required some changes. HHH-12323[2] is the Jira for these changes.
Again the see the Jira for details.
Type System
The other major change for 6.0 is the metamodel, type system change. This
one is pervasive. All of the strategies to bridge Type and read-by-name /
read-by-position, imo, are not feasible.
The changes in the run-time metamodel are too much to bridge, which is a
complicating factor. Right down to PersisterFactory.
P.S. where there is already a Jira it would be best if we can keep the
discussions on the Jira itself.
[1] https://hibernate.atlassian.net/browse/HHH-11356
[2] https://hibernate.atlassian.net/browse/HHH-11356
7 years, 9 months
HHH-12353: have getReference stick to the Java API it promises?
by Sanne Grinovero
Issue HHH-12353 was just reported and I have to agree it looks dodgy.
Essentially invoking:
entityManager.getReference( Person.class )
might not return a type compatible with Person, when Person is final
and annotated with @Proxy(proxyClass = AnotherTypeX.class), then
AnotherTypeX might be returned and this is not necessarily a subtype
of Person.
That's ok as I understand we hardly have alternatives, but the
EntityManager API for getReference mandates this signature:
<T> T getReference(Class<T> entityClass, Object primaryKey)
so we're not actually returning the expected type T in all
circumstances, confusing compilers and tooling into giving the wrong
suggestions.
I see some options:
a# disallow using @Proxy on a final entity - seems reasonable since
the docs warn against pitfalls.
b# throw an exception on Person.class being used as parameter, as the
user should actually use the proxytype?
c# somehow have the proxy still extend the final entity?
Option b# seems problematic as it's not obvious to users either, and
we would need to return a proxy reference even when there actually is
a managed Person instance in the current session.
Option c# is probably unrealistic and problematic too, as it would
require enhancing of the final class and I guess we can't rely on that
consistently.
In summary, I believe we should throw a bootstrap exception requiring
to remove the `final` modifier on the parent entity. Or challenge the
specification :(
Thanks,
Sanne
7 years, 9 months
Re: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly?
by Guillaume Smet
Hi Christian,
On Mon, Mar 5, 2018 at 2:15 PM, Christian Beikov <christian.beikov(a)gmail.com
> wrote:
>
> I have a fix for the NPE the user reported, but there is one edge case,
> which hasn't been rerported yet as it seems exotic, that I am still trying
> to figure out.
> I can provide the "partial fix" later today if you like, but I'd prefer to
> fix the overall problem before releasing.
>
I'd say let's try to have a proper global fix, but if it's too long to get
the right fix, let's revisit this decision.
Just MHO, let's wait for Steve and the others.
--
Guillaume
7 years, 9 months
NoORM - Improve consistency of our pom files with JBoss parent and WildFly parent
by Guillaume Smet
Hi,
So, I started the effort of making our version properties consistent with
JBoss parent/WildFly parent with Search but the idea is to generalize this
to all our NoORM projects and be as consistent as possible between the
projects.
The idea is to, as much as possible, use the exact same notation as the
other JBoss projects when declaring the version properties of our
dependencies
You can see what it implies in this diff:
https://github.com/hibernate/hibernate-search/pull/1639/files#diff-600376...
So, from now on, when you need to add new dependencies in Search:
- check if JBoss parent or WildFly parent already contains this dependency,
if so use the exact same property name
- if not, use <version.full.package.name> if it is descriptive and
discriminating enough
- if the package name is used for several artifacts or is not descriptive
enough, use <version.full.package.name.artifact-id>
My plan is to be done with OGM in 2 weeks and do it for HV 6.1 as I don't
want to do it in a micro.
So please avoid big pom refactorings in OGM for the next 2 weeks.
Dependency upgrades are OK, I'll merge them along the way.
Thanks!
--
Guillaume
7 years, 9 months
Null-Pointer Exception with 5.2.14
by Petar Tahchiev
Hi guys,
I have this exception with latest 5.2.14 (my project runs fine with 5.2.13):
Caused by: javax.persistence.PersistenceException: [PersistenceUnit:
default] Unable to build Hibernate SessionFactory
at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:970)
at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:895)
at
org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:57)
at
org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:365)
at
org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.buildNativeEntityManagerFactory(AbstractEntityManagerFactoryBean.java:387)
at
org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:376)
at
org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.afterPropertiesSet(LocalContainerEntityManagerFactoryBean.java:341)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1769)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1706)
... 32 more
Caused by: org.hibernate.MappingException: Could not instantiate persister
org.hibernate.persister.entity.SingleTableEntityPersister
at
org.hibernate.persister.internal.PersisterFactoryImpl.createEntityPersister(PersisterFactoryImpl.java:112)
at
org.hibernate.persister.internal.PersisterFactoryImpl.createEntityPersister(PersisterFactoryImpl.java:77)
at
org.hibernate.metamodel.internal.MetamodelImpl.initialize(MetamodelImpl.java:128)
at
org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:300)
at
org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:460)
at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:892)
... 39 more
Caused by: java.lang.NullPointerException
at
org.hibernate.persister.entity.AbstractPropertyMapping.getSuperCollection(AbstractPropertyMapping.java:285)
at
org.hibernate.persister.entity.AbstractPropertyMapping.addPropertyPath(AbstractPropertyMapping.java:198)
at
org.hibernate.persister.entity.AbstractPropertyMapping.initPropertyPaths(AbstractPropertyMapping.java:395)
at
org.hibernate.persister.entity.AbstractEntityPersister.initOrdinaryPropertyPaths(AbstractEntityPersister.java:2300)
at
org.hibernate.persister.entity.AbstractEntityPersister.initPropertyPaths(AbstractEntityPersister.java:2347)
at
org.hibernate.persister.entity.AbstractEntityPersister.postConstruct(AbstractEntityPersister.java:3906)
at
org.hibernate.persister.entity.SingleTableEntityPersister.<init>(SingleTableEntityPersister.java:437)
at sun.reflect.GeneratedConstructorAccessor94.newInstance(Unknown
Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at
org.hibernate.persister.internal.PersisterFactoryImpl.createEntityPersister(PersisterFactoryImpl.java:96)
... 44 more
--
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
7 years, 9 months
HHH-11223 : Initialize bytecode enhanced lazy group using a single SQL statement
by Gail Badner
Hi,
Currently, when a lazy group is loaded that has associations, there are 2
SQL statements executed.
For example, suppose the DEFAULT lazy group contains the following:
* Order#customer is a lazy many-to-one association;
* Order#text is a lazy LOB.
When one of these properties is referenced, Hibernate loads both of them.
Currently, it takes 2 SQL statements to get the association loaded.
1) Loads #text and the FK value for #customer (select o.text, o.customer_id
from orders o where o.id = ?)
2) Loads the state for #customer (select ... from customers c where c.id =
?)
In other words, FetchMode.SELECT is used to load associations in a lazy
group.
HHH-11223 involves combining the 2 SQL statements into a single statement
using a join (i.e., using FetchMode.JOIN), but only when at least one of
the following is true:
* caching is disabled for the SessionFactory (e.g., hibernate.cache.use_sec
ond_level_cache=false;
* caching is not enabled for "get" operations (i.e.,
session.getCacheMode().isGetEnabled() == false);
* the associated entity type (and subclasses?) is not cached
HHH-11223 only mentions to-one associations, but I think collections in a
lazy group could also be loaded using a join as well.
I think I'm pretty close, but I need to do a lot more testing to ensure it
covers things like:
* lazy association in composite ID
* lazy association in an embeddable
* lazy association in a secondary table
* lazy association in a subclass
* too many bags
This is what I have implemented so far:
https://github.com/hibernate/hibernate-orm/pull/2170
At the moment, I'm not looking for a comprehensive review. I'm just looking
for a review of the overall design.
I don't want to get into the nitty-gritty here, but, basically, I've
created a new type of AbstractLoadPlanBasedEntityLoader, LazyGroupLoader,
which loads the lazy group properties into the existing entity.
If caching is disabled for the SessionFactory, then one loader is
constructed per lazy group, and associations will be loaded using
FetchMode.JOIN.
If caching is enabled for the SessionFactory, then 2 loaders are
constructed per lazy group. One loader is used when caching is enabled for
"get" operations (using Fetch.SELECT for cached associated
entities/collections; Fetch.JOIN for other associations). The other loader
is used when caching is disabled for "get" operations.
Here are some of the changes to the default behavior (described above) that
could be useful:
1) Change all associations in lazy groups to be loaded using
FetchMode.SELECT (as is currently done without the fix), or using
FetchMode.JOIN (regardless of caching). A new configuration property could
be added:
hibernate.bytecode.lazyGroup_association_fetchMode=(default | select | join
)
2) Allow the FetchMode to be configured for a particular lazy association.
According to the documentation [1], @Fetch can't be used for this because,
"... FetchMode.JOIN acts as a FetchType.EAGER strategy. Even if we mark the
association as FetchType.LAZY, the FetchMode.JOIN will load the association
eagerly."
A new annotation could be introduced: @LazyFetch.
Comments or suggestions?
Thanks,
Gail
[1] http://docs.jboss.org/hibernate/orm/5.2/userguide/
html_single/Hibernate_User_Guide.html#fetching-fetchmode-join
7 years, 9 months
JDK 10: Release Candidate & JDK 11 Early Access builds available
by Rory O'Donnell
Hi Sanne,
*JDK 10 build 45 is our JDK 10 Release Candidate and now available at
http://jdk.java.net/10/*
* Schedule, status & features
o http://openjdk.java.net/projects/jdk/10/
* Release Notes
o http://jdk.java.net/10/release-notes
* Summary of changes in b45:
o JDK-8198658 <https://bugs.openjdk.java.net/browse/JDK-8198658> -
Docs still point to JDK 9 docs
*JDK 11 EA build 3, under both the GPL and Oracle EA licenses, are now
available at **http://jdk.java.net/11**.*
* Schedule, status & features
o http://openjdk.java.net/projects/jdk/11/
* Release Notes:
o http://jdk.java.net/11/release-notes
* Summary of changes
o https://download.java.net/java/early_access/jdk11/2/jdk-11+2.html
* JEPs targeted to JDK 11, so far
o 309: Dynamic Class-File Constants <http://openjdk.java.net/jeps/309>
o 318: Epsilon: An Arbitrarily Low-Overhead Garbage Collector
<http://openjdk.java.net/jeps/318>
o *320: **Remove the Java EE and CORBA Modules
<http://openjdk.java.net/jeps/320>*
**
+ ** *This build includes JEP 320, so build is significantly
smaller (nine fewer modules, 22 fewer megabyteson Linux/x64).*
o 323: Local-Variable Syntax for Lambda Parameters
<http://openjdk.java.net/jeps/323>
* Open Source Project fixes in JDK 11 build 1
o JDK-8195096 <https://bugs.openjdk.java.net/browse/JDK-8195096>-
Apache Tomcat
+ Exception with custom LogManager on starting Apache Tomcat
o JDK-8193802 <https://bugs.openjdk.java.net/browse/JDK-8193802>-
Apache Maven
+ NullPointerException from JarFileSystem.getVersionMap()
o JDK-8191842 <https://bugs.openjdk.java.net/browse/JDK-8191842> -
jOOQ
+ JShell: Inferred type information is lost when assigning
types to a "var"
Finally, the Crypto roadmap
<https://www.java.com/en/jre-jdk-cryptoroadmap.html> was updated -
23-Feb-2018**
**
* Add support for AEAD TLS Cipher Suites
o Target date changed from 2018-04-17 to 2018-07-17
Regards,
Rory
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
7 years, 9 months
Introduce OperationContext in 5.3?
by Gail Badner
Hi,
HHH-10478 is currently scheduled for 6.0.0.alpha1. What do you think about
introducing it into 5.3.0 instead?
Using an OperationContext would be a less hacky way to fix HHH-3799
(PersistentSet does not honor hashcode/equals contract when loaded eagerly).
It would be nice to remove operation-specific fields from
StatefulPersistenceContext:
private int cascading;
private int loadCounter;
private int removeOrphanBeforeUpdatesCounter;
private boolean flushing;
private boolean defaultReadOnly;
private boolean hasNonReadOnlyEntities;
private LoadContexts loadContexts;
Without using an Operation context, the fix for HHH-3799would add something
like:
private boolean isEntityLoading;
Regards,
Gail
7 years, 9 months
Byte-buddy: default enhancer in 5.3 ? [HHH-11253]
by Sanne Grinovero
HHH-11253 is about making ByteBuddy the default implementation, but
it's flagged for 6.
I think that in Paris there was consensus to make it the default in
5.3 alredy, to possibly drop Javassist entirely in 6.0.
May I change this to 6 ? If that's ok, I can assign it to myself.
Thanks,
Sanne
7 years, 9 months