Gunnar, back to the original discussion... I asked you about this specifically in Paris and you responded "no" - but reading info I have found online seems to indicate that it is indeed perfectly valid to build with Java 9 and include a module-info.class into the jar and be able to load that into Java 8 (module-info is simply ignored). Are the resources I have read just wrong?
On Thu, Dec 28, 2017 at 9:06 AM Steve Ebersole <st...@hibernate.org> wrote: > After tweaking this, here is what I have... > > Manifest-Version: 1.0 > Created-By: 1.8.0_121 (Oracle Corporation) > Main-Class: org.hibernate.Version > > Specification-Title: hibernate-core > Specification-Version: 5.3 > Specification-Vendor: Hibernate.org > > Implementation-Title: hibernate-core > Implementation-Version: 5.3.0.SNAPSHOT > Implementation-Vendor-Id: org.hibernate > Implementation-Vendor: Hibernate.org > Implementation-Url: http://hibernate.org > > Automatic-Module-Name: org.hibernate.orm.core > > Bundle-ManifestVersion: 2 > Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))" > Tool: Bnd-3.4.0.201707252008 > > Bundle-SymbolicName: org.hibernate.orm.core > Bundle-Version: 5.3.0.SNAPSHOT > Bundle-Name: hibernate-core > Bundle-Description: A module of the Hibernate O/RM project > Bundle-Vendor: Hibernate.org > Bundle-DocURL: http://www.hibernate.org/orm/5.3 > Bnd-LastModified: 1513615321000 > > Import-Package: ... > Export-Package: ... > > > Which looks great to me... > > On Wed, Dec 27, 2017 at 3:39 PM Steve Ebersole <st...@hibernate.org> > wrote: > >> I had intended this for 5.3 which hasn't even gone Beta yet (we wont have >> an Alpha). >> >> On Wed, Dec 27, 2017 at 3:38 PM Brett Meyer <br...@hibernate.org> wrote: >> >>> +1 from me on making them consistent. In practice, Bundle-SymbolicName >>> isn't used for much, other than a guaranteed unique identifier. One of >>> the Karaf guys pointed out that Bundle-SymbolicName is used to link a >>> fragment bundle to its host bundle, but we've been able to avoid >>> fragments like the plague on purpose. >>> >>> In practice, most users should be pulling in and interacting with our >>> bundles purely through Maven artifacts or our features.xml, so a change >>> would largely be unnoticed. >>> >>> We still might consider holding off doing that until at least a minor >>> version change, since there is a potential issue for any tooling that >>> might be relying on that (logging/auditing, etc.)... >>> >>> >>> On 12/23/17 11:38 PM, Steve Ebersole wrote: >>> > Another thing I was noticing was an annoying minor difference between >>> the >>> > OSGi bundle name and the Java 9 module name: >>> > >>> > Automatic-Module-Name: org.hibernate.orm.core >>> > Bundle-SymbolicName: org.hibernate.core >>> > >>> > Does it make sense to adjust the OSGi bundle name to follow the module >>> > naming? >>> > >>> > On Sat, Dec 23, 2017 at 8:47 AM Steve Ebersole <st...@hibernate.org> >>> wrote: >>> > >>> >> I already did a PR for the `Automatic-Module-Name` yesterday and >>> added you >>> >> as a reviewer. when you get a chance... >>> >> >>> >> >>> >> >>> >> On Sat, Dec 23, 2017 at 8:36 AM Gunnar Morling <gun...@hibernate.org> >>> >> wrote: >>> >> >>> >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole <st...@hibernate.org>: >>> >>> >>> >>>> I created a Jira to track this: >>> >>>> https://hibernate.atlassian.net/browse/HHH-12188 >>> >>>> >>> >>>> On Fri, Dec 22, 2017 at 5:33 AM Steve Ebersole <st...@hibernate.org >>> > >>> >>>> wrote: >>> >>>> >>> >>>>> Thanks for investigating this Gunnar. >>> >>>>> >>> >>>>> Some thoughts inline... >>> >>>>> >>> >>>>> On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling < >>> gun...@hibernate.org> >>> >>>>> wrote: >>> >>>>> >>> >>>>> >>> >>>>>> * 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) >>> >>>>>> >>> >>>>> Do you know if there is a plan to fix this in Java 9? Seems >>> bizarre >>> >>>>> that Java 9 expects all kinds of strict modularity from libraries >>> and >>> >>>>> applications when the JDK itself can't follow that.. >>> >>>>> >>> >>> The "java.transaction" module of the JDK is marked with >>> >>> @Deprecated(forRemoval=true) as of Java 9, but I don't know when the >>> >>> removal will happen. There's JEP 320 for this ( >>> >>> http://openjdk.java.net/jeps/320), which also describes why the >>> module >>> >>> exists in its current form. It's not scheduled for Java 10 >>> currently, and >>> >>> given the latter is in rampdown already, I wouldn't expect this >>> removal to >>> >>> happen before Java 11. >>> >>> >>> >>> >>> >>>>>> * 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 >>> >>>>>> >>> >>>>> We actually no longer use that artifact as a dependency. Since JPA >>> >>>>> 2.2, the EG publishes a "blessed" API jar which is what we use as a >>> >>>>> dependency. >>> >>>>> >>> >>> Ah, yes, very nice. That one already defines an explicit module name >>> >>> ("java.persistence") via the Automatic-Module-Name manifest entry. >>> >>> >>> >>>>>> * 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?). >>> >>>>>> >>> >>>>> I'm not sure what a decent solution would be here. Ultimately the >>> >>>>> runtime needs to be able to communicate with the generated proxies >>> - how >>> >>>>> else would you suggest this happen? >>> >>>>> >>> >>> Not sure either. Maybe we could generate a dedicated interface into >>> the >>> >>> user's module and then inject a generated implementation -- living >>> within >>> >>> the ORM module -- of that interface into the entities. Worth some >>> tinkering >>> >>> I reckon. >>> >>> >>> >>>>> * 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 >>> >>>>> >>> >>> Excellent. >>> >>> >>> >>>>> * 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. >>> >>>>>> >>> >>>>> Can you open a Jira for that? >>> >>>>> >>> >>> Done: https://hibernate.atlassian.net/browse/HHH-12189. >>> >>> >>> >>> >>> >>>>>> 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 >>> >>>>>> >>> >>>>> IIUC for jars targeting both Java 8 and Java 9 we cannot include a >>> >>>>> module-info file. But we need to set the module names - you >>> mentioned >>> >>>>> there was a "hinting" process. From what I could glean from >>> searching >>> >>>>> (which was oddly not many hits), this is achieved by adding a >>> >>>>> `Automatic-Module-Name` entry in the JAR's MANIFEST.MF. Correct? >>> >>>>> >>> >>> Yes, exactly that's the mechanism. Jason Greene is working on a >>> document >>> >>> with recommendations around naming patterns, I hope it'll be >>> published soon. >>> >>> >>> >>> >>> >>>>> Also, IIRC we agreed with `org.hibernate.orm` as the base for all >>> ORM >>> >>>>> module names, so we'd have: >>> >>>>> >>> >>>>> - org.hibernate.orm.c3p0 >>> >>>>> - org.hibernate.orm.core >>> >>>>> - ... >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> > _______________________________________________ >>> > hibernate-dev mailing list >>> > hibernate-dev@lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
