Evidence of incompatibility (was Some suggested patches and improvements)

[Russell Gold]

No, the cleanup of the java 9 classes is bound to the compile step. Therefore, you don’t need to do a clean first. That would have been very aggravating.

> On May 18, 2017, at 11:38 AM, Ralph Goers <rgoers at apache.org> wrote:
> 
> Yes, I had to do something similar. But this is fragile if you don’t always do a clean or explicitly include a clean step that runs to clean up those items even if you didn’t specify it.
> 
> Ralph
> 
>> On May 18, 2017, at 7:20 AM, Russell Gold <russell.gold at oracle.com <mailto:russell.gold at oracle.com>> wrote:
>> 
>> Maven support and tool support in general for MR Jars is very poor at the moment - including the bundle plugin. I do have a working example <https://github.com/javaee/gmbal-pfl/blob/master/pfl-basic/pom.xml> you could look at that includes OSGi support. The key here is that I delete the java9 classes before computing the OSGi manifest, and only compile them before building the jar. 
>> 
>> Russ
>> 
>>> On May 17, 2017, at 11:28 PM, Ralph Goers <rgoers at apache.org <mailto:rgoers at apache.org>> wrote:
>>> 
>>> 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> <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 <mailto:eric at tibco.com>> wrote:
>>>> 
>>>> On Wed, May 17, 2017 at 1:08 AM, Andrew Dinn <adinn at redhat.com <mailto: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 <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
>>>>> -----------
>>>>> 
>>>> 
>>> 
>> 
>