Re: Evidence of incompatibility (was Some suggested patches and improvements)

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 wrote: > > Yes, I had to do something similar. But this is fragile if you don’t always > do a cl

Re: Evidence of incompatibility (was Some suggested patches and improvements)

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 wrote: > > Maven support and tool support in general for

Re: Evidence of incompatibility (was Some suggested patches and improvements)

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 you could look at that includes OSGi support. The key here is that I delete the java9 c

Re: Some suggested patches and improvements

On 18.05.2017 02:29, Gregg Wonderly wrote: I understand that you might feel this is an excessive rant. [snip] I will be looking at Swift and/or Go and just moving on. All the best on your future technological adventures, in any case, whether they are with Java, or something else! Please do

Re: Some suggested patches and improvements

On 18/05/2017 01:29, Gregg Wonderly wrote: I understand that you might feel this is an excessive rant. But, practically I know of Java applications around the world which all use things like Spring. Spring seems to be making great progress, here's a recent write-up from Juergen Hoeller:

Re: Evidence of incompatibility (was Some suggested patches and improvements)

On 18/05/2017 04:28, Ralph Goers 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 proce

Re: Evidence of incompatibility (was Some suggested patches and improvements)

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

Re: Some suggested patches and improvements

> On May 17, 2017, at 3:08 AM, Andrew Dinn wrote: > > On 16/05/17 19:11, Gregg Wonderly wrote: > > > >> 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? This

Re: Evidence of incompatibility (was Some suggested patches and improvements)

On 17/05/2017 20:56, Robert Gibson wrote: : And of course the intersection of these issues makes things even more complicated. At this point I would settle for being able to add a command-line flag to get our app to run, but despite testing EA builds for over a year and assiduously flagging

Re: Evidence of incompatibility (was Some suggested patches and improvements)

On 17 May 2017, at 20:50, Alan Bateman wrote: > > On 17/05/2017 18:26, Eric Johnson wrote: > >> : >> 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

Re: Evidence of incompatibility (was Some suggested patches and improvements)

On 17/05/2017 18:26, Eric Johnson wrote: : 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 be

Evidence of incompatibility (was Some suggested patches and improvements)

On Wed, May 17, 2017 at 1:08 AM, Andrew Dinn wrote: > On 16/05/17 19:11, Gregg Wonderly wrote: > > > > > 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

Re: Some suggested patches and improvements

On 16/05/17 19:11, Gregg Wonderly wrote: > 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? regards, Andrew Dinn ---

Re: Some suggested patches and improvements

On 16/05/2017 19:11, Gregg Wonderly wrote: At some level, this is the problem that is paramount on the release of JDK-9. Earlier Mark asked if the Eclipse foundation had to approve or be ready to support all of what JDK-9/Jigsaw supports before it could be released. The statement below seems

Re: Some suggested patches and improvements

At some level, this is the problem that is paramount on the release of JDK-9. Earlier Mark asked if the Eclipse foundation had to approve or be ready to support all of what JDK-9/Jigsaw supports before it could be released. The statement below seems to stipulate that “all Java software must be

Re: Some suggested patches and improvements

On 05/16/2017 06:02 AM, Alan Bateman wrote: On 12/05/2017 14:31, David M. Lloyd wrote: : There is a lot more to #5, something that will become clear when you work through all the scenarios. The JSR and spec part are minor though but I'd prefer to hold off until there is more discussion on t

Re: Some suggested patches and improvements

On 12/05/2017 14:31, David M. Lloyd wrote: : There is a lot more to #5, something that will become clear when you work through all the scenarios. The JSR and spec part are minor though but I'd prefer to hold off until there is more discussion on this topic in the JSR. I'd rather not hold o

Re: Some suggested patches and improvements

On 12/05/2017 14:31, David M. Lloyd wrote: : #4 seems to be working around the outcome of issue #CyclicDependences in the JSR. I also don't wish to comment on that except to say that introducing system properties to skip specified checks is highly problematic from a conformance perspective.

Re: Some suggested patches and improvements

On 12 May 2017 at 17:31, David M. Lloyd wrote: >>> 4. Make run-time cycle checking optional >> >> My opinion is that run-time cycles are inevitable. The proposed >> solutions (refactoring to API vs Impl) is not particularly good in an >> open source context. I'm also concerned that "requires stati

Re: Some suggested patches and improvements

On 12 May 2017 at 11:22, Alan Bateman wrote: > However for #3 then you've > missed several important error cases, e.g. illegal package names, or the > package is already in another module defined to the class loader. These checks are already present in implAddPackage, so why duplicate those check

Re: Some suggested patches and improvements

On 05/12/2017 01:02 PM, David M. Lloyd wrote: On 05/12/2017 08:31 AM, David M. Lloyd wrote: On 05/12/2017 03:22 AM, Alan Bateman wrote: On 12/05/2017 01:43, David M. Lloyd wrote: I've proposed five patches to the jpms-spec-experts list [1..5] for discussion. The patches are as follows: [.

Re: Some suggested patches and improvements

On 05/12/2017 08:31 AM, David M. Lloyd wrote: On 05/12/2017 03:22 AM, Alan Bateman wrote: On 12/05/2017 01:43, David M. Lloyd wrote: I've proposed five patches to the jpms-spec-experts list [1..5] for discussion. The patches are as follows: [...] 3. Layer primitive: addPackage() - allows M

Re: Some suggested patches and improvements

On 12.05.2017 18:49, Michael Nascimento wrote: #1-#3, IMHO, meet the needs of a niche who knows how to work around these issues using other ways (although inconvenient). I see me as someone needing this, and only having hints about how to make it work, that are based on annotation processors

Re: Some suggested patches and improvements

#1-#3, IMHO, meet the needs of a niche who knows how to work around these issues using other ways (although inconvenient). 4 and 5 are solutions for problems any developer assembling a medium-large application will definitely face and therefore are essential in my point of view since it'd be unrea

Re: Some suggested patches and improvements

On 05/12/2017 09:37 AM, Stephen Colebourne wrote: On 12 May 2017 at 01:43, David M. Lloyd wrote: 1. Layer primitive: addExports() - mirrors the existing Module.addExports() method for ModuleLayer.Controllers 2. Layer primitive: addUses() - mirrors the existing Module.addUses() method for Module

Re: Some suggested patches and improvements

On 12 May 2017 at 17:37, Stephen Colebourne wrote: > On 12 May 2017 at 01:43, David M. Lloyd wrote: >> 1. Layer primitive: addExports() - mirrors the existing Module.addExports() >> method for ModuleLayer.Controllers >> 2. Layer primitive: addUses() - mirrors the existing Module.addUses() method

Re: Some suggested patches and improvements

On 12 May 2017 at 01:43, David M. Lloyd wrote: > 1. Layer primitive: addExports() - mirrors the existing Module.addExports() > method for ModuleLayer.Controllers > 2. Layer primitive: addUses() - mirrors the existing Module.addUses() method > for ModuleLayer.Controllers > 3. Layer primitive: addPa

Re: Some suggested patches and improvements

On 05/12/2017 03:22 AM, Alan Bateman wrote: On 12/05/2017 01:43, David M. Lloyd wrote: I've proposed five patches to the jpms-spec-experts list [1..5] for discussion. The patches are as follows: 1. Layer primitive: addExports() - mirrors the existing Module.addExports() method for ModuleLay

Re: Some suggested patches and improvements

On 12/05/2017 01:43, David M. Lloyd wrote: I've proposed five patches to the jpms-spec-experts list [1..5] for discussion. The patches are as follows: 1. Layer primitive: addExports() - mirrors the existing Module.addExports() method for ModuleLayer.Controllers 2. Layer primitive: addUses()

Re: Some suggested patches and improvements

gsaw-dev" Sent: Thursday, May 11, 2017 5:43:09 PM Subject: Some suggested patches and improvements I've proposed five patches to the jpms-spec-experts list [1..5] for discussion. The patches are as follows: 1. Layer primitive: addExports() - mirrors the existing Modul

Some suggested patches and improvements

I've proposed five patches to the jpms-spec-experts list [1..5] for discussion. The patches are as follows: 1. Layer primitive: addExports() - mirrors the existing Module.addExports() method for ModuleLayer.Controllers 2. Layer primitive: addUses() - mirrors the existing Module.addUses() meth