ORM & Java 9 - strange javadoc failure
by Steve Ebersole
I worked on getting Travis CI set up on ORM for reasons discussed here
previously. But I am running into a really strange error when I enabled
Java 9:
javadoc: error - An exception occurred while building a component:
ClassSerializedForm
(com.sun.tools.javac.code.Symbol$CompletionFailure: class file for
org.hibernate.engine.Mapping not found)
Please file a bug against the javadoc tool via the Java bug reporting page
(http://bugreport.java.com) after checking the Bug Database (
http://bugs.java.com)
for duplicates. Include error messages and the following diagnostic in your
report. Thank you.
com.sun.tools.javac.code.Symbol$CompletionFailure: class file for
org.hibernate.engine.Mapping not found
It seems like javadoc is complaining because it sees a reference to a class
(org.hibernate.engine.Mapping) that it cannot find. It is true that there
is no class named org.hibernate.engine.Mapping, the real name is
org.hibernate.engine.spi.Mapping - but what is strange is that I search the
entire ORM project and found zero references to the String
org.hibernate.engine.Mapping.
I just kicked off a run of the ORM / Java 9 Jenkins job to see if it has
the same failure.
Anyone have any ideas?
8 years, 3 months
- 2
- 5
Repository renamed: lucene-modules -> lucene-jbossmodules
by Sanne Grinovero
Hi all,
we renamed the Git repository name, and the respective GitHub project,
from lucene-modules to lucene-jbossmodules.
Obviously "modules" alone was getting a bit too ambiguous.
We decided to not call them "WildFly modules" as these are not used
only for WildFly, and the modular technology is called "JBoss Modules"
[1].
Please don't forget to update your references in any git clone you might have!
Thanks,
Sanne
1- https://jboss-modules.github.io/jboss-modules/
8 years, 3 months
- 1
- 0
Using Hibernate ORM as automatic JPMS modules
by Gunnar Morling
Hi all,
Following to our discussion in Paris, I've created a simple test bed for
showing the usage of Hibernate ORM and its dependencies as automatic
modules for the Java 9 module system:
https://github.com/gunnarmorling/hibernate-orm-on-java9-modules
It pretty much works as expected, I couldn't reproduce the classloader
issue I was mentioning during the meeting. A few things worth noting:
* JDK 9 comes with an incomplete JTA module (java.transaction), so a
complete one must be provided via --upgrade-module-path (I'm using the
2.0.0.Alpha1 version Tomaz Cerar has created for that purpose)
* hibernate-jpa-2.1-api-1.0.0.Final.jar can't be used as an automatic
module, as the automatic naming algorithm stumples upon the numbers (2.1)
within the module name it derives; I'm therefore using my ModiTect tooling (
https://github.com/moditect/moditect/) to convert the JPA API JAR into an
explicit module on the fly
See
https://github.com/gunnarmorling/hibernate-orm-on-java9-modules/blob/mast...
for the actual test, which is run using the module path only (i.e. no
classpath).
A few things caught my attention:
* When using ByteBuddy as the byte code provider, a reads relationship must
be added from the user's module towards hibernate.core ("requires
hibernate.core"). This is due to the usage of
org.hibernate.proxy.ProxyConfiguration within the generated proxy classes.
Ideally no dependence to the JPA provider should be needed when solely
working with the JPA API (as this demo does), but I'm not sure whether this
can be avoided when using proxies (or could we construct proxies in a way
not requiring this dependence?).
* 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.
* Multiple methods in ReflectHelper call setAccessible() without checking
whether the method/field/constructor already is accessible. If we changed
that to only call setAccessible() if actually needed, people would have to
be a little bit less permissive in their module descriptor. It'd suffice
for them to declare "exports com.example.entities to hibernate.core"
instead of "opens com.example.entities to hibernate.core", unless they
mandate (private) field access for their entities.
The demo is very simple (insert and load of an entity with a lazy
association). If there's anything else you'd like to try out when using ORM
as JPMS modules, let me know or just fork the demo and try it out yourself
:)
Cheers,
--Gunnar
8 years, 3 months
- 3
- 24