Re: Project Jigsaw JDK & JRE binaries + test results

[Alan Bateman]

On 14/09/2015 12:30, Mani Sarkar wrote:

Hi all,

Project Jigsaw JDK & JRE binaries + test results are now available on the
Adopt OpenJDK Cloudbees Build farm:

https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/project-jigsaw-openjdk-1.9-linux-x86_64/lastSuccessfulBuild/artifact/



Hi Mani,

There are patches needed to jtreg to support @modules and 
@compile/module that aren't in code-tools/jtreg yet. Hopefully soon and 
that should give you much better test results.


The other issue is that these test runs are running tests that are 
temporarily excluded by jdk/test/ProblemList.jake.txt needed and 
langtools/test/ProblemList.jake.txt. To skip these tests requires 
specifying these files to jtreg -exclude. As to why there are excluded 
tests, then it's partly that there is more work to do on jtreg and 
partly other issues (both product and test issues). Where possible, then 
the exclude list has the JIRA issue tracking the reason why the test is 
temporarily excluded.


-Alan.

Project Jigsaw JDK & JRE binaries + test results

[Mani Sarkar]

Hi all,

Project Jigsaw JDK & JRE binaries + test results are now available on the
Adopt OpenJDK Cloudbees Build farm:

https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/project-jigsaw-openjdk-1.9-linux-x86_64/lastSuccessfulBuild/artifact/

Please share with your communities.

Cheers,
Mani

