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 <mikael.stal...@magine.com> 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 <ralph.go...@dslextreme.com> > 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 <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. > > > > > > > > > -- > [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. > -- Matt Sicker <boa...@gmail.com>
