ORM 6 : hibernate-orm-modules & Antlr 4
by Steve Ebersole
I am working on re-enabling the `hibernate-orm-modules` module but am
running into a problem being able to resolve Antlr 4 classes. I'm sure the
problem is related to the entry `<module name="org.antlr"/>` in
`hibernate-core.xml` but I am not sure how to fix that. Any ideas?
5 years, 10 months
Jakarta EE: JPA 3.0 is coming
by Sanne Grinovero
Hi all,
as a consequence of having moved all Java EE technologies to the
Jakarta EE project at the Eclipse foundation, the API needs to change
so to address the Oracle trademark requirements.
The new JPA project lives here:
- https://github.com/eclipse-ee4j/jpa-api
For context, to make it simpler for people to adopt the new API the
Jakarta EE team decided to not allow any other change to the API; this
would make it possible for people to migrate their existing code bases
by running a simple "search and replace all". This implies that even
though it's a new major version, it's sadly not a good time to
challenge any API or spec working as this is intentionally frozen.
And (our very own!) Scott Marlow helped with the primary change, which
you can see here having quite an impact:
- https://github.com/eclipse-ee4j/jpa-api/pull/231
It's just a small change of renaming all packages "javax.persistence"
to "jakarta.persistence" .. but it has wide impact all over.
We should start thinking how to make support for JPA 3 happen in
Hibernate ORM; there's of course many options, but we need to take
into account some points:
1)We can't spend years of brilliant minds on this
2)We don't want to make the migration too hard to users
3)We normally promise backwards compatibility within minor releases of
our projects
4)While Hibernate ORM 6 is making great progress, it's a very large
quest to finish it. It's not wise to try to time-box it, while we
might need to deliver JPA 3 at some (TBD) reasonable deadline.
5)Whatever we do, it shall not have a major burden on the team working
on ORM6 as that's our most important project.
I hope we agree on these points?
So I think I will spend some time exploring the fesability of a JPA
3.0 in some 5.x branch, while aiming at maintaining backwards
compatibility.
To address requirement 1# , I'll just explore this without making a
commitment to the plan.. also I think it would be interesting to
explore a partial migration, for example I suppose it might be
possible for us to "accept" the use of mapping annotations from JPA
3.0 (on top of the ones from JPA 2.0) while not exposing the full
proper API yet.
Considering the API is literally the same contract, if you except the
package name, it might be feasible to expose the full JPA 3.0 in a
backwards compatible way as well but this might require:
- use of bridge methods, e.g. bytecode manipulation at build time [1]
- depend on both JPA API packages
In particular I wonder, how would you all feel if (for example)
Hibernate ORM 5.5.x were to depend on both JPA 2 and JPA 3 API
artifacts?
And additional change to take into account is that the JPA3 API now
defines a module-info resource; it would be nice to try taking
advantage of that but it's of course more complicated if we have a
hybrid JPA 2/3 implementation. I guess that aspect will have to wait
for ORM6, but also that ORM6 being rebased on this work could benefit
from using the JPA3 groundwork.
Thanks,
Sanne
1 - https://github.com/dmlloyd/bridger
5 years, 10 months
Custom EventType and listeners
by Gail Badner
There has been some discussion that it may be useful for hibernate-rx to be
able to define RX-specific event types and listeners.
I've created a POC [1] that adds this support. I still need to do some
testing, but I would like some feedback before I spend too much time on
this.
Please let me know if this is a reasonable improvement. If it is, I will
create an HHH jira and create a pull request.
Thanks,
Gail
[1]
https://github.com/gbadner/hibernate-core/commit/2d368a2ce1da36468ab7f965...
5 years, 10 months