-- 
@theNeomatrix369 *  |  **Blog
**  |  *LJC Associate & LJC Advocate
(@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project - *MutabilityDetector
*  |  **Bitbucket
* * |  **Github
* * |  **LinkedIn
*
*Come to Devoxx UK 2016:* http://www.devoxx.co.uk/

*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*

Re: Project Jigsaw JDK & JRE binaries + test results

[Mani Sarkar]

Hi Alan,

Thanks for the update - I recollect Jon's email about jtreg needing some
work.

Cheers,
Mani

On Mon, Sep 14, 2015 at 12:51 PM, Alan Bateman 
wrote:

> On 14/09/2015 12:30, Mani Sarkar wrote:
>
>> Hi all,
>>
>> Project Jigsaw JDK & JRE binaries + test results are now available on the
>> Adopt OpenJDK Cloudbees Build farm:
>>
>>
>> https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/project-jigsaw-openjdk-1.9-linux-x86_64/lastSuccessfulBuild/artifact/
>>
>>
>> Hi Mani,
>
> There are patches needed to jtreg to support @modules and @compile/module
> that aren't in code-tools/jtreg yet. Hopefully soon and that should give
> you much better test results.
>
> The other issue is that these test runs are running tests that are
> temporarily excluded by jdk/test/ProblemList.jake.txt needed and
> langtools/test/ProblemList.jake.txt. To skip these tests requires
> specifying these files to jtreg -exclude. As to why there are excluded
> tests, then it's partly that there is more work to do on jtreg and partly
> other issues (both product and test issues). Where possible, then the
> exclude list has the JIRA issue tracking the reason why the test is
> temporarily excluded.
>
> -Alan.
>
>


-- 
@theNeomatrix369 *  |  **Blog
**  |  *LJC Associate & LJC Advocate
(@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project - *MutabilityDetector
*  |  **Bitbucket
* * |  **Github
* * |  **LinkedIn
*
*Come to Devoxx UK 2016:* http://www.devoxx.co.uk/

*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*

JavaxToolsCompiler

[Robert Scholte]

Hi,

On behalf of the Apache Maven team I'd like to ask for advice for changing  
the JavaxToolsCompiler[1]
This implementation is used when java code is being compiled with Maven  
*by default*, so right now when pointing JAVA_HOME to the latest JDK9  
version builds will fail.
There are other ways to compile, e.g. use the fork-parameter[2] or with  
toolchains[3], but what I'd like to know is whether it is still  
possible/valid to use javax.tools.JavaCompiler and is so: how should we  
rewrite this code?


regards,
Robert Scholte

[1]  
https://github.com/codehaus-plexus/plexus-compiler/blob/master/plexus-compilers/plexus-compiler-javac/src/main/java/org/codehaus/plexus/compiler/javac/JavaxToolsCompiler.java
[2]  
http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#fork

[3] http://maven.apache.org/guides/mini/guide-using-toolchains.html

Re: JavaxToolsCompiler

[Robert Scholte]

Op Mon, 14 Sep 2015 20:27:39 +0200 schreef Alan Bateman  
:



On 14/09/2015 17:40, Robert Scholte wrote:

Hi,

On behalf of the Apache Maven team I'd like to ask for advice for  
changing the JavaxToolsCompiler[1]
This implementation is used when java code is being compiled with Maven  
*by default*, so right now when pointing JAVA_HOME to the latest JDK9  
version builds will fail.
There are other ways to compile, e.g. use the fork-parameter[2] or with  
toolchains[3], but what I'd like to know is whether it is still  
possible/valid to use javax.tools.JavaCompiler and is so: how should we  
rewrite this code?


Thanks for bringing this up as a few people have reported issues with  
Maven not finding the compiler.


Just to be clear, are you seeing this issue with the regular JDK 9 EA  
builds or just the Jigsaw EA builds?


Regular JDK9 EA works fine, I'm only seeing it with Jigsaw EA


Did this start when tools.jar went away?


I guess so.

I just did a quick test to check that  
ToolProvider.getSystemJavaCompiler() is returning the system  
JavaCompiler is returned for both builds (and it is). Is the issue that  
you are seeing that getSystemJavaCompiler() is returning null?


Stuart said yes, I think so too.



-Alan.


Robert

Re: javac not enforcing module boundaries?

[Jonathan Gibbons]

https://bugs.openjdk.java.net/browse/JDK-8136505

-- Jon

On 09/14/2015 01:22 AM, Peter Levart wrote:

Hi,

I experimented a little with EA build and found javac behaving a 
little strange. Is this known or expected behaviour?


For example, having the following layout of sources:

modsrc/modA/module-info.java

module modA {
requires modB;
}

modsrc/modA/pkgA/TestA.java

package pkgA;

import pkgB.TypeB;

public class TestA {
public static void main(String[] args) {
TypeB b = new TypeB();
b.getC().getD().helloD();
}
}

modsrc/modB/module-info.java

module modB {
exports pkgB;
requires modC;
}

modsrc/modB/pkgB/TypeB.java

package pkgB;

import pkgC.TypeC;

public class TypeB {
public TypeC getC() {
return new TypeC();
}
}

modsrc/modC/module-info.java

module modC {
exports pkgC;
requires modD;
}

modsrc/modC/pkgC/TypeC.java

package pkgC;

import pkgD.TypeD;

public class TypeC {
public TypeD getD() {
return new TypeD();
}
}

modsrc/modD/module-info.java

module modD {
exports pkgD;
}

modsrc/modD/pkgD/TypeD.java

package pkgD;

public class TypeD {java -modulepath modout -m modA/pkgA.TestA
public void helloD() {
System.out.println("Hello from " + 
this.getClass().getModule());

}
}


and using the following command to compile them:

javac -modulesourcepath modsrc -d modout modsrc/modA/pkgA/TestA.java

They compile without error and produce the following output files:

modout/modA/module-info.class
modout/modA/pkgA/TestA.class
modout/modB/module-info.class
modout/modB/pkgB/TypeB.class
modout/modC/module-info.class
modout/modC/pkgC/TypeC.class
modout/modD/module-info.class
modout/modD/pkgD/TypeD.class


Running the above with the following command:

java -modulepath modout -m modA/pkgA.TestA


Gives the following runtime error:

Exception in thread "main" java.lang.IllegalAccessError: class 
pkgA.TestA (in module: modA) cannot access class pkgC.TypeC (in 
module: modC), modA cannot read modC

at pkgA.TestA.main(modA@/TestA.java:8)


Which is expected. What I didn't expect is that javac did not figure 
this out correctly. Am I missing something and not using javac in the 
right way?



Regards, Peter

Re: jigsaw vs. jsr166 CVS

[Jonathan Gibbons]

On 09/13/2015 11:54 AM, Martin Buchholz wrote:

javadoc does not seem to have any support for -Xmodule, so I don't know how
to fix the "docs" target.

https://bugs.openjdk.java.net/browse/JDK-8136503

-- Jon

Re: CFV: New Jigsaw Committer: Harold Seigel (Karen Kinnear)

[Sundararajan Athijegannathan]

Vote: Yes

On 9/15/2015 12:28 AM, Mike Duigou wrote:

Vote: YES

On 2015-09-11 12:43, jigsaw-dev-requ...@openjdk.java.net wrote:

From: Karen Kinnear 
To: jigsaw-dev 
Subject: CFV: New Jigsaw Committer: Harold Seigel
Message-ID: <7f587027-2bdb-4c37-9fd7-01aebfb17...@oracle.com>
Content-Type: text/plain;charset=us-ascii


I hereby nominate Harold Seigel to Jigsaw Committer.

Harold is a member of the hotspot runtime team and a Reviewer on the
jdk9 project.
Harold has been contributing to Project Jigsaw in the hotspot runtime 
for over a
year, including support for the JVM_* interfaces for modules, boot 
class loader

support for jigsaw and handling jvm bootstrapping issues relative to
jigsaw that are
currently prototyped in the jigsaw/jake forest.

Votes are due by: September 25, 2105 8:00 PST. Only current Jigsaw
Committers [1] are eligible to vote on this nomination. Votes must be
cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [2]

thanks,
Karen
[1] http://openjdk.java.net/census
[2] http://openjdk.java.net/projects/#committer-vote

Harold's changesets for jigsaw/jake: ...

Re: Project Jigsaw: Early-Access Builds available on jdk9.java.net/jigsaw

[Alan Bateman]

On 14/09/2015 17:48, Rahman USTA wrote:

|jlink  --modulepath  %JAVA_HOME%/jmods;mlib  --addmods  com.greetings  
--output  greetingsapp|
After last step, greetingsapp folder generated with all Jigsaw 
modules. How can I include just base mod or other compact mods ?


I assume what you are seeing is service binding with service providers 
and their dependencies getting linked into the image. Can you add 
"--limitmods com.greetings" to the command line and see if that gets you 
the run-time image that you expect?


If you run "greetingsapp/bin/java -listmods" then it will list the names 
of the modules in the generated image.


-Alan

Re: JavaxToolsCompiler

[Alan Bateman]

On 14/09/2015 17:40, Robert Scholte wrote:

Hi,

On behalf of the Apache Maven team I'd like to ask for advice for 
changing the JavaxToolsCompiler[1]
This implementation is used when java code is being compiled with 
Maven *by default*, so right now when pointing JAVA_HOME to the latest 
JDK9 version builds will fail.
There are other ways to compile, e.g. use the fork-parameter[2] or 
with toolchains[3], but what I'd like to know is whether it is still 
possible/valid to use javax.tools.JavaCompiler and is so: how should 
we rewrite this code?


Thanks for bringing this up as a few people have reported issues with 
Maven not finding the compiler.


Just to be clear, are you seeing this issue with the regular JDK 9 EA 
builds or just the Jigsaw EA builds? Did this start when tools.jar went 
away? I just did a quick test to check that 
ToolProvider.getSystemJavaCompiler() is returning the system 
JavaCompiler is returned for both builds (and it is). Is the issue that 
you are seeing that getSystemJavaCompiler() is returning null?


-Alan.

Re: JavaxToolsCompiler

[Stuart McCulloch]

Yes, the issue is that ToolProvider.getSystemJavaCompiler() is returning null 
when using the Jigsaw EA with Maven.

AFAICT this is because it’s now using the service loader mechanism which is 
influenced by the Thread’s context ClassLoader  

The following patch to make sure Maven uses the system context when looking up 
the compiler appears to solve the issue:

https://github.com/codehaus-plexus/plexus-compiler/pull/13

--  
Cheers, Stuart


On Monday, 14 September 2015 at 19:27, Alan Bateman wrote:

> On 14/09/2015 17:40, Robert Scholte wrote:
> > Hi,
> >  
> > On behalf of the Apache Maven team I'd like to ask for advice for  
> > changing the JavaxToolsCompiler[1]
> > This implementation is used when java code is being compiled with  
> > Maven *by default*, so right now when pointing JAVA_HOME to the latest  
> > JDK9 version builds will fail.
> > There are other ways to compile, e.g. use the fork-parameter[2] or  
> > with toolchains[3], but what I'd like to know is whether it is still  
> > possible/valid to use javax.tools.JavaCompiler and is so: how should  
> > we rewrite this code?
> >  
>  
>  
> Thanks for bringing this up as a few people have reported issues with  
> Maven not finding the compiler.
>  
> Just to be clear, are you seeing this issue with the regular JDK 9 EA  
> builds or just the Jigsaw EA builds? Did this start when tools.jar went  
> away? I just did a quick test to check that  
> ToolProvider.getSystemJavaCompiler() is returning the system  
> JavaCompiler is returned for both builds (and it is). Is the issue that  
> you are seeing that getSystemJavaCompiler() is returning null?
>  
> -Alan.
>  
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
> (mailto:dev-unsubscr...@maven.apache.org)
> For additional commands, e-mail: dev-h...@maven.apache.org 
> (mailto:dev-h...@maven.apache.org)
>  
>  

Re: CFV: New Jigsaw Committer: Harold Seigel (Karen Kinnear)

[Mike Duigou]

Vote: YES

On 2015-09-11 12:43, jigsaw-dev-requ...@openjdk.java.net wrote:

From: Karen Kinnear 
To: jigsaw-dev 
Subject: CFV: New Jigsaw Committer: Harold Seigel
Message-ID: <7f587027-2bdb-4c37-9fd7-01aebfb17...@oracle.com>
Content-Type: text/plain;   charset=us-ascii


I hereby nominate Harold Seigel to Jigsaw Committer.

Harold is a member of the hotspot runtime team and a Reviewer on the
jdk9 project.
Harold has been contributing to Project Jigsaw in the hotspot runtime 
for over a
year, including support for the JVM_* interfaces for modules, boot 
class loader

support for jigsaw and handling jvm bootstrapping issues relative to
jigsaw that are
currently prototyped in the jigsaw/jake forest.

Votes are due by: September 25, 2105 8:00 PST. Only current Jigsaw
Committers [1] are eligible to vote on this nomination. Votes must be
cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [2]

thanks,
Karen
[1] http://openjdk.java.net/census
[2] http://openjdk.java.net/projects/#committer-vote

Harold's changesets for jigsaw/jake: ...

Re: CFV: New jigsaw Committer: Jean-Francois Denise (Alan Bateman)

[Mike Duigou]

Vote: YES

On 2015-09-14 01:22, jigsaw-dev-requ...@openjdk.java.net wrote:


Date: Sun, 13 Sep 2015 15:33:48 +0100
From: Alan Bateman 
To: jigsaw-dev 
Subject: CFV: New jigsaw Committer: Jean-Francois Denise
Message-ID: <55f5894c.4090...@oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed


I hereby nominate Jean-Francois Denise to jigsaw Committer.

Jean-Francois is a jdk9 Committer and has been contributing to the
ongoing development of the jimage container format. He has also been
focused recently on the link phase and jlink tool cited in JEP 261 [0].
He has more than 40 change-sets/contributions in the jigsaw/jake 
forest.


Votes are due by September 26, 2015 8:00 PDT.

Only current jigsaw Committers [1] are eligible to vote on this
nomination. Votes must be cast in the open by replying to this mailing 
list.


For Lazy Consensus voting instructions, see [2].

-Alan.

[0] http://openjdk.java.net/jeps/261
[1] http://openjdk.java.net/census
[2] http://openjdk.java.net/projects/#committer-vote

Re: javac not enforcing module boundaries?

[Alan Bateman]

On 14/09/2015 09:22, Peter Levart wrote:

:

Gives the following runtime error:

Exception in thread "main" java.lang.IllegalAccessError: class 
pkgA.TestA (in module: modA) cannot access class pkgC.TypeC (in 
module: modC), modA cannot read modC

at pkgA.TestA.main(modA@/TestA.java:8)


Which is expected. What I didn't expect is that javac did not figure 
this out correctly. Am I missing something and not using javac in the 
right way?


The API exported by modB has a method that returns an instance of 
pkgC.TypeC so I would have expected modB to be a good citizen and 
"requires public modC". Similarly, with the API exported by modC where 
is returns an instance of pkgD.TypeD, I would have expected modC to 
"requires public modD". I will guess that you've set it up this way to 
probe more into implied readability.


The javac command looks right, I see that it also doesn't fail when the 
modules are compiled separately (D, C, B, A).


-Alan.