On May 9, 2017 12:18 AM, "Remko Popma" <[email protected]> wrote:
(Shameless plug) Every java main() method deserves http://picocli.info > On May 9, 2017, at 15:35, Gary Gregory <[email protected]> wrote: > > Hi All, > > On Mon, May 8, 2017 at 10:46 PM, 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. >> > > 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... :-( Mark Reinhold's reasoning in his response (http://mail.openjdk.java.net/ pipermail/jpms-spec-experts/2017-May/000695.html) makes sense to me. Sounds reasonable indeed. Reading this latest sounds like JBoss has a lot of work to do in order to fit in Java 9 modules from its own module system and they'd rather not do more work than less, which is understandable. MR's view on a conservative first cut makes sense. It is so late in the Java 9 timeframe that these change requests seem doomed anyway. Gary Also not sure if there really is a problem: "Cycles are not allowed when modules are resolved but it is possible to create them post-resolution via the API, if needed [4][5]. Cycles are also set up amongst all automatic modules, after resolution, to make it easier to treat existing JAR files as modules without change [6]." > > 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 <[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]> >> >> >> > > > -- > 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=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
