Re: RFR 8147491: module graph consistency checks after jlink plugins operate on module pool

Hi Mandy, Paul, Thanks for the reviews. Updated webrev as per suggestions: http://cr.openjdk.java.net/~sundar/8147491/webrev.02/ Thanks, -Sundar On 8/25/2016 10:50 PM, Paul Sandoz wrote: >> On 25 Aug 2016, at 10:15, Paul Sandoz wrote: >> >> >>> On 25 Aug 2016, at

Re: Discover modulename

On 25/08/2016 18:28, Robert Scholte wrote: Hi, JavaOne spoiler alert: I've been able to add this kind of information to the output of the maven-dependency-plugin: [INFO] --- maven-dependency-plugin:3.0.0-SNAPSHOT:list (default-cli) @ maven-dependency-plugin --- [INFO] [INFO] The following

Re: RFR 8147491: module graph consistency checks after jlink plugins operate on module pool

> On Aug 25, 2016, at 10:15 AM, Paul Sandoz wrote: > > >> On 25 Aug 2016, at 09:33, Mandy Chung wrote: >> >> >>> On Aug 25, 2016, at 7:18 AM, Sundararajan Athijegannathan >>> wrote: >>> >>> Please

Re: Discover modulename

Hi, JavaOne spoiler alert: I've been able to add this kind of information to the output of the maven-dependency-plugin: [INFO] --- maven-dependency-plugin:3.0.0-SNAPSHOT:list (default-cli) @ maven-dependency-plugin --- [INFO] [INFO] The following files have been resolved: [INFO]

Re: RFR 8147491: module graph consistency checks after jlink plugins operate on module pool

> On 25 Aug 2016, at 10:15, Paul Sandoz wrote: > > >> On 25 Aug 2016, at 09:33, Mandy Chung wrote: >> >> >>> On Aug 25, 2016, at 7:18 AM, Sundararajan Athijegannathan >>> wrote: >>> >>> Please review

Re: RFR 8147491: module graph consistency checks after jlink plugins operate on module pool

> On 25 Aug 2016, at 09:33, Mandy Chung wrote: > > >> On Aug 25, 2016, at 7:18 AM, Sundararajan Athijegannathan >> wrote: >> >> Please review http://cr.openjdk.java.net/~sundar/8147491/webrev.01/ for >>

Re: RFR 8147491: module graph consistency checks after jlink plugins operate on module pool

> On Aug 25, 2016, at 7:18 AM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8147491/webrev.01/ for > https://bugs.openjdk.java.net/browse/JDK-8147491 I think ResourcePoolConfiguration::validate should

Re: JDK9 and Gradle modular quickstart

I can't comment on Dave's intentions to put more effort into the quickstart project for its own sake, since it was done as a simple starting point for work we need to do to modify JavaFX to build with a Jigsaw-capable JDK 9. I can say that as Dave folds this into the JavaFX build, he will do

Re: JDK9 and Gradle modular quickstart

Hi David, Thank you for sharing this. A couple thoughts - - you might consider posting it in a repo as opposed to a zip so we can follow changes (bitbucket, kenai, whatever) - adding an .hgignore - reading the note at the top of your build.gradle, this comment caught my attention

Re: JDK9 and Gradle modular quickstart

Thanks for sharing this, David. We definitely have plans to support modules "natively" but found like you that Gradle 3.0 makes it possible to work around pretty easily. 2016-08-25 15:19 GMT+02:00 David Hill : > > Hi, >I mentioned I was working on a modular compilation

JDK9 and Gradle modular quickstart

Hi, I mentioned I was working on a modular compilation with Gradle 3 and JDK9. I have something to share now :-) This adapted quickstart comprises a "module" of two classes, a test class, and a "shim" test class. (The shim is an adapter used for 'white box' style tests).

RE: Question on returning instances of a (not exported) derived class

Hi Peter, thanks for your explanations. I do now understand the behaviour of case [1] ..., thanks! About case [2] you wrote * Are you sure you didn't have the toString() method overridden in InternalData at time of compilation? Yes, I am sure. I agree, this should compile. At least

Re: Question on returning instances of a (not exported) derived class

Hi Martin, Let me try to explain why... On 08/25/2016 08:56 AM, Martin Lehmann wrote: package pkgmain; import pkgx.*; public class Main { public static void main(String[] args) { DataFactory myDataFactory = new DataFactory(); // all OK System.out.println("Factory.createData(): "

Re: Discover modulename

On 25/08/2016 11:26, Robert Scholte wrote: Hi, In an old thread I asked this before and got the following answer: "One way is `jar --file foo.jar -p`. That will print the module descriptor when the JAR file is a modular JAR. There is API support for reading the binary form of the module

Re: Discover modulename

Hi Robert, there are currently two different module descriptor formats, the old one, that is readable by current JDK9 and the new one that is readable by the JDK9-jigsaw, and they are not compatible. If you want to read the module descriptor of asm6-alpha, you need to use the jar from the JDK9

Discover modulename

Hi, In an old thread I asked this before and got the following answer: "One way is `jar --file foo.jar -p`. That will print the module descriptor when the JAR file is a modular JAR. There is API support for reading the binary form of the module declaration too." With the renaming of the

Question on returning instances of a (not exported) derived class

Hi all, I have a question on exporting packages and its handling with derived classes. Any help appreciated! In a module mod.x one package "pkgx" is exported containing 2 classes Data and DataFactory. Another package "pkgxinternal" is not exported and contains the class InternalData which is

Re: jlink cross-targeting

On 24/08/2016 21:53, Sander Mak wrote: : I thought I'd fire up a Windows VM, running on an OSX host. Downloaded the win32 jigsaw-ea build to the host, pointed host's jlink at the win32 jmods directory and created a runtime image targeting Windows. After moving this image from the host to