Hi All, On Mon, May 8, 2017 at 10:46 PM, Ralph Goers <ralph.go...@dslextreme.com> 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. > For this one, this could be a case where module users will have to wrap jars in a module like some people do in OSGi: wrapping a jar to create a bundle. Eclipse ended up with a whole repository of these. Yikes. > > 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. > Nothing to do about that which is what one of the items the JBoss folks where dismayed about... :-( It's good that we are finding this out early but it sure seems worse and worse :-( Gary > 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 <boa...@gmail.com> 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 <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> > > > -- 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=cadb800f39946ec62ea2b1af9fe6a2b8> <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=31ecd1f6b6d1eaf8886ac902a24de418%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
