I am afraid I have to echo these sentiments to some degree. In trying to get Log4j to support Java 9 I first tried to use a multi-release jar. This failed miserably when the OSGi build tool failed over finding java classes under META-INF. Then it proceeded to complain about the module-info.java files. Why these are java syntax instead of json or something more sensible for something that only contains declarations is a mystery to me. FWIW - the OSGi people don’t seem interested in supporting these new features - https://issues.apache.org/jira/browse/FELIX-5592 <https://issues.apache.org/jira/browse/FELIX-5592>.
I have been able to work around some of these issues but it has made the Log4j build very fragile and I haven’t really begun to see what happens when log4j is actually modularized or runs in an application that is. Ralph > On May 17, 2017, at 10:26 AM, Eric Johnson <e...@tibco.com> wrote: > > On Wed, May 17, 2017 at 1:08 AM, Andrew Dinn <ad...@redhat.com> wrote: > >> On 16/05/17 19:11, Gregg Wonderly wrote: >> >> <ad cohortem hominum snipped (pardon my French)> >> >>> If we really cannot actually keep from breaking 90% of existing Java >>> in the market place when this new JDK release goes out, how valuable >>> is JigSaw really? >> >> citation needed? >> > > I mostly ignore jigsaw, and check in every now and then. > > I have a few co-workers that have poked at migrating their products to Java > 9. So far as I know, nobody has succeeded yet. > > With significant regularity, I see issues pop up on this list that have odd > problems, or persist in being unresolved. One of my favorites at the moment > is automatic module names - a problem that Jigsaw caused for itself. Maybe > that one is resolved for now, but I'm pretty certain that questions will > come flooding back once Java 9 GAs. > > As near as I can tell, applications that compile and run under Java 8 will > mostly *not* "just work" with Java 9 JRE. And that seems to be the lived > experience of my co-workers. If a project is lucky, the only changes > necessary will involve command line parameters. If a team is unlucky, they > will need to rebuild for Java 9. If a team is really unlucky, they will > need to partially or fully modularize. At which point some even more > juggling is required to continue to support Java 7 & 8, if that's required > by customers. > > My overall concerns for Jigsaw: > https://medium.com/@one.eric.johnson/java-9-jigsaw-troubles-4fc406ef41e0 > > I'm not sure what citations you expect to see. There's probably nobody out > there who can afford to pre-flight an EA build of Java 9 against all their > products to see what the actual costs are going to be. Based on anecdotal > evidence from this mailing list, significant players in the Java ecosystem > - build tools, IDEs, critical libraries - have all had to fix unexpected > breakages with Java 9. Obviously, the ones that don't break don't typically > show up, so this is a self-selecting example, but an important one. > > However, even something as simple as requiring changes to command line > parameters in order to launch a program compiled for Java 8 is a breaking > change. The Jigsaw team seems to be taking this as a mere complaint, rather > than as a genuine compatibility issue. > > Here's a challenge back to the Jigsaw team. Can I still do java -jar ... > every existing Java application (without recompile!) that currently > launches that way? I'm even willing to cut some slack and ignore > applications that use com.sun APIs that have been "private" for years. Will > that still work? The Jigsaw community should be able to provide evidence > that's still possible, not that we should be required to provide evidence > that it isn't. > > Eric. > > >> regards, >> >> >> Andrew Dinn >> ----------- >> >
