Evidence of incompatibility (was Some suggested patches and improvements)

[Ralph Goers]

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 <eric at tibco.com> wrote:
> 
> On Wed, May 17, 2017 at 1:08 AM, Andrew Dinn <adinn at 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
>> -----------
>> 
>