So I keep reading up on Java modules and the more I do the more confused I get about how this can ever work properly.
1. I am confused about how we are supposed to create a module and reference something that is not yet a module. As I understand it, it will either be an automatic module on the module path or just be in the “unnamed” module on the class path. Well, a jar that has made no attempt to be modularized will be known by the wrong name - essentially the jar file name without the version so I don’t see how that can just be dropped on the module path. Also, as I understand it in order for it to be accessed on the class path we can’t declare a requirement on it (which makes sense I guess since it isn’t a module), but it means our module declaration is incomplete. 2. This one scares me. The module system doesn’t allow circularities. So picture a case where HttpClient is a module and it uses the Log4j 2 or SLF4J API (it doesn’t really matter which). Then Log4j has an Appender that uses HttpClient. Now you have Log4j that has an Appender that uses HttpClient (so an optional dependency is declared) and then HttpClient uses Log4j (and so declares that as a dependency) you now have a system that won’t run. Even if HttpClient uses SLF4J instead you will still have a problem if that then gets routed to Log4j. I’ve written to a couple of folks off list but at the moment I’m not clear on how this can work for libraries like Log4j. Ralph > On Apr 24, 2017, at 7:58 AM, Matt Sicker <[email protected]> wrote: > > Support Java 9 modules sounds a lot stricter than OSGi modules. Essentially > what is best practices in OSGi is required in JPMS. > > Anyways, the ServiceLoader for log4j-api sounds reasonable. The current > solution is basically a custom version of that with additional metadata > (the required API version), but we can probably support that differently. > From what I recall, it's basically two service loaders combined into one. > > On 24 April 2017 at 09:22, Mikael Ståldal <[email protected]> wrote: > >> Doing things for Java 9 modules that are beneficial also in Java 7/8 is >> good. >> >> Using Java ServiceLoader seems like a good idea, and we should definitely >> do it if required to support latest SLF4J. >> >> I am not so sure about refactoring package the structure though. Especially >> not if doing so will break BC. >> >> On Mon, Apr 24, 2017 at 4:00 PM, Ralph Goers <[email protected]> >> wrote: >> >>> It is and it isn’t. I’ve been working on module support all weekend. >>> There are a couple of changes that must be made before modules can be >>> effectively implemented and IMO it is worth doing them whether we support >>> modules or not. Note that none of these changes require Java 9. >>> >>> 1. Modify the API provider mechanism to use Java ServiceLoader. Modules >>> require that the kind of mechanism we are using be implemented with >>> ServiceLoader. However, our current implementation makes this easy and >>> creating a binding for for an implementation is dirt simple. I will be >>> checking something in for this in the next few days. >>> 2. Refactor our existing package structures. Modules essentially make >>> everything in a package public. We currently have a mixture of public and >>> private classes in both our API and in core. We need to go through all >>> these classes and determine which are really public and move the private >>> ones to a different package. This isn’t trivial. I think there is >> benefit >>> in doing this whether we support modules or not. Right now many methods >>> have “consider this private” in the header. But some classes in API that >>> are marked this way are used by Core, which means they are required to be >>> public to an implementation. These kinds of classes should be in the spi >>> package. >>> >>> I should also note that SLF4J now supports Java modules in the 1.8.0 >> alpha >>> releases. I tried integrating with that, and was somewhat successful, but >>> since Logback isn’t modularized our build fails in the various points >> where >>> we have tests that use it. SLF4J also changed its binding mechanism to >> use >>> SeviceLoader and it will ignore implementations that use the current >>> binding mechanism. I have implemented support for that and will be >>> committing that in the next few days as well. >>> >>> Ralph >>> >>>> On Apr 24, 2017, at 3:15 AM, Mikael Ståldal <[email protected] >>> >>> wrote: >>>> >>>> I think that it might be a bit early for us to do too much work for >>>> supporting Java 9 modules. >>>> >>>> On Mon, Apr 24, 2017 at 12:03 PM, Mikael Ståldal < >>> [email protected]> >>>> wrote: >>>> >>>>> This option will only be supported in JDK 9. >>>>> It will be removed in JDK 10. >>>>> >>>>> >>>>> On Sun, Apr 23, 2017 at 6:51 PM, Gary Gregory <[email protected] >>> >>>>> wrote: >>>>> >>>>>> The "big kill switch" straight from the source: >>>>>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017- >>> March/011763.html >>>>>> >>>>>> --permit-illegal-access >>>>>> >>>>>> Gary >>>>>> >>>>>> On Apr 23, 2017 9:44 AM, "Matt Sicker" <[email protected]> wrote: >>>>>> >>>>>>> “I have too often seen APIs that seemed like a good idea at the time >>> but >>>>>>> were, in fact, woefully deficient, baked into the Java Platform >> where >>>>>> they >>>>>>> fester for ages, cause pain to all who use it, and torment those who >>>>>>> maintain it. I will not let that happen >>>>>>> Here“ - Mark Reinhold >>>>>>> >>>>>>> That sounds like JPMS in general to be honest, but I'm just being >>>>>> cynical. >>>>>>> ;) >>>>>>> >>>>>>> On 23 April 2017 at 11:34, Gary Gregory <[email protected]> >>> wrote: >>>>>>> >>>>>>>> On Apr 23, 2017 9:19 AM, "Matt Sicker" <[email protected]> wrote: >>>>>>>> >>>>>>>> One potential scenario I see is that many users may just end up >>>>>> disabling >>>>>>>> JPMS in all their applications to the point that it's significantly >>>>>>> revised >>>>>>>> or scaled back for Java 10 or later. >>>>>>>> >>>>>>>> >>>>>>>> That's my plan the first time I see an IllegalAccessError :-( what >> is >>>>>> the >>>>>>>> command line kill switch called? >>>>>>>> >>>>>>>> Gary >>>>>>>> >>>>>>>> >>>>>>>> On 23 April 2017 at 11:04, Gary Gregory <[email protected]> >>>>>> wrote: >>>>>>>> >>>>>>>>> Worse: Are Java 9 modules its Titanic? >>>>>>>>> https://developer.jboss.org/blogs/scott.stark/2017/04/14/ >>>>>>>>> critical-deficiencies-in-jigsawjsr-376-java-platform- >>>>>>>>> module-system-ec-member-concerns >>>>>>>>> >>>>>>>>> >>>>>>>>> Gary >>>>>>>>> >>>>>>>>> On Apr 22, 2017 5:02 PM, "Ralph Goers" < >> [email protected]> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> This is an interesting look at the problems faced in getting >>>>>>> Hibernate >>>>>>>> to >>>>>>>>>> work. http://stackoverflow.com/questions/43258796/hibernate- >>>>>>>>>> support-for-java-9 <http://stackoverflow.com/ >>>>>>>>> questions/43258796/hibernate- >>>>>>>>>> support-for-java-9>. >>>>>>>>>> >>>>>>>>>> The issue with the compile problem with javax.xml are familiar to >>>>>> me >>>>>>> - >>>>>>>> I >>>>>>>>>> had to modify some Log4j code to not use the DataType converter >>>>>> as it >>>>>>>>> isn’t >>>>>>>>>> present in the java.base module. >>>>>>>>>> >>>>>>>>>> Ralph >>>>>>>>>> >>>>>>>>>>> On Apr 22, 2017, at 4:40 PM, Ralph Goers < >>>>>>> [email protected] >>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Oh - I just reread this. S far as I know Java 9 has a scheduled >>>>>>>> release >>>>>>>>>> date. It is July 27. >>>>>>>>>>> >>>>>>>>>>> BTW - here is the complete set of features - >>>>>>>> https://docs.oracle.com/ >>>>>>>>>> javase/9/whatsnew/toc.htm#JSNEW-GUID-BA9D8AF6-E706-4327- >>>>>>>>> 8909-F6747B8F35C5 >>>>>>>>>> <https://docs.oracle.com/javase/9/whatsnew/toc.htm# >>>>>>>>>> JSNEW-GUID-BA9D8AF6-E706-4327-8909-F6747B8F35C5>. >>>>>>>>>>> >>>>>>>>>>> Ralph >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Apr 22, 2017, at 10:45 AM, Gary Gregory < >>>>>>> [email protected]> >>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Let me play devil's advocate here for a sec... >>>>>>>>>>>> >>>>>>>>>>>> Java 9 modules and this auto naming business sounds painful. Is >>>>>>>> there >>>>>>>>>> any >>>>>>>>>>>> chance that this feature will be ignored like >>>>>> java.util.logging is >>>>>>>> or >>>>>>>>>>>> should be? >>>>>>>>>>>> >>>>>>>>>>>> Can we stop tying ourselves into unreleased pretzels over a >>>>>> moving >>>>>>>>>> target >>>>>>>>>>>> since we do not know when Java 9 will be out. >>>>>>>>>>>> >>>>>>>>>>>> Can't we refocus this energy on getting the best out of Java 8? >>>>>>>>>>>> >>>>>>>>>>>> Ducking from incoming tomatoes, >>>>>>>>>>>> Gary >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Apr 21, 2017 at 8:48 PM, Matt Sicker <[email protected] >>>>>>> >>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I'm a fan of splitting packages up better due to OSGi support >>>>>> in >>>>>>>> the >>>>>>>>>> first >>>>>>>>>>>>> place. Hierarchical packaging is definitely something new >>>>>> (OSGi >>>>>>>>> doesn't >>>>>>>>>>>>> care about that; each package is considered separately), and >>>>>> it >>>>>>>> could >>>>>>>>>> help >>>>>>>>>>>>> in making some classes more organized. >>>>>>>>>>>>> >>>>>>>>>>>>> On 21 April 2017 at 14:55, Stefan Bodewig <[email protected] >>>>>>> >>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On 2017-04-21, Ralph Goers wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have not started work on this yet, but from looking at >>>>>>>>>>>>>>> http://blog.joda.org/2017/04/j >>>>>> ava-9-modules-jpms-basics.html >>>>>>>>>>>>>>> <http://blog.joda.org/2017/04/ >>>>>> java-9-modules-jpms-basics.html> >>>>>>>> it >>>>>>>>>>>>>>> seems we are going to have problems with a) plugins that >>>>>> are in >>>>>>>>>>>>>>> different jars (modules) that use the same namespace and b) >>>>>>>>>> log4j-core >>>>>>>>>>>>>>> as it currently exists. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Item b is a problem because the module-info for log4j-core >>>>>>> should >>>>>>>>>> have >>>>>>>>>>>>>>> a requires ONLY for log4j-api. For example, I’m not sure >>>>>> how we >>>>>>>> can >>>>>>>>>>>>>>> have an optional dependency on Jackson. >>>>>>>>>>>>>> >>>>>>>>>>>>>> requires static module-name-of-jackson; >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html >>>>>> section >>>>>>>>> 1.1.1 >>>>>>>>>>>>>> >>>>>>>>>>>>>> The requires keyword may be followed by the modifier >>>>>> static. >>>>>>>> This >>>>>>>>>>>>>> specifies that the dependence, while mandatory at compile >>>>>>> time, >>>>>>>> is >>>>>>>>>>>>>> optional at run time. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Of course "requires static" captures this way more clearly >>>>>> than >>>>>>>>>> "require >>>>>>>>>>>>>> optional" which was proposed intially >>>>>>>>>>>>>> http://openjdk.java.net/projects/jigsaw/doc/topics/ >>>>>>> optional.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> :-) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Without knowing the structure of log4j too well I agree the >>>>>>> strict >>>>>>>>>>>>>> package hierarchies mandated by JPMS will be a problem. >>>>>> Probably >>>>>>>> for >>>>>>>>>>>>>> many other projects with more than one artifact as well. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Stefan >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Matt Sicker <[email protected]> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> E-Mail: [email protected] | [email protected] >>>>>>>>>>>> Java Persistence with Hibernate, Second Edition >>>>>>>>>>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_ >>>>>>>>>> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459& >>>>>>>>>> linkCode=as2&tag=garygregory-20&linkId= >>>>>>> cadb800f39946ec62ea2b1af9fe6a2 >>>>>>>> b8> >>>>>>>>>>>> >>>>>>>>>>>> <http:////ir-na.amazon-adsystem.com/e/ir?t= >>>>>>>>> garygregory-20&l=am2&o=1&a= >>>>>>>>>> 1617290459> >>>>>>>>>>>> JUnit in Action, Second Edition >>>>>>>>>>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_ >>>>>>>>>> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& >>>>>>>>>> linkCode=as2&tag=garygregory-20&linkId= >>>>>>> 31ecd1f6b6d1eaf8886ac902a24de4 >>>>>>>>> 18%22 >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> <http:////ir-na.amazon-adsystem.com/e/ir?t= >>>>>>>>> garygregory-20&l=am2&o=1&a= >>>>>>>>>> 1935182021> >>>>>>>>>>>> Spring Batch in Action >>>>>>>>>>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_ >>>>>>>>>> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& >>>>>>>>>> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% >>>>>>>>>> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> >>>>>>>>>>>> <http:////ir-na.amazon-adsystem.com/e/ir?t= >>>>>>>>> garygregory-20&l=am2&o=1&a= >>>>>>>>>> 1935182951> >>>>>>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>>>>>> Home: http://garygregory.com/ >>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Matt Sicker <[email protected]> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Matt Sicker <[email protected]> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> [image: MagineTV] >>>>> >>>>> *Mikael Ståldal* >>>>> Senior software developer >>>>> >>>>> *Magine TV* >>>>> [email protected] >>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com >>>>> >>>>> Privileged and/or Confidential Information may be contained in this >>>>> message. If you are not the addressee indicated in this message >>>>> (or responsible for delivery of the message to such a person), you may >>> not >>>>> copy or deliver this message to anyone. In such case, >>>>> you should destroy this message and kindly notify the sender by reply >>>>> email. >>>>> >>>> >>>> >>>> >>>> -- >>>> [image: MagineTV] >>>> >>>> *Mikael Ståldal* >>>> Senior software developer >>>> >>>> *Magine TV* >>>> [email protected] >>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com >>>> >>>> Privileged and/or Confidential Information may be contained in this >>>> message. If you are not the addressee indicated in this message >>>> (or responsible for delivery of the message to such a person), you may >>> not >>>> copy or deliver this message to anyone. In such case, >>>> you should destroy this message and kindly notify the sender by reply >>>> email. >>> >>> >>> >> >> >> -- >> [image: MagineTV] >> >> *Mikael Ståldal* >> Senior software developer >> >> *Magine TV* >> [email protected] >> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com >> >> Privileged and/or Confidential Information may be contained in this >> message. If you are not the addressee indicated in this message >> (or responsible for delivery of the message to such a person), you may not >> copy or deliver this message to anyone. In such case, >> you should destroy this message and kindly notify the sender by reply >> email. >> > > > > -- > Matt Sicker <[email protected]>
