You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Ralph Goers <ra...@dslextreme.com> on 2017/04/21 19:40:40 UTC
Java 9 modules
I have not started work on this yet, but from looking at http://blog.joda.org/2017/04/java-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.
Item a is a problem if we create multiple jars (modules) for different network components but try to place them all under org.apache.logging.log4j.net <http://org.apache.logging.log4j.net/>.
Thoughts?
Ralph
Re: Java 9 modules
Posted by Ralph Goers <ra...@dslextreme.com>.
As I read through this again it seems that perhaps the usage of Jackson could be specified as “requires static” so it is an optional dependency. However, I am getting the feeling that we are going to have a clash between log4j-api and log4j-core as log4j-api would export org.apache.logging.log4j which precludes log4j-core from exporting org.apache.logging.log4j.core.
I am also not clear on how log4j can create module-info files that reference other projects that haven’t yet created modules.
Ralph
> On Apr 21, 2017, at 12:40 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> I have not started work on this yet, but from looking at http://blog.joda.org/2017/04/java-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.
>
> Item a is a problem if we create multiple jars (modules) for different network components but try to place them all under org.apache.logging.log4j.net <http://org.apache.logging.log4j.net/>.
>
> Thoughts?
>
> Ralph
Re: Java 9 modules
Posted by Matt Sicker <bo...@gmail.com>.
My workplaces have generally tried to stay up to date with new releases
except for occasional legacy applications that are barely being updated
anymore. However, that pattern remains to be seen with how much backwards
compatibility is broken by Java 9.
On 22 April 2017 at 17:45, Ralph Goers <ra...@dslextreme.com> wrote:
> That is interesting. Where I work we moved straight from Java 6 to 8 and
> skipped 7. That move was fairly painless. Despite me wanting to keep
> compatibility with Java 7 here, everything I am using at work is running on
> Java 8. But I anticipate the move to Java 9 is going to be fairly painful
> for some of our applications as they will need to have lots of other
> dependencies upgraded besides Java.
>
> Ralph
>
> > On Apr 22, 2017, at 2:59 PM, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > That's a given IMO. For my work projects, there is so much inertia
> > anchoring to Java 7 for various reasons.
> >
> > One of the many fun things of FOSS for me is that things move faster than
> > for work projects.
> >
> > So keeping on hearing that we must stay on Java 7 is not great.
> >
> > Yeah, there is the multi jar things and Java 9 thing but that is not the
> > same as just moving to Java 8 plain and simple.
> >
> > Gary
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Java 9 modules
Posted by Ralph Goers <ra...@dslextreme.com>.
That is interesting. Where I work we moved straight from Java 6 to 8 and skipped 7. That move was fairly painless. Despite me wanting to keep compatibility with Java 7 here, everything I am using at work is running on Java 8. But I anticipate the move to Java 9 is going to be fairly painful for some of our applications as they will need to have lots of other dependencies upgraded besides Java.
Ralph
> On Apr 22, 2017, at 2:59 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> That's a given IMO. For my work projects, there is so much inertia
> anchoring to Java 7 for various reasons.
>
> One of the many fun things of FOSS for me is that things move faster than
> for work projects.
>
> So keeping on hearing that we must stay on Java 7 is not great.
>
> Yeah, there is the multi jar things and Java 9 thing but that is not the
> same as just moving to Java 8 plain and simple.
>
> Gary
Re: Java 9 modules
Posted by Ralph Goers <ra...@dslextreme.com>.
I have no problem introducing things that let our users take advantage of Java 8 features so long as we continue to support our Java 7 users. My plan for Java 9 is the same as that.
IOW, we can’t take advantage of language constructs or JDK features that require us to compile with Java 9. That said, the current build is now compiling with both Java 9 and Java 7, so you can introduce things that require Java 9 to compile so long as it is a new feature only available in Java 9 (like modules) or is also available in some form in Java 7 (like StackWalker).
Ralph
> On Apr 22, 2017, at 2:59 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> That's a given IMO. For my work projects, there is so much inertia
> anchoring to Java 7 for various reasons.
>
> One of the many fun things of FOSS for me is that things move faster than
> for work projects.
>
> So keeping on hearing that we must stay on Java 7 is not great.
>
> Yeah, there is the multi jar things and Java 9 thing but that is not the
> same as just moving to Java 8 plain and simple.
>
> Gary
Re: Java 9 modules
Posted by Gary Gregory <ga...@gmail.com>.
That's a given IMO. For my work projects, there is so much inertia
anchoring to Java 7 for various reasons.
One of the many fun things of FOSS for me is that things move faster than
for work projects.
So keeping on hearing that we must stay on Java 7 is not great.
Yeah, there is the multi jar things and Java 9 thing but that is not the
same as just moving to Java 8 plain and simple.
Gary
Re: Java 9 modules
Posted by Matt Sicker <bo...@gmail.com>.
I'm starting to worry that Java 9 is going to be like Python 3 and that
it'll take years and years to get even a majority of users on board with it
due to these changes.
On 22 April 2017 at 13:13, Ralph Goers <ra...@dslextreme.com> wrote:
> WRT modules my plan is to hope for the best and expect the worst. I am
> working as we speak to create the module-info files for Java 9. These
> shouldn’t cause any harm to applications that choose to not use Java
> modules but will be necessary for those who do. If we don’t support it I
> would expect that would just be another reason for users to run off and
> pick a different framework that does.
>
> Also, there is no getting around StackWalker.
>
> I still see nothing in Java 8 worth making the effort for. I would
> suggest using multi-release jars to support those Java 8 features you might
> want to use, but that is pointless since multi-release jars aren’t
> supported until Java 9. Even then, I ended up backing away from using them
> as OSGi seems to have no intention of supporting them.
>
> Ralph
>
> > On Apr 22, 2017, at 10:45 AM, Gary Gregory <ga...@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 <bo...@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 <bo...@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/java-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 <bo...@gmail.com>
> >>
> >
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@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
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Java 9 modules
Posted by Ralph Goers <ra...@dslextreme.com>.
WRT modules my plan is to hope for the best and expect the worst. I am working as we speak to create the module-info files for Java 9. These shouldn’t cause any harm to applications that choose to not use Java modules but will be necessary for those who do. If we don’t support it I would expect that would just be another reason for users to run off and pick a different framework that does.
Also, there is no getting around StackWalker.
I still see nothing in Java 8 worth making the effort for. I would suggest using multi-release jars to support those Java 8 features you might want to use, but that is pointless since multi-release jars aren’t supported until Java 9. Even then, I ended up backing away from using them as OSGi seems to have no intention of supporting them.
Ralph
> On Apr 22, 2017, at 10:45 AM, Gary Gregory <ga...@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 <bo...@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 <bo...@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/java-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 <bo...@gmail.com>
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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
Re: Java 9 modules
Posted by Ralph Goers <ra...@dslextreme.com>.
I’m not sure what that means.
I may try to refactor log4j-api to be a Multi-Release jar so that the IDEs have less of an issue. However, once the next Java 9 JDK is released I believe whatever the issue with the tests was that Gary found will be fixed, so he should just be able to use Java 9 directly.
BTW - Java 9 has a new compiler option —release[1][2], which should cause compiles to fail if the code uses JDK methods that aren’t in the target version.
Ralph
1. http://blog.ltgt.net/most-build-tools-misuse-javac/ <http://blog.ltgt.net/most-build-tools-misuse-javac/>
2. http://openjdk.java.net/jeps/247 <http://openjdk.java.net/jeps/247>
> On May 9, 2017, at 1:33 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> So similar to the OSGi bundle loading strategy, for Java 9, we'll need a
> layer loading strategy?
>
> On 9 May 2017 at 11:36, Ralph Goers <ra...@dslextreme.com> wrote:
>
>> As I understand it, what you are saying is possible but Log4j doesn’t
>> currently need to load these dependencies dynamically. We dynamically load
>> our plugins, but the plugins we are talking about are provided by Log4j.
>> These plugins use a third party jar and these are hard-wired dependencies.
>> This all works fine today as Java doesn’t care about circularities. Of
>> course we do and handle that situation at runtime if an actual circularity
>> exists when performing the logging operations. But there is no problem if
>> Log4j needs Kafka, and Kafka needs Log4j.
>>
>> Ralph
>>
>>
>>
>>> On May 9, 2017, at 9:07 AM, Pedro Lamarão <pe...@prodist.com.br>
>> wrote:
>>>
>>> Hello all!
>>> I have been lurking on the list for a while, as a user of both log4j and
>> log4cxx.
>>> This Java 9 module situation greatly interests me.
>>> About the circularity problem, isn't it the case that loading modules at
>> runtime will solve the circularity problem?
>>> As far as I understand the new system, it is possible to build a new
>> Layer and load modules into it.
>>> Say the application depends on log4j. At runtime, log4j-core discovers
>> the need to load log4j-foo. It creates a new Layer and loads log4j-foo and
>> foo into it. foo may depend on log4j, yes, but that is already loaded in
>> the parent Layer.
>>> Am I missing something?
>>> Regards,
>>> P.
>>>
>>>
>>> Em 09/05/2017 12:43, Ralph Goers escreveu:
>>>> While it may sound reasonable, it is not. Matt’s point about
>> LoggerFinder and our support of NoSQL appenders and the like is proof that
>> there are valid reasons for circularities. We are just lucky that Jackson
>> and Disruptor don’t seem to do logging or we would have circularities there
>> too.
>>>>
>>>> BTW - I got a private answer to my question on this. It was that I
>> should post my question to the jigsaw dev list but that I should expect
>> that Log4j - or at least pieces of it - can’t be modularized.
>>>>
>>>> Ralph
>>>>
>>>>> On May 9, 2017, at 8:24 AM, Gary Gregory <ga...@gmail.com>
>> <ma...@gmail.com> wrote:
>>>>>
>>>>> On May 9, 2017 12:18 AM, "Remko Popma" <remko.popma@gmail.com <mailto:
>> remko.popma@gmail.com> <ma...@gmail.com> <mailto:
>> remko.popma@gmail.com>> wrote:
>>>>>
>>>>>
>>>>> Mark Reinhold's reasoning in his response (
>> http://mail.openjdk.java.net/ <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
>>>
>>> --
>>>
>>> <image001.jpg>
>>> Pedro Lamarão
>>> PRODIST TECHNOLOGIES
>>> http://www.prodist.com.br <http://www.prodist.com.br/>
>>> "Securing Critical Systems"
>>>
>>> (11) 3672-3526
>>> (21) 2292-9481
>>> (21) 98887-5175
>>>
>>>
>>>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
Re: Java 9 modules
Posted by Matt Sicker <bo...@gmail.com>.
So similar to the OSGi bundle loading strategy, for Java 9, we'll need a
layer loading strategy?
On 9 May 2017 at 11:36, Ralph Goers <ra...@dslextreme.com> wrote:
> As I understand it, what you are saying is possible but Log4j doesn’t
> currently need to load these dependencies dynamically. We dynamically load
> our plugins, but the plugins we are talking about are provided by Log4j.
> These plugins use a third party jar and these are hard-wired dependencies.
> This all works fine today as Java doesn’t care about circularities. Of
> course we do and handle that situation at runtime if an actual circularity
> exists when performing the logging operations. But there is no problem if
> Log4j needs Kafka, and Kafka needs Log4j.
>
> Ralph
>
>
>
> > On May 9, 2017, at 9:07 AM, Pedro Lamarão <pe...@prodist.com.br>
> wrote:
> >
> > Hello all!
> > I have been lurking on the list for a while, as a user of both log4j and
> log4cxx.
> > This Java 9 module situation greatly interests me.
> > About the circularity problem, isn't it the case that loading modules at
> runtime will solve the circularity problem?
> > As far as I understand the new system, it is possible to build a new
> Layer and load modules into it.
> > Say the application depends on log4j. At runtime, log4j-core discovers
> the need to load log4j-foo. It creates a new Layer and loads log4j-foo and
> foo into it. foo may depend on log4j, yes, but that is already loaded in
> the parent Layer.
> > Am I missing something?
> > Regards,
> > P.
> >
> >
> > Em 09/05/2017 12:43, Ralph Goers escreveu:
> >> While it may sound reasonable, it is not. Matt’s point about
> LoggerFinder and our support of NoSQL appenders and the like is proof that
> there are valid reasons for circularities. We are just lucky that Jackson
> and Disruptor don’t seem to do logging or we would have circularities there
> too.
> >>
> >> BTW - I got a private answer to my question on this. It was that I
> should post my question to the jigsaw dev list but that I should expect
> that Log4j - or at least pieces of it - can’t be modularized.
> >>
> >> Ralph
> >>
> >>> On May 9, 2017, at 8:24 AM, Gary Gregory <ga...@gmail.com>
> <ma...@gmail.com> wrote:
> >>>
> >>> On May 9, 2017 12:18 AM, "Remko Popma" <remko.popma@gmail.com <mailto:
> remko.popma@gmail.com> <ma...@gmail.com> <mailto:
> remko.popma@gmail.com>> wrote:
> >>>
> >>>
> >>> Mark Reinhold's reasoning in his response (
> http://mail.openjdk.java.net/ <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
> >
> > --
> >
> > <image001.jpg>
> > Pedro Lamarão
> > PRODIST TECHNOLOGIES
> > http://www.prodist.com.br <http://www.prodist.com.br/>
> > "Securing Critical Systems"
> >
> > (11) 3672-3526
> > (21) 2292-9481
> > (21) 98887-5175
> >
> >
> >
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Java 9 modules
Posted by Mikael Ståldal <mi...@magine.com>.
Starting a new thread about recursive logging at runtime since that's not
related to Java 9 modules.
On Wed, May 10, 2017 at 5:08 PM, Matt Sicker <bo...@gmail.com> wrote:
> https://github.com/apache/logging-log4j2/blob/master/
> log4j-core/src/main/java/org/apache/logging/log4j/core/
> config/AppenderControl.java
>
> All appenders are supported generically.
>
> On 10 May 2017 at 09:59, Mikael Ståldal <mi...@magine.com> wrote:
>
> > Do we have recursion prevention in any other appender than KafkaAppender?
> >
> > On Wed, May 10, 2017 at 4:55 PM, Matt Sicker <bo...@gmail.com> wrote:
> >
> > > We already have recursion prevention in appenders, so that's not an
> > issue.
> > > Runtime cycles are based on module imports apparently, not necessarily
> on
> > > the flow of data.
> > >
> > > On 10 May 2017 at 04:28, Mikael Ståldal <mi...@magine.com>
> > wrote:
> > >
> > > > Actually, it is a bit of a problem that the Kafka client library do
> > > logging
> > > > during our calls to it in KafkaAppender. But this is only a problem
> at
> > > > runtime.
> > > >
> > > > On Tue, May 9, 2017 at 6:36 PM, Ralph Goers <
> > ralph.goers@dslextreme.com>
> > > > wrote:
> > > >
> > > > > As I understand it, what you are saying is possible but Log4j
> doesn’t
> > > > > currently need to load these dependencies dynamically. We
> dynamically
> > > > load
> > > > > our plugins, but the plugins we are talking about are provided by
> > > Log4j.
> > > > > These plugins use a third party jar and these are hard-wired
> > > > dependencies.
> > > > > This all works fine today as Java doesn’t care about circularities.
> > Of
> > > > > course we do and handle that situation at runtime if an actual
> > > > circularity
> > > > > exists when performing the logging operations. But there is no
> > problem
> > > if
> > > > > Log4j needs Kafka, and Kafka needs Log4j.
> > > > >
> > > > > Ralph
> > > > >
> > > > >
> > > > >
> > > > > > On May 9, 2017, at 9:07 AM, Pedro Lamarão <
> > > > pedro.lamarao@prodist.com.br>
> > > > > wrote:
> > > > > >
> > > > > > Hello all!
> > > > > > I have been lurking on the list for a while, as a user of both
> > log4j
> > > > and
> > > > > log4cxx.
> > > > > > This Java 9 module situation greatly interests me.
> > > > > > About the circularity problem, isn't it the case that loading
> > modules
> > > > at
> > > > > runtime will solve the circularity problem?
> > > > > > As far as I understand the new system, it is possible to build a
> > new
> > > > > Layer and load modules into it.
> > > > > > Say the application depends on log4j. At runtime, log4j-core
> > > discovers
> > > > > the need to load log4j-foo. It creates a new Layer and loads
> > log4j-foo
> > > > and
> > > > > foo into it. foo may depend on log4j, yes, but that is already
> loaded
> > > in
> > > > > the parent Layer.
> > > > > > Am I missing something?
> > > > > > Regards,
> > > > > > P.
> > > > > >
> > > > > >
> > > > > > Em 09/05/2017 12:43, Ralph Goers escreveu:
> > > > > >> While it may sound reasonable, it is not. Matt’s point about
> > > > > LoggerFinder and our support of NoSQL appenders and the like is
> proof
> > > > that
> > > > > there are valid reasons for circularities. We are just lucky that
> > > Jackson
> > > > > and Disruptor don’t seem to do logging or we would have
> circularities
> > > > there
> > > > > too.
> > > > > >>
> > > > > >> BTW - I got a private answer to my question on this. It was
> that I
> > > > > should post my question to the jigsaw dev list but that I should
> > expect
> > > > > that Log4j - or at least pieces of it - can’t be modularized.
> > > > > >>
> > > > > >> Ralph
> > > > > >>
> > > > > >>> On May 9, 2017, at 8:24 AM, Gary Gregory <
> garydgregory@gmail.com
> > >
> > > > > <ma...@gmail.com> wrote:
> > > > > >>>
> > > > > >>> On May 9, 2017 12:18 AM, "Remko Popma" <remko.popma@gmail.com
> > > > <mailto:
> > > > > remko.popma@gmail.com> <ma...@gmail.com> <mailto:
> > > > > remko.popma@gmail.com>> wrote:
> > > > > >>>
> > > > > >>>
> > > > > >>> Mark Reinhold's reasoning in his response (
> > > > > http://mail.openjdk.java.net/ <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
> > > > > >
> > > > > > --
> > > > > >
> > > > > > <image001.jpg>
> > > > > > Pedro Lamarão
> > > > > > PRODIST TECHNOLOGIES
> > > > > > http://www.prodist.com.br <http://www.prodist.com.br/>
> > > > > > "Securing Critical Systems"
> > > > > >
> > > > > > (11) 3672-3526
> > > > > > (21) 2292-9481
> > > > > > (21) 98887-5175
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > [image: MagineTV]
> > > >
> > > > *Mikael Ståldal*
> > > > Senior software developer
> > > >
> > > > *Magine TV*
> > > > mikael.staldal@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 <bo...@gmail.com>
> > >
> >
> >
> >
> > --
> > [image: MagineTV]
> >
> > *Mikael Ståldal*
> > Senior software developer
> >
> > *Magine TV*
> > mikael.staldal@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 <bo...@gmail.com>
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior software developer
*Magine TV*
mikael.staldal@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.
Re: Java 9 modules
Posted by Matt Sicker <bo...@gmail.com>.
https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AppenderControl.java
All appenders are supported generically.
On 10 May 2017 at 09:59, Mikael Ståldal <mi...@magine.com> wrote:
> Do we have recursion prevention in any other appender than KafkaAppender?
>
> On Wed, May 10, 2017 at 4:55 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> > We already have recursion prevention in appenders, so that's not an
> issue.
> > Runtime cycles are based on module imports apparently, not necessarily on
> > the flow of data.
> >
> > On 10 May 2017 at 04:28, Mikael Ståldal <mi...@magine.com>
> wrote:
> >
> > > Actually, it is a bit of a problem that the Kafka client library do
> > logging
> > > during our calls to it in KafkaAppender. But this is only a problem at
> > > runtime.
> > >
> > > On Tue, May 9, 2017 at 6:36 PM, Ralph Goers <
> ralph.goers@dslextreme.com>
> > > wrote:
> > >
> > > > As I understand it, what you are saying is possible but Log4j doesn’t
> > > > currently need to load these dependencies dynamically. We dynamically
> > > load
> > > > our plugins, but the plugins we are talking about are provided by
> > Log4j.
> > > > These plugins use a third party jar and these are hard-wired
> > > dependencies.
> > > > This all works fine today as Java doesn’t care about circularities.
> Of
> > > > course we do and handle that situation at runtime if an actual
> > > circularity
> > > > exists when performing the logging operations. But there is no
> problem
> > if
> > > > Log4j needs Kafka, and Kafka needs Log4j.
> > > >
> > > > Ralph
> > > >
> > > >
> > > >
> > > > > On May 9, 2017, at 9:07 AM, Pedro Lamarão <
> > > pedro.lamarao@prodist.com.br>
> > > > wrote:
> > > > >
> > > > > Hello all!
> > > > > I have been lurking on the list for a while, as a user of both
> log4j
> > > and
> > > > log4cxx.
> > > > > This Java 9 module situation greatly interests me.
> > > > > About the circularity problem, isn't it the case that loading
> modules
> > > at
> > > > runtime will solve the circularity problem?
> > > > > As far as I understand the new system, it is possible to build a
> new
> > > > Layer and load modules into it.
> > > > > Say the application depends on log4j. At runtime, log4j-core
> > discovers
> > > > the need to load log4j-foo. It creates a new Layer and loads
> log4j-foo
> > > and
> > > > foo into it. foo may depend on log4j, yes, but that is already loaded
> > in
> > > > the parent Layer.
> > > > > Am I missing something?
> > > > > Regards,
> > > > > P.
> > > > >
> > > > >
> > > > > Em 09/05/2017 12:43, Ralph Goers escreveu:
> > > > >> While it may sound reasonable, it is not. Matt’s point about
> > > > LoggerFinder and our support of NoSQL appenders and the like is proof
> > > that
> > > > there are valid reasons for circularities. We are just lucky that
> > Jackson
> > > > and Disruptor don’t seem to do logging or we would have circularities
> > > there
> > > > too.
> > > > >>
> > > > >> BTW - I got a private answer to my question on this. It was that I
> > > > should post my question to the jigsaw dev list but that I should
> expect
> > > > that Log4j - or at least pieces of it - can’t be modularized.
> > > > >>
> > > > >> Ralph
> > > > >>
> > > > >>> On May 9, 2017, at 8:24 AM, Gary Gregory <garydgregory@gmail.com
> >
> > > > <ma...@gmail.com> wrote:
> > > > >>>
> > > > >>> On May 9, 2017 12:18 AM, "Remko Popma" <remko.popma@gmail.com
> > > <mailto:
> > > > remko.popma@gmail.com> <ma...@gmail.com> <mailto:
> > > > remko.popma@gmail.com>> wrote:
> > > > >>>
> > > > >>>
> > > > >>> Mark Reinhold's reasoning in his response (
> > > > http://mail.openjdk.java.net/ <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
> > > > >
> > > > > --
> > > > >
> > > > > <image001.jpg>
> > > > > Pedro Lamarão
> > > > > PRODIST TECHNOLOGIES
> > > > > http://www.prodist.com.br <http://www.prodist.com.br/>
> > > > > "Securing Critical Systems"
> > > > >
> > > > > (11) 3672-3526
> > > > > (21) 2292-9481
> > > > > (21) 98887-5175
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > [image: MagineTV]
> > >
> > > *Mikael Ståldal*
> > > Senior software developer
> > >
> > > *Magine TV*
> > > mikael.staldal@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 <bo...@gmail.com>
> >
>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.staldal@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 <bo...@gmail.com>
Re: Java 9 modules
Posted by Mikael Ståldal <mi...@magine.com>.
Do we have recursion prevention in any other appender than KafkaAppender?
On Wed, May 10, 2017 at 4:55 PM, Matt Sicker <bo...@gmail.com> wrote:
> We already have recursion prevention in appenders, so that's not an issue.
> Runtime cycles are based on module imports apparently, not necessarily on
> the flow of data.
>
> On 10 May 2017 at 04:28, Mikael Ståldal <mi...@magine.com> wrote:
>
> > Actually, it is a bit of a problem that the Kafka client library do
> logging
> > during our calls to it in KafkaAppender. But this is only a problem at
> > runtime.
> >
> > On Tue, May 9, 2017 at 6:36 PM, Ralph Goers <ra...@dslextreme.com>
> > wrote:
> >
> > > As I understand it, what you are saying is possible but Log4j doesn’t
> > > currently need to load these dependencies dynamically. We dynamically
> > load
> > > our plugins, but the plugins we are talking about are provided by
> Log4j.
> > > These plugins use a third party jar and these are hard-wired
> > dependencies.
> > > This all works fine today as Java doesn’t care about circularities. Of
> > > course we do and handle that situation at runtime if an actual
> > circularity
> > > exists when performing the logging operations. But there is no problem
> if
> > > Log4j needs Kafka, and Kafka needs Log4j.
> > >
> > > Ralph
> > >
> > >
> > >
> > > > On May 9, 2017, at 9:07 AM, Pedro Lamarão <
> > pedro.lamarao@prodist.com.br>
> > > wrote:
> > > >
> > > > Hello all!
> > > > I have been lurking on the list for a while, as a user of both log4j
> > and
> > > log4cxx.
> > > > This Java 9 module situation greatly interests me.
> > > > About the circularity problem, isn't it the case that loading modules
> > at
> > > runtime will solve the circularity problem?
> > > > As far as I understand the new system, it is possible to build a new
> > > Layer and load modules into it.
> > > > Say the application depends on log4j. At runtime, log4j-core
> discovers
> > > the need to load log4j-foo. It creates a new Layer and loads log4j-foo
> > and
> > > foo into it. foo may depend on log4j, yes, but that is already loaded
> in
> > > the parent Layer.
> > > > Am I missing something?
> > > > Regards,
> > > > P.
> > > >
> > > >
> > > > Em 09/05/2017 12:43, Ralph Goers escreveu:
> > > >> While it may sound reasonable, it is not. Matt’s point about
> > > LoggerFinder and our support of NoSQL appenders and the like is proof
> > that
> > > there are valid reasons for circularities. We are just lucky that
> Jackson
> > > and Disruptor don’t seem to do logging or we would have circularities
> > there
> > > too.
> > > >>
> > > >> BTW - I got a private answer to my question on this. It was that I
> > > should post my question to the jigsaw dev list but that I should expect
> > > that Log4j - or at least pieces of it - can’t be modularized.
> > > >>
> > > >> Ralph
> > > >>
> > > >>> On May 9, 2017, at 8:24 AM, Gary Gregory <ga...@gmail.com>
> > > <ma...@gmail.com> wrote:
> > > >>>
> > > >>> On May 9, 2017 12:18 AM, "Remko Popma" <remko.popma@gmail.com
> > <mailto:
> > > remko.popma@gmail.com> <ma...@gmail.com> <mailto:
> > > remko.popma@gmail.com>> wrote:
> > > >>>
> > > >>>
> > > >>> Mark Reinhold's reasoning in his response (
> > > http://mail.openjdk.java.net/ <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
> > > >
> > > > --
> > > >
> > > > <image001.jpg>
> > > > Pedro Lamarão
> > > > PRODIST TECHNOLOGIES
> > > > http://www.prodist.com.br <http://www.prodist.com.br/>
> > > > "Securing Critical Systems"
> > > >
> > > > (11) 3672-3526
> > > > (21) 2292-9481
> > > > (21) 98887-5175
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > [image: MagineTV]
> >
> > *Mikael Ståldal*
> > Senior software developer
> >
> > *Magine TV*
> > mikael.staldal@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 <bo...@gmail.com>
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior software developer
*Magine TV*
mikael.staldal@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.
Re: Java 9 modules
Posted by Matt Sicker <bo...@gmail.com>.
We already have recursion prevention in appenders, so that's not an issue.
Runtime cycles are based on module imports apparently, not necessarily on
the flow of data.
On 10 May 2017 at 04:28, Mikael Ståldal <mi...@magine.com> wrote:
> Actually, it is a bit of a problem that the Kafka client library do logging
> during our calls to it in KafkaAppender. But this is only a problem at
> runtime.
>
> On Tue, May 9, 2017 at 6:36 PM, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
> > As I understand it, what you are saying is possible but Log4j doesn’t
> > currently need to load these dependencies dynamically. We dynamically
> load
> > our plugins, but the plugins we are talking about are provided by Log4j.
> > These plugins use a third party jar and these are hard-wired
> dependencies.
> > This all works fine today as Java doesn’t care about circularities. Of
> > course we do and handle that situation at runtime if an actual
> circularity
> > exists when performing the logging operations. But there is no problem if
> > Log4j needs Kafka, and Kafka needs Log4j.
> >
> > Ralph
> >
> >
> >
> > > On May 9, 2017, at 9:07 AM, Pedro Lamarão <
> pedro.lamarao@prodist.com.br>
> > wrote:
> > >
> > > Hello all!
> > > I have been lurking on the list for a while, as a user of both log4j
> and
> > log4cxx.
> > > This Java 9 module situation greatly interests me.
> > > About the circularity problem, isn't it the case that loading modules
> at
> > runtime will solve the circularity problem?
> > > As far as I understand the new system, it is possible to build a new
> > Layer and load modules into it.
> > > Say the application depends on log4j. At runtime, log4j-core discovers
> > the need to load log4j-foo. It creates a new Layer and loads log4j-foo
> and
> > foo into it. foo may depend on log4j, yes, but that is already loaded in
> > the parent Layer.
> > > Am I missing something?
> > > Regards,
> > > P.
> > >
> > >
> > > Em 09/05/2017 12:43, Ralph Goers escreveu:
> > >> While it may sound reasonable, it is not. Matt’s point about
> > LoggerFinder and our support of NoSQL appenders and the like is proof
> that
> > there are valid reasons for circularities. We are just lucky that Jackson
> > and Disruptor don’t seem to do logging or we would have circularities
> there
> > too.
> > >>
> > >> BTW - I got a private answer to my question on this. It was that I
> > should post my question to the jigsaw dev list but that I should expect
> > that Log4j - or at least pieces of it - can’t be modularized.
> > >>
> > >> Ralph
> > >>
> > >>> On May 9, 2017, at 8:24 AM, Gary Gregory <ga...@gmail.com>
> > <ma...@gmail.com> wrote:
> > >>>
> > >>> On May 9, 2017 12:18 AM, "Remko Popma" <remko.popma@gmail.com
> <mailto:
> > remko.popma@gmail.com> <ma...@gmail.com> <mailto:
> > remko.popma@gmail.com>> wrote:
> > >>>
> > >>>
> > >>> Mark Reinhold's reasoning in his response (
> > http://mail.openjdk.java.net/ <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
> > >
> > > --
> > >
> > > <image001.jpg>
> > > Pedro Lamarão
> > > PRODIST TECHNOLOGIES
> > > http://www.prodist.com.br <http://www.prodist.com.br/>
> > > "Securing Critical Systems"
> > >
> > > (11) 3672-3526
> > > (21) 2292-9481
> > > (21) 98887-5175
> > >
> > >
> > >
> >
> >
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.staldal@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 <bo...@gmail.com>
Re: Java 9 modules
Posted by Mikael Ståldal <mi...@magine.com>.
Actually, it is a bit of a problem that the Kafka client library do logging
during our calls to it in KafkaAppender. But this is only a problem at
runtime.
On Tue, May 9, 2017 at 6:36 PM, Ralph Goers <ra...@dslextreme.com>
wrote:
> As I understand it, what you are saying is possible but Log4j doesn’t
> currently need to load these dependencies dynamically. We dynamically load
> our plugins, but the plugins we are talking about are provided by Log4j.
> These plugins use a third party jar and these are hard-wired dependencies.
> This all works fine today as Java doesn’t care about circularities. Of
> course we do and handle that situation at runtime if an actual circularity
> exists when performing the logging operations. But there is no problem if
> Log4j needs Kafka, and Kafka needs Log4j.
>
> Ralph
>
>
>
> > On May 9, 2017, at 9:07 AM, Pedro Lamarão <pe...@prodist.com.br>
> wrote:
> >
> > Hello all!
> > I have been lurking on the list for a while, as a user of both log4j and
> log4cxx.
> > This Java 9 module situation greatly interests me.
> > About the circularity problem, isn't it the case that loading modules at
> runtime will solve the circularity problem?
> > As far as I understand the new system, it is possible to build a new
> Layer and load modules into it.
> > Say the application depends on log4j. At runtime, log4j-core discovers
> the need to load log4j-foo. It creates a new Layer and loads log4j-foo and
> foo into it. foo may depend on log4j, yes, but that is already loaded in
> the parent Layer.
> > Am I missing something?
> > Regards,
> > P.
> >
> >
> > Em 09/05/2017 12:43, Ralph Goers escreveu:
> >> While it may sound reasonable, it is not. Matt’s point about
> LoggerFinder and our support of NoSQL appenders and the like is proof that
> there are valid reasons for circularities. We are just lucky that Jackson
> and Disruptor don’t seem to do logging or we would have circularities there
> too.
> >>
> >> BTW - I got a private answer to my question on this. It was that I
> should post my question to the jigsaw dev list but that I should expect
> that Log4j - or at least pieces of it - can’t be modularized.
> >>
> >> Ralph
> >>
> >>> On May 9, 2017, at 8:24 AM, Gary Gregory <ga...@gmail.com>
> <ma...@gmail.com> wrote:
> >>>
> >>> On May 9, 2017 12:18 AM, "Remko Popma" <remko.popma@gmail.com <mailto:
> remko.popma@gmail.com> <ma...@gmail.com> <mailto:
> remko.popma@gmail.com>> wrote:
> >>>
> >>>
> >>> Mark Reinhold's reasoning in his response (
> http://mail.openjdk.java.net/ <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
> >
> > --
> >
> > <image001.jpg>
> > Pedro Lamarão
> > PRODIST TECHNOLOGIES
> > http://www.prodist.com.br <http://www.prodist.com.br/>
> > "Securing Critical Systems"
> >
> > (11) 3672-3526
> > (21) 2292-9481
> > (21) 98887-5175
> >
> >
> >
>
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior software developer
*Magine TV*
mikael.staldal@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.
Re: Java 9 modules
Posted by Ralph Goers <ra...@dslextreme.com>.
As I understand it, what you are saying is possible but Log4j doesn’t currently need to load these dependencies dynamically. We dynamically load our plugins, but the plugins we are talking about are provided by Log4j. These plugins use a third party jar and these are hard-wired dependencies. This all works fine today as Java doesn’t care about circularities. Of course we do and handle that situation at runtime if an actual circularity exists when performing the logging operations. But there is no problem if Log4j needs Kafka, and Kafka needs Log4j.
Ralph
> On May 9, 2017, at 9:07 AM, Pedro Lamarão <pe...@prodist.com.br> wrote:
>
> Hello all!
> I have been lurking on the list for a while, as a user of both log4j and log4cxx.
> This Java 9 module situation greatly interests me.
> About the circularity problem, isn't it the case that loading modules at runtime will solve the circularity problem?
> As far as I understand the new system, it is possible to build a new Layer and load modules into it.
> Say the application depends on log4j. At runtime, log4j-core discovers the need to load log4j-foo. It creates a new Layer and loads log4j-foo and foo into it. foo may depend on log4j, yes, but that is already loaded in the parent Layer.
> Am I missing something?
> Regards,
> P.
>
>
> Em 09/05/2017 12:43, Ralph Goers escreveu:
>> While it may sound reasonable, it is not. Matt’s point about LoggerFinder and our support of NoSQL appenders and the like is proof that there are valid reasons for circularities. We are just lucky that Jackson and Disruptor don’t seem to do logging or we would have circularities there too.
>>
>> BTW - I got a private answer to my question on this. It was that I should post my question to the jigsaw dev list but that I should expect that Log4j - or at least pieces of it - can’t be modularized.
>>
>> Ralph
>>
>>> On May 9, 2017, at 8:24 AM, Gary Gregory <ga...@gmail.com> <ma...@gmail.com> wrote:
>>>
>>> On May 9, 2017 12:18 AM, "Remko Popma" <remko.popma@gmail.com <ma...@gmail.com> <ma...@gmail.com> <ma...@gmail.com>> wrote:
>>>
>>>
>>> Mark Reinhold's reasoning in his response (http://mail.openjdk.java.net/ <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
>
> --
>
> <image001.jpg>
> Pedro Lamarão
> PRODIST TECHNOLOGIES
> http://www.prodist.com.br <http://www.prodist.com.br/>
> "Securing Critical Systems"
>
> (11) 3672-3526
> (21) 2292-9481
> (21) 98887-5175
>
>
>
Re: Java 9 modules
Posted by Pedro Lamarão <pe...@prodist.com.br>.
Hello all!
I have been lurking on the list for a while, as a user of both log4j and
log4cxx.
This Java 9 module situation greatly interests me.
About the circularity problem, isn't it the case that loading modules at
runtime will solve the circularity problem?
As far as I understand the new system, it is possible to build a new
Layer and load modules into it.
Say the application depends on log4j. At runtime, log4j-core discovers
the need to load log4j-foo. It creates a new Layer and loads log4j-foo
and foo into it. foo may depend on log4j, yes, but that is already
loaded in the parent Layer.
Am I missing something?
Regards,
P.
Em 09/05/2017 12:43, Ralph Goers escreveu:
> While it may sound reasonable, it is not. Matt’s point about LoggerFinder and our support of NoSQL appenders and the like is proof that there are valid reasons for circularities. We are just lucky that Jackson and Disruptor don’t seem to do logging or we would have circularities there too.
>
> BTW - I got a private answer to my question on this. It was that I should post my question to the jigsaw dev list but that I should expect that Log4j - or at least pieces of it - can’t be modularized.
>
> Ralph
>
>> On May 9, 2017, at 8:24 AM, Gary Gregory <ga...@gmail.com> wrote:
>>
>> On May 9, 2017 12:18 AM, "Remko Popma" <remko.popma@gmail.com <ma...@gmail.com>> wrote:
>>
>>
>> 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
--
<o:p></o:p><o:p> </o:p>
cid:image005.jpg@01D2AFC0.49538E40
*Pedro Lamarão***
*PRODIST TECHNOLOGIES*
http://www.prodist.com.br <http://www.prodist.com.br/>
*/"Securing Critical Systems"/*
**
*(11) 3672-3526*
*(21) 2292-9481*
*(21) 98887-5175*
**
Re: Java 9 modules
Posted by Apache <ra...@dslextreme.com>.
Yes, although we could fully modularize the API right away.
Ralph
> On May 9, 2017, at 12:51 AM, Gary Gregory <ga...@gmail.com> wrote:
>
>> On Tue, May 9, 2017 at 12:34 AM, Apache <ra...@dslextreme.com> wrote:
>>
>> Technically you are considered modularized just by adding a manifest entry
>> providing the module name. But all the packages are exported. You cannot do
>> more than that until all your dependencies do at least that much.
>>
>
> So it's a two-step. First the module name, only when all the deps do it.
> Then some other second step, only when the deps do that too.
>
> Sounds like it will be a looooong wait.
>
> Gary
>
>
>>
>> Ralph
>>
>>> On May 9, 2017, at 12:27 AM, Gary Gregory <ga...@gmail.com>
>> wrote:
>>>
>>>> On Tue, May 9, 2017 at 12:24 AM, Apache <ra...@dslextreme.com>
>> wrote:
>>>>
>>>> I read that previously but if Log4J implements modules I don't see how
>> the
>>>> nodal appenders or flume appender can work.
>>>>
>>>> I also got a reply to my query about referencing dependencies that are
>> not
>>>> yet modularized and the recommendation is to only use the manifest entry
>>>> and not have a module-info.java until all dependencies are modularized.
>>>>
>>>
>>> Am I reading that we should not modularize Log4j 2 until all of its
>>> dependencies are themselves modularized?
>>>
>>> Gary
>>>
>>>>
>>>>> On May 9, 2017, at 12:18 AM, Remko Popma <re...@gmail.com>
>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> (Shameless plug) Every java main() method deserves http://picocli.info
>>>>>> On May 9, 2017, at 15:35, Gary Gregory <ga...@gmail.com>
>> wrote:
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> On Mon, May 8, 2017 at 10:46 PM, Ralph Goers <
>>>> ralph.goers@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... :-(
>>>>>
>>>>> 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 <bo...@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.staldal@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.goers@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.staldal@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.staldal@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 <
>>>>>>> garydgregory@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" <bo...@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 <
>> garydgregory@gmail.com
>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Apr 23, 2017 9:19 AM, "Matt Sicker" <bo...@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 <
>>>> garydgregory@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.goers@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.goers@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 <
>>>>>>>>>>>>>> garydgregory@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 <
>>>>>>> boards@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 <
>>>>>>> bodewig@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 <bo...@gmail.com>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> [image: MagineTV]
>>>>>>>>>>>>
>>>>>>>>>>>> *Mikael Ståldal*
>>>>>>>>>>>> Senior software developer
>>>>>>>>>>>>
>>>>>>>>>>>> *Magine TV*
>>>>>>>>>>>> mikael.staldal@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.staldal@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.staldal@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 <bo...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@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
>>
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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
Re: Java 9 modules
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, May 9, 2017 at 12:34 AM, Apache <ra...@dslextreme.com> wrote:
> Technically you are considered modularized just by adding a manifest entry
> providing the module name. But all the packages are exported. You cannot do
> more than that until all your dependencies do at least that much.
>
So it's a two-step. First the module name, only when all the deps do it.
Then some other second step, only when the deps do that too.
Sounds like it will be a looooong wait.
Gary
>
> Ralph
>
> > On May 9, 2017, at 12:27 AM, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> >> On Tue, May 9, 2017 at 12:24 AM, Apache <ra...@dslextreme.com>
> wrote:
> >>
> >> I read that previously but if Log4J implements modules I don't see how
> the
> >> nodal appenders or flume appender can work.
> >>
> >> I also got a reply to my query about referencing dependencies that are
> not
> >> yet modularized and the recommendation is to only use the manifest entry
> >> and not have a module-info.java until all dependencies are modularized.
> >>
> >
> > Am I reading that we should not modularize Log4j 2 until all of its
> > dependencies are themselves modularized?
> >
> > Gary
> >
> >>
> >>> On May 9, 2017, at 12:18 AM, Remko Popma <re...@gmail.com>
> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> (Shameless plug) Every java main() method deserves http://picocli.info
> >>>> On May 9, 2017, at 15:35, Gary Gregory <ga...@gmail.com>
> wrote:
> >>>>
> >>>> Hi All,
> >>>>
> >>>> On Mon, May 8, 2017 at 10:46 PM, Ralph Goers <
> >> ralph.goers@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... :-(
> >>>
> >>> 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 <bo...@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.staldal@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.goers@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.staldal@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.staldal@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 <
> >>>>> garydgregory@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" <bo...@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 <
> garydgregory@gmail.com
> >>>
> >>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On Apr 23, 2017 9:19 AM, "Matt Sicker" <bo...@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 <
> >> garydgregory@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.goers@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.goers@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 <
> >>>>>>>>>>>> garydgregory@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 <
> >>>>> boards@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 <
> >>>>> bodewig@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 <bo...@gmail.com>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> [image: MagineTV]
> >>>>>>>>>>
> >>>>>>>>>> *Mikael Ståldal*
> >>>>>>>>>> Senior software developer
> >>>>>>>>>>
> >>>>>>>>>> *Magine TV*
> >>>>>>>>>> mikael.staldal@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.staldal@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.staldal@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 <bo...@gmail.com>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> E-Mail: garydgregory@gmail.com | ggregory@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
> >>
> >>
> >>
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@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
>
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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
Re: Java 9 modules
Posted by Apache <ra...@dslextreme.com>.
Technically you are considered modularized just by adding a manifest entry providing the module name. But all the packages are exported. You cannot do more than that until all your dependencies do at least that much.
Ralph
> On May 9, 2017, at 12:27 AM, Gary Gregory <ga...@gmail.com> wrote:
>
>> On Tue, May 9, 2017 at 12:24 AM, Apache <ra...@dslextreme.com> wrote:
>>
>> I read that previously but if Log4J implements modules I don't see how the
>> nodal appenders or flume appender can work.
>>
>> I also got a reply to my query about referencing dependencies that are not
>> yet modularized and the recommendation is to only use the manifest entry
>> and not have a module-info.java until all dependencies are modularized.
>>
>
> Am I reading that we should not modularize Log4j 2 until all of its
> dependencies are themselves modularized?
>
> Gary
>
>>
>>> On May 9, 2017, at 12:18 AM, Remko Popma <re...@gmail.com> wrote:
>>>
>>>
>>>
>>>
>>>
>>> (Shameless plug) Every java main() method deserves http://picocli.info
>>>> On May 9, 2017, at 15:35, Gary Gregory <ga...@gmail.com> wrote:
>>>>
>>>> Hi All,
>>>>
>>>> On Mon, May 8, 2017 at 10:46 PM, Ralph Goers <
>> ralph.goers@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... :-(
>>>
>>> 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 <bo...@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 <mi...@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.goers@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.staldal@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.staldal@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 <
>>>>> garydgregory@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" <bo...@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 <garydgregory@gmail.com
>>>
>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Apr 23, 2017 9:19 AM, "Matt Sicker" <bo...@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 <
>> garydgregory@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.goers@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.goers@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 <
>>>>>>>>>>>> garydgregory@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 <
>>>>> boards@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 <
>>>>> bodewig@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 <bo...@gmail.com>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> [image: MagineTV]
>>>>>>>>>>
>>>>>>>>>> *Mikael Ståldal*
>>>>>>>>>> Senior software developer
>>>>>>>>>>
>>>>>>>>>> *Magine TV*
>>>>>>>>>> mikael.staldal@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.staldal@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.staldal@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 <bo...@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@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
>>
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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
Re: Java 9 modules
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, May 9, 2017 at 12:24 AM, Apache <ra...@dslextreme.com> wrote:
> I read that previously but if Log4J implements modules I don't see how the
> nodal appenders or flume appender can work.
>
> I also got a reply to my query about referencing dependencies that are not
> yet modularized and the recommendation is to only use the manifest entry
> and not have a module-info.java until all dependencies are modularized.
>
Am I reading that we should not modularize Log4j 2 until all of its
dependencies are themselves modularized?
Gary
>
> > On May 9, 2017, at 12:18 AM, Remko Popma <re...@gmail.com> wrote:
> >
> >
> >
> >
> >
> > (Shameless plug) Every java main() method deserves http://picocli.info
> >> On May 9, 2017, at 15:35, Gary Gregory <ga...@gmail.com> wrote:
> >>
> >> Hi All,
> >>
> >> On Mon, May 8, 2017 at 10:46 PM, Ralph Goers <
> ralph.goers@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... :-(
> >
> > 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 <bo...@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 <mi...@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.goers@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.staldal@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.staldal@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 <
> >>> garydgregory@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" <bo...@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 <garydgregory@gmail.com
> >
> >>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> On Apr 23, 2017 9:19 AM, "Matt Sicker" <bo...@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 <
> garydgregory@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.goers@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.goers@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 <
> >>>>>>>>>> garydgregory@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 <
> >>> boards@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 <
> >>> bodewig@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 <bo...@gmail.com>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Matt Sicker <bo...@gmail.com>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> [image: MagineTV]
> >>>>>>>>
> >>>>>>>> *Mikael Ståldal*
> >>>>>>>> Senior software developer
> >>>>>>>>
> >>>>>>>> *Magine TV*
> >>>>>>>> mikael.staldal@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.staldal@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.staldal@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 <bo...@gmail.com>
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >> E-Mail: garydgregory@gmail.com | ggregory@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
>
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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
Re: Java 9 modules
Posted by Apache <ra...@dslextreme.com>.
I read that previously but if Log4J implements modules I don't see how the nodal appenders or flume appender can work.
I also got a reply to my query about referencing dependencies that are not yet modularized and the recommendation is to only use the manifest entry and not have a module-info.java until all dependencies are modularized.
> On May 9, 2017, at 12:18 AM, Remko Popma <re...@gmail.com> wrote:
>
>
>
>
>
> (Shameless plug) Every java main() method deserves http://picocli.info
>> On May 9, 2017, at 15:35, Gary Gregory <ga...@gmail.com> wrote:
>>
>> Hi All,
>>
>> On Mon, May 8, 2017 at 10:46 PM, Ralph Goers <ra...@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... :-(
>
> 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 <bo...@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 <mi...@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.goers@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.staldal@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.staldal@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 <
>>> garydgregory@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" <bo...@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 <ga...@gmail.com>
>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Apr 23, 2017 9:19 AM, "Matt Sicker" <bo...@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 <ga...@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.goers@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.goers@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 <
>>>>>>>>>> garydgregory@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 <
>>> boards@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 <
>>> bodewig@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 <bo...@gmail.com>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> [image: MagineTV]
>>>>>>>>
>>>>>>>> *Mikael Ståldal*
>>>>>>>> Senior software developer
>>>>>>>>
>>>>>>>> *Magine TV*
>>>>>>>> mikael.staldal@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.staldal@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.staldal@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 <bo...@gmail.com>
>>>
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@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
Re: Java 9 modules
Posted by Apache <ra...@dslextreme.com>.
It will require that modules that have Log4J plugins declare the package containing the plugins as "open" to Log4J. Apparently we will also have to call Module.addReads() to be able to access the module.
Ralph
Sent from my iPad
> On May 10, 2017, at 2:40 AM, Mikael Ståldal <mi...@magine.com> wrote:
>
> As far as I can see, we use setAccessible in our plugin loader? Can that be
> a problem?
>
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012571.html
>
> On Wed, May 10, 2017 at 6:34 AM, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> I got further clarification on the jigsaw dev list.
>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012562.html <
>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012562.html>.
>> I am still waiting for an answer about the impact to our plugin system, but
>> I am pretty sure it will continue to work as is.
>>
>> It seems that we should be able to make most of the modules be “proper”
>> modules with a few simple changes. The biggest impact will be that we can’t
>> properly modularize log4j-core until Disruptor and Jackson are modules,
>> since we can’t remove those as optional dependencies from core. We should
>> move everything else that has a dependency to other modules. Those will
>> also have to wait to be “proper” modules until their dependencies are, but
>> they can all use the manifest entry to declare their module names.
>>
>> As for the circularity, there is none because log4j-api will not specify
>> that it requires log4j-core. It will bind to its implementation through a
>> ServiceProvider. I’ve already written that and will commit that portion in
>> a few days. That change doesn’t require Java 9 and will be backward
>> compatible.
>>
>> As for the actual modularization, I still think we should wait to declare
>> them, at least until the dust settles and we are closer to an actual
>> release. But I think we should continue looking at breaking stuff out of
>> core to make it easier to create the modules when the time comes.
>>
>> Ralph
>>
>>
>>>> On May 9, 2017, at 8:43 AM, Ralph Goers <ra...@dslextreme.com>
>>> wrote:
>>>
>>> While it may sound reasonable, it is not. Matt’s point about
>> LoggerFinder and our support of NoSQL appenders and the like is proof that
>> there are valid reasons for circularities. We are just lucky that Jackson
>> and Disruptor don’t seem to do logging or we would have circularities there
>> too.
>>>
>>> BTW - I got a private answer to my question on this. It was that I
>> should post my question to the jigsaw dev list but that I should expect
>> that Log4j - or at least pieces of it - can’t be modularized.
>>>
>>> Ralph
>>>
>>>> On May 9, 2017, at 8:24 AM, Gary Gregory <ga...@gmail.com>
>> wrote:
>>>>
>>>> On May 9, 2017 12:18 AM, "Remko Popma" <remko.popma@gmail.com <mailto:
>> remko.popma@gmail.com>> wrote:
>>>>
>>>>
>>>> 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
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.staldal@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.
Re: Java 9 modules
Posted by Mikael Ståldal <mi...@magine.com>.
As far as I can see, we use setAccessible in our plugin loader? Can that be
a problem?
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012571.html
On Wed, May 10, 2017 at 6:34 AM, Ralph Goers <ra...@dslextreme.com>
wrote:
> I got further clarification on the jigsaw dev list.
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012562.html <
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012562.html>.
> I am still waiting for an answer about the impact to our plugin system, but
> I am pretty sure it will continue to work as is.
>
> It seems that we should be able to make most of the modules be “proper”
> modules with a few simple changes. The biggest impact will be that we can’t
> properly modularize log4j-core until Disruptor and Jackson are modules,
> since we can’t remove those as optional dependencies from core. We should
> move everything else that has a dependency to other modules. Those will
> also have to wait to be “proper” modules until their dependencies are, but
> they can all use the manifest entry to declare their module names.
>
> As for the circularity, there is none because log4j-api will not specify
> that it requires log4j-core. It will bind to its implementation through a
> ServiceProvider. I’ve already written that and will commit that portion in
> a few days. That change doesn’t require Java 9 and will be backward
> compatible.
>
> As for the actual modularization, I still think we should wait to declare
> them, at least until the dust settles and we are closer to an actual
> release. But I think we should continue looking at breaking stuff out of
> core to make it easier to create the modules when the time comes.
>
> Ralph
>
>
> > On May 9, 2017, at 8:43 AM, Ralph Goers <ra...@dslextreme.com>
> wrote:
> >
> > While it may sound reasonable, it is not. Matt’s point about
> LoggerFinder and our support of NoSQL appenders and the like is proof that
> there are valid reasons for circularities. We are just lucky that Jackson
> and Disruptor don’t seem to do logging or we would have circularities there
> too.
> >
> > BTW - I got a private answer to my question on this. It was that I
> should post my question to the jigsaw dev list but that I should expect
> that Log4j - or at least pieces of it - can’t be modularized.
> >
> > Ralph
> >
> >> On May 9, 2017, at 8:24 AM, Gary Gregory <ga...@gmail.com>
> wrote:
> >>
> >> On May 9, 2017 12:18 AM, "Remko Popma" <remko.popma@gmail.com <mailto:
> remko.popma@gmail.com>> wrote:
> >>
> >>
> >> 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
>
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior software developer
*Magine TV*
mikael.staldal@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.
Re: Java 9 modules
Posted by Matt Sicker <bo...@gmail.com>.
Sounds pretty good to me, thanks for getting clarification. I haven't
looked at the JPMS API yet, but by the sounds of it, we may be able to use
it for some interesting plugin things as it is.
On 9 May 2017 at 23:34, Ralph Goers <ra...@dslextreme.com> wrote:
> I got further clarification on the jigsaw dev list.
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012562.html <
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012562.html>.
> I am still waiting for an answer about the impact to our plugin system, but
> I am pretty sure it will continue to work as is.
>
> It seems that we should be able to make most of the modules be “proper”
> modules with a few simple changes. The biggest impact will be that we can’t
> properly modularize log4j-core until Disruptor and Jackson are modules,
> since we can’t remove those as optional dependencies from core. We should
> move everything else that has a dependency to other modules. Those will
> also have to wait to be “proper” modules until their dependencies are, but
> they can all use the manifest entry to declare their module names.
>
> As for the circularity, there is none because log4j-api will not specify
> that it requires log4j-core. It will bind to its implementation through a
> ServiceProvider. I’ve already written that and will commit that portion in
> a few days. That change doesn’t require Java 9 and will be backward
> compatible.
>
> As for the actual modularization, I still think we should wait to declare
> them, at least until the dust settles and we are closer to an actual
> release. But I think we should continue looking at breaking stuff out of
> core to make it easier to create the modules when the time comes.
>
> Ralph
>
>
> > On May 9, 2017, at 8:43 AM, Ralph Goers <ra...@dslextreme.com>
> wrote:
> >
> > While it may sound reasonable, it is not. Matt’s point about
> LoggerFinder and our support of NoSQL appenders and the like is proof that
> there are valid reasons for circularities. We are just lucky that Jackson
> and Disruptor don’t seem to do logging or we would have circularities there
> too.
> >
> > BTW - I got a private answer to my question on this. It was that I
> should post my question to the jigsaw dev list but that I should expect
> that Log4j - or at least pieces of it - can’t be modularized.
> >
> > Ralph
> >
> >> On May 9, 2017, at 8:24 AM, Gary Gregory <ga...@gmail.com>
> wrote:
> >>
> >> On May 9, 2017 12:18 AM, "Remko Popma" <remko.popma@gmail.com <mailto:
> remko.popma@gmail.com>> wrote:
> >>
> >>
> >> 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
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Java 9 modules
Posted by Ralph Goers <ra...@dslextreme.com>.
I got further clarification on the jigsaw dev list. http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012562.html <http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012562.html>. I am still waiting for an answer about the impact to our plugin system, but I am pretty sure it will continue to work as is.
It seems that we should be able to make most of the modules be “proper” modules with a few simple changes. The biggest impact will be that we can’t properly modularize log4j-core until Disruptor and Jackson are modules, since we can’t remove those as optional dependencies from core. We should move everything else that has a dependency to other modules. Those will also have to wait to be “proper” modules until their dependencies are, but they can all use the manifest entry to declare their module names.
As for the circularity, there is none because log4j-api will not specify that it requires log4j-core. It will bind to its implementation through a ServiceProvider. I’ve already written that and will commit that portion in a few days. That change doesn’t require Java 9 and will be backward compatible.
As for the actual modularization, I still think we should wait to declare them, at least until the dust settles and we are closer to an actual release. But I think we should continue looking at breaking stuff out of core to make it easier to create the modules when the time comes.
Ralph
> On May 9, 2017, at 8:43 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> While it may sound reasonable, it is not. Matt’s point about LoggerFinder and our support of NoSQL appenders and the like is proof that there are valid reasons for circularities. We are just lucky that Jackson and Disruptor don’t seem to do logging or we would have circularities there too.
>
> BTW - I got a private answer to my question on this. It was that I should post my question to the jigsaw dev list but that I should expect that Log4j - or at least pieces of it - can’t be modularized.
>
> Ralph
>
>> On May 9, 2017, at 8:24 AM, Gary Gregory <ga...@gmail.com> wrote:
>>
>> On May 9, 2017 12:18 AM, "Remko Popma" <remko.popma@gmail.com <ma...@gmail.com>> wrote:
>>
>>
>> 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
Re: Java 9 modules
Posted by Ralph Goers <ra...@dslextreme.com>.
While it may sound reasonable, it is not. Matt’s point about LoggerFinder and our support of NoSQL appenders and the like is proof that there are valid reasons for circularities. We are just lucky that Jackson and Disruptor don’t seem to do logging or we would have circularities there too.
BTW - I got a private answer to my question on this. It was that I should post my question to the jigsaw dev list but that I should expect that Log4j - or at least pieces of it - can’t be modularized.
Ralph
> On May 9, 2017, at 8:24 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> On May 9, 2017 12:18 AM, "Remko Popma" <remko.popma@gmail.com <ma...@gmail.com>> wrote:
>
>
> 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
Re: Java 9 modules
Posted by Gary Gregory <ga...@gmail.com>.
On May 9, 2017 12:18 AM, "Remko Popma" <re...@gmail.com> wrote:
(Shameless plug) Every java main() method deserves http://picocli.info
> On May 9, 2017, at 15:35, Gary Gregory <ga...@gmail.com> wrote:
>
> Hi All,
>
> On Mon, May 8, 2017 at 10:46 PM, Ralph Goers <ra...@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... :-(
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 <bo...@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 <mi...@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.goers@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.staldal@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.staldal@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 <
>> garydgregory@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" <bo...@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 <ga...@gmail.com>
>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Apr 23, 2017 9:19 AM, "Matt Sicker" <bo...@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 <ga...@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.goers@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.goers@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 <
>>>>>>>>> garydgregory@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 <
>> boards@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 <
>> bodewig@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 <bo...@gmail.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> [image: MagineTV]
>>>>>>>
>>>>>>> *Mikael Ståldal*
>>>>>>> Senior software developer
>>>>>>>
>>>>>>> *Magine TV*
>>>>>>> mikael.staldal@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.staldal@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.staldal@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 <bo...@gmail.com>
>>
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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
Re: Java 9 modules
Posted by Remko Popma <re...@gmail.com>.
(Shameless plug) Every java main() method deserves http://picocli.info
> On May 9, 2017, at 15:35, Gary Gregory <ga...@gmail.com> wrote:
>
> Hi All,
>
> On Mon, May 8, 2017 at 10:46 PM, Ralph Goers <ra...@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... :-(
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 <bo...@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 <mi...@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.goers@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.staldal@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.staldal@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 <
>> garydgregory@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" <bo...@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 <ga...@gmail.com>
>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Apr 23, 2017 9:19 AM, "Matt Sicker" <bo...@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 <ga...@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.goers@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.goers@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 <
>>>>>>>>> garydgregory@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 <
>> boards@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 <
>> bodewig@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 <bo...@gmail.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> [image: MagineTV]
>>>>>>>
>>>>>>> *Mikael Ståldal*
>>>>>>> Senior software developer
>>>>>>>
>>>>>>> *Magine TV*
>>>>>>> mikael.staldal@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.staldal@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.staldal@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 <bo...@gmail.com>
>>
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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
Re: Java 9 modules
Posted by Gary Gregory <ga...@gmail.com>.
Hi All,
On Mon, May 8, 2017 at 10:46 PM, Ralph Goers <ra...@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 <bo...@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 <mi...@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.goers@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.staldal@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.staldal@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 <
> garydgregory@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" <bo...@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 <ga...@gmail.com>
> >>> wrote:
> >>>>>>>
> >>>>>>>> On Apr 23, 2017 9:19 AM, "Matt Sicker" <bo...@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 <ga...@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.goers@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.goers@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 <
> >>>>>>> garydgregory@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 <
> boards@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 <
> bodewig@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 <bo...@gmail.com>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Matt Sicker <bo...@gmail.com>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> [image: MagineTV]
> >>>>>
> >>>>> *Mikael Ståldal*
> >>>>> Senior software developer
> >>>>>
> >>>>> *Magine TV*
> >>>>> mikael.staldal@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.staldal@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.staldal@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 <bo...@gmail.com>
>
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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
Re: Java 9 modules
Posted by Matt Sicker <bo...@gmail.com>.
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 <mi...@magine.com> 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 <ra...@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.
> >
> > 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 <bo...@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 <mi...@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.goers@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.staldal@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.staldal@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 <
> > garydgregory@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" <bo...@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 <ga...@gmail.com>
> > >>> wrote:
> > >>>>>>>
> > >>>>>>>> On Apr 23, 2017 9:19 AM, "Matt Sicker" <bo...@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 <garydgregory@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.goers@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.goers@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 <
> > >>>>>>> garydgregory@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 <
> > boards@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 <
> > bodewig@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 <bo...@gmail.com>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> --
> > >>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> Matt Sicker <bo...@gmail.com>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>> [image: MagineTV]
> > >>>>>
> > >>>>> *Mikael Ståldal*
> > >>>>> Senior software developer
> > >>>>>
> > >>>>> *Magine TV*
> > >>>>> mikael.staldal@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.staldal@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.staldal@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 <bo...@gmail.com>
> >
> >
> >
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.staldal@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 <bo...@gmail.com>
Re: Java 9 modules
Posted by Mikael Ståldal <mi...@magine.com>.
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 <ra...@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.
>
> 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 <bo...@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 <mi...@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.goers@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.staldal@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.staldal@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 <
> garydgregory@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" <bo...@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 <ga...@gmail.com>
> >>> wrote:
> >>>>>>>
> >>>>>>>> On Apr 23, 2017 9:19 AM, "Matt Sicker" <bo...@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 <ga...@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.goers@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.goers@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 <
> >>>>>>> garydgregory@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 <
> boards@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 <
> bodewig@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 <bo...@gmail.com>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Matt Sicker <bo...@gmail.com>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> [image: MagineTV]
> >>>>>
> >>>>> *Mikael Ståldal*
> >>>>> Senior software developer
> >>>>>
> >>>>> *Magine TV*
> >>>>> mikael.staldal@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.staldal@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.staldal@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 <bo...@gmail.com>
>
>
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior software developer
*Magine TV*
mikael.staldal@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.
Re: Java 9 modules
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <bo...@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 <mi...@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 <ra...@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.staldal@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.staldal@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 <garydgregory@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" <bo...@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 <ga...@gmail.com>
>>> wrote:
>>>>>>>
>>>>>>>> On Apr 23, 2017 9:19 AM, "Matt Sicker" <bo...@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 <ga...@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.goers@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.goers@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 <
>>>>>>> garydgregory@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 <boards@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 <bodewig@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 <bo...@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> [image: MagineTV]
>>>>>
>>>>> *Mikael Ståldal*
>>>>> Senior software developer
>>>>>
>>>>> *Magine TV*
>>>>> mikael.staldal@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.staldal@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.staldal@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 <bo...@gmail.com>
Re: Java 9 modules
Posted by Matt Sicker <bo...@gmail.com>.
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 <mi...@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 <ra...@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.staldal@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.staldal@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 <garydgregory@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" <bo...@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 <ga...@gmail.com>
> > wrote:
> > >>>>
> > >>>>> On Apr 23, 2017 9:19 AM, "Matt Sicker" <bo...@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 <ga...@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.goers@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.goers@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 <
> > >>>> garydgregory@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 <boards@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 <bodewig@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 <bo...@gmail.com>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> --
> > >>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Matt Sicker <bo...@gmail.com>
> > >>>>
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> [image: MagineTV]
> > >>
> > >> *Mikael Ståldal*
> > >> Senior software developer
> > >>
> > >> *Magine TV*
> > >> mikael.staldal@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.staldal@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.staldal@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 <bo...@gmail.com>
Re: Java 9 modules
Posted by Mikael Ståldal <mi...@magine.com>.
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 <ra...@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 <mi...@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.staldal@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 <ga...@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" <bo...@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 <ga...@gmail.com>
> wrote:
> >>>>
> >>>>> On Apr 23, 2017 9:19 AM, "Matt Sicker" <bo...@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 <ga...@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" <ra...@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.goers@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 <
> >>>> garydgregory@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 <boards@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 <bodewig@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 <bo...@gmail.com>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Matt Sicker <bo...@gmail.com>
> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >> [image: MagineTV]
> >>
> >> *Mikael Ståldal*
> >> Senior software developer
> >>
> >> *Magine TV*
> >> mikael.staldal@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.staldal@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.staldal@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.
Re: Java 9 modules
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <mi...@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 <mi...@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 <ga...@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" <bo...@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 <ga...@gmail.com> wrote:
>>>>
>>>>> On Apr 23, 2017 9:19 AM, "Matt Sicker" <bo...@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 <ga...@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" <ra...@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.goers@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 <
>>>> garydgregory@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 <boards@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 <bodewig@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 <bo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>
>>
>>
>>
>> --
>> [image: MagineTV]
>>
>> *Mikael Ståldal*
>> Senior software developer
>>
>> *Magine TV*
>> mikael.staldal@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.staldal@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.
Re: Java 9 modules
Posted by Mikael Ståldal <mi...@magine.com>.
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 <mi...@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 <ga...@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" <bo...@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 <ga...@gmail.com> wrote:
>> >
>> > > On Apr 23, 2017 9:19 AM, "Matt Sicker" <bo...@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 <ga...@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" <ra...@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.goers@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 <
>> > garydgregory@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 <boards@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 <bodewig@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 <bo...@gmail.com>
>> > > > > >>>
>> > > > > >>
>> > > > > >>
>> > > > > >>
>> > > > > >> --
>> > > > > >> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
>> > >
>> >
>> >
>> >
>> > --
>> > Matt Sicker <bo...@gmail.com>
>> >
>>
>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.staldal@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.staldal@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.
Re: Java 9 modules
Posted by Mikael Ståldal <mi...@magine.com>.
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 <ga...@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" <bo...@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 <ga...@gmail.com> wrote:
> >
> > > On Apr 23, 2017 9:19 AM, "Matt Sicker" <bo...@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 <ga...@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" <ra...@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.goers@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 <
> > garydgregory@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 <bo...@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 <bo...@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/java-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 <bo...@gmail.com>
> > > > > >>>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
> > >
> >
> >
> >
> > --
> > Matt Sicker <bo...@gmail.com>
> >
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior software developer
*Magine TV*
mikael.staldal@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.
Re: Java 9 modules
Posted by Gary Gregory <ga...@gmail.com>.
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" <bo...@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 <ga...@gmail.com> wrote:
>
> > On Apr 23, 2017 9:19 AM, "Matt Sicker" <bo...@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 <ga...@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" <ra...@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.goers@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 <
> garydgregory@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 <bo...@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 <bo...@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/java-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 <bo...@gmail.com>
> > > > >>>
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
> >
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
Re: Java 9 modules
Posted by Matt Sicker <bo...@gmail.com>.
“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 <ga...@gmail.com> wrote:
> On Apr 23, 2017 9:19 AM, "Matt Sicker" <bo...@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 <ga...@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" <ra...@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.goers@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 <ga...@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 <bo...@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 <bo...@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/java-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 <bo...@gmail.com>
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
>
--
Matt Sicker <bo...@gmail.com>
Re: Java 9 modules
Posted by Gary Gregory <ga...@gmail.com>.
On Apr 23, 2017 9:19 AM, "Matt Sicker" <bo...@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 <ga...@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" <ra...@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 <ra...@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 <ga...@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 <bo...@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 <bo...@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/java-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 <bo...@gmail.com>
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> E-Mail: garydgregory@gmail.com | ggregory@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=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 <bo...@gmail.com>
Re: Java 9 modules
Posted by Matt Sicker <bo...@gmail.com>.
Oh, and I suppose this is a great time to gloat: if Java 9 turns out to be
a dud, there's always Scala and Kotlin as interesting alternatives to
continue the general Java platform. Depending on how this goes, it's even
possible that a company like IBM or Red Hat will fork Java into a new
language. Then, after a few years of fragmentation, Oracle gives up and
donates it to the ASF after it's already irrelevant.
On 23 April 2017 at 11:19, Matt Sicker <bo...@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.
>
> On 23 April 2017 at 11:04, Gary Gregory <ga...@gmail.com> wrote:
>
>> Worse: Are Java 9 modules its Titanic?
>> https://developer.jboss.org/blogs/scott.stark/2017/04/14/cri
>> tical-deficiencies-in-jigsawjsr-376-java-platform-module-
>> system-ec-member-concerns
>>
>>
>> Gary
>>
>> On Apr 22, 2017 5:02 PM, "Ralph Goers" <ra...@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/ques
>> tions/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 <ra...@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 <ga...@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 <bo...@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 <bo...@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/java-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 <bo...@gmail.com>
>> > >>>
>> > >>
>> > >>
>> > >>
>> > >> --
>> > >> E-Mail: garydgregory@gmail.com | ggregory@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=cadb800f39946ec62ea2b
>> 1af9fe6a2b8>
>> > >>
>> > >> <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=31ecd1f6b6d1eaf8886ac
>> 902a24de418%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 <bo...@gmail.com>
>
--
Matt Sicker <bo...@gmail.com>
Re: Java 9 modules
Posted by Matt Sicker <bo...@gmail.com>.
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.
On 23 April 2017 at 11:04, Gary Gregory <ga...@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" <ra...@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 <ra...@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 <ga...@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 <bo...@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 <bo...@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/java-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 <bo...@gmail.com>
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> E-Mail: garydgregory@gmail.com | ggregory@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=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 <bo...@gmail.com>
Re: Java 9 modules
Posted by Gary Gregory <ga...@gmail.com>.
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" <ra...@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 <ra...@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 <ga...@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 <bo...@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 <bo...@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/java-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 <bo...@gmail.com>
> >>>
> >>
> >>
> >>
> >> --
> >> E-Mail: garydgregory@gmail.com | ggregory@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
> >
>
>
Re: Java 9 modules
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ra...@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 <ga...@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 <bo...@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 <bo...@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/java-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 <bo...@gmail.com>
>>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@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
>
Re: Java 9 modules
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ga...@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 <bo...@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 <bo...@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/java-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 <bo...@gmail.com>
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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
Re: Java 9 modules
Posted by Gary Gregory <ga...@gmail.com>.
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 <bo...@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 <bo...@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/java-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 <bo...@gmail.com>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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
Re: Java 9 modules
Posted by Matt Sicker <bo...@gmail.com>.
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 <bo...@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/java-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 <bo...@gmail.com>
Re: Java 9 modules
Posted by Stefan Bodewig <bo...@apache.org>.
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/java-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