This raises a question: how do you add a provider for System.Logger? Any implementation will need to use java.base, but java.base contains System.Logger, so you get a cycle right off the bat. Same goes for pretty much every class in Java.
On 9 May 2017 at 03:04, Mikael Ståldal <[email protected]> wrote: > We already have the circular case with KafkaAppender, the Kafka client > library we use logs with SLF4J. > > > On Tue, May 9, 2017 at 7:46 AM, Ralph Goers <[email protected]> > wrote: > > > 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]> > > > > > > > > > -- > [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]>
