(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.
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
