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 <mikael.stal...@magine.com> 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 <mikael.stal...@magine.com> > 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 <garydgreg...@gmail.com> >> 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" <boa...@gmail.com> 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 <garydgreg...@gmail.com> wrote: >>>> >>>>> On Apr 23, 2017 9:19 AM, "Matt Sicker" <boa...@gmail.com> 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 <garydgreg...@gmail.com> >>> 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" <ralph.go...@dslextreme.com> >>>>> 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 < >>>> ralph.go...@dslextreme.com >>>>>> >>>>>>> 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 < >>>> garydgreg...@gmail.com> >>>>>>> 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 <boa...@gmail.com >>>> >>>>>> 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 <bode...@apache.org >>>> >>>>>> 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 <boa...@gmail.com> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>>>>> 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 <boa...@gmail.com> >>>>> >>>> >>>> >>>> >>>> -- >>>> Matt Sicker <boa...@gmail.com> >>>> >>> >> >> >> >> -- >> [image: MagineTV] >> >> *Mikael Ståldal* >> Senior software developer >> >> *Magine TV* >> mikael.stal...@magine.com >> 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* > mikael.stal...@magine.com > 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.
