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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >> <mailto:[email protected]> wrote: >>>>> >>>>> On May 9, 2017 12:18 AM, "Remko Popma" <[email protected] <mailto: >> [email protected]> <mailto:[email protected]> <mailto: >> [email protected]>> 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 <[email protected]>
