Re: Exporting a package with no Java sources

[Jonathan Gibbons]

Right now, javac only looks in one location (i.e. directory + its 
subdirectories) for the compiled classes for a module.


It is too late to change this for JDK 9, and even if we could, I think 
we are already pushing the limits of what can be specified on the 
command line to configure the different paths for all the modules 
involved in the compilation.


Converting the error to a warning (as was suggested in the original post 
in this thread) would not address the case where the Java source code 
needs to refer to types declared in class files generated from non-Java 
sources.


-- Jon


On 7/1/17 3:08 AM, Alan Bateman wrote:

On 01/07/2017 10:09, Peter Levart wrote:

Hi Alexander,

Have you tried to put a package-info.java into the exported package? It
might work.

I don't think so, but a dummy class/interface will do (it doesn't have 
to be public). There is a lengthy discussion on this topic in JIRA 
from 2016 that would be useful to link to (but I can't find it just 
now because JIRA is down for maintenance).


-Alan

Re: javap cannot read module-info.class

[Stephan Herrmann]

One working example certainly doesn't prove absence of a bug :)
But yes, I must have gotten my bash aliases wrong, the reported error
is only printed by the Java 8 version of javap, in 9 it works as expected.

One small bit remains:
If I let our compiler emit CONSTANT_Utf8_info for the module name
without a wrapper CONSTANT_Module_info javap does happily accept this.
"java --list-modules" rejects this, though.

other than that: sorry for the noise,
Stephan

On 01.07.2017 18:01, Remi Forax wrote:

Hi Stephan,
there is something wrong from your side, it works for me :)

/usr/jdk/jdk-9-b175/bin/javap --module-path target/main/exploded/ --module 
fr.umlv.asm.test module-info
Compiled from "module-info.java"
module fr.umlv.asm.test {
   requires java.base;
   requires org.objectweb.asm.all.debug;
   exports fr.umlv.asm.test;
}

/usr/jdk/jdk-9-b175/bin/javap -m java.base module-info
Compiled from "module-info.java"
module java.base@9 {
   exports sun.reflect.generics.reflectiveObjects to
 java.desktop;
   exports java.util;
   exports java.lang.ref;
   exports jdk.internal.misc to
 java.rmi,
 java.sql,
 jdk.jshell,
...

cheers,
Rémi

- Mail original -

De: "Stephan Herrmann" 
À: jigsaw-dev@openjdk.java.net
Envoyé: Samedi 1 Juillet 2017 17:08:20
Objet: javap cannot read module-info.class



compile an arbitrary module-info.java and then:

$ javap module-info.class
  Error: error while reading constant pool for /tmp/bin/module-info.class:
  unexpected tag at #5: 19

 From tweaking the Eclipse compiler it seems that javap is expecting a
CONSTANT_Utf8_info,
where according to JVMS 4.7.25 a CONSTANT_Module_info is required.

JVMS and javac agree, so javap is the odd man out.

Stephan

PS: build is 9+175

Re: Cleanly starting apps on Java 9 and earlier

[Alan Bateman]

On 01/07/2017 13:15, Enrico Olivelli wrote:

:

Alan,
Can you give some poonters to this page?
Thank you

There isn't a page to point at yet, mostly we are waiting for 
javaee.github.io to be updated to list stable Maven coordinates or 
download links for each of the standalone technologies.


-Alan.

Re: javap cannot read module-info.class

[Alan Bateman]

On 01/07/2017 16:08, Stephan Herrmann wrote:

compile an arbitrary module-info.java and then:

$ javap module-info.class
 Error: error while reading constant pool for 
/tmp/bin/module-info.class: unexpected tag at #5: 19


From tweaking the Eclipse compiler it seems that javap is expecting a 
CONSTANT_Utf8_info,

where according to JVMS 4.7.25 a CONSTANT_Module_info is required.
It would be interesting to see if the runtime can read this, does "java 
-p /tmp/bin --list-modules" list the module?


-Alan

Re: javap cannot read module-info.class

[Remi Forax]

Hi Stephan,
there is something wrong from your side, it works for me :)

/usr/jdk/jdk-9-b175/bin/javap --module-path target/main/exploded/ --module 
fr.umlv.asm.test module-info
Compiled from "module-info.java"
module fr.umlv.asm.test {
  requires java.base;
  requires org.objectweb.asm.all.debug;
  exports fr.umlv.asm.test;
}

/usr/jdk/jdk-9-b175/bin/javap -m java.base module-info
Compiled from "module-info.java"
module java.base@9 {
  exports sun.reflect.generics.reflectiveObjects to
java.desktop;
  exports java.util;
  exports java.lang.ref;
  exports jdk.internal.misc to
java.rmi,
java.sql,
jdk.jshell,
...

cheers,
Rémi

- Mail original -
> De: "Stephan Herrmann" 
> À: jigsaw-dev@openjdk.java.net
> Envoyé: Samedi 1 Juillet 2017 17:08:20
> Objet: javap cannot read module-info.class

> compile an arbitrary module-info.java and then:
> 
> $ javap module-info.class
>  Error: error while reading constant pool for /tmp/bin/module-info.class:
>  unexpected tag at #5: 19
> 
> From tweaking the Eclipse compiler it seems that javap is expecting a
> CONSTANT_Utf8_info,
> where according to JVMS 4.7.25 a CONSTANT_Module_info is required.
> 
> JVMS and javac agree, so javap is the odd man out.
> 
> Stephan
> 
> PS: build is 9+175

javap cannot read module-info.class

[Stephan Herrmann]

compile an arbitrary module-info.java and then:

$ javap module-info.class
 Error: error while reading constant pool for /tmp/bin/module-info.class: 
unexpected tag at #5: 19

From tweaking the Eclipse compiler it seems that javap is expecting a 
CONSTANT_Utf8_info,
where according to JVMS 4.7.25 a CONSTANT_Module_info is required.

JVMS and javac agree, so javap is the odd man out.

Stephan

PS: build is 9+175

RE: Cleanly starting apps on Java 9 and earlier

[Stephen Felts]

IMO:

1. You should avoid `--add-modules java.se.ee' unless you need all of those 
modules.  You should bring in only those modules that you need.  The choices 
are java.activation, java.corba, java.transaction, java.xml.bind, java.xml.ws, 
java.xml.ws.annotation.  So use --add-modules java.xml.ws.

2. You can't use -XX:+IgnoreUnrecognizedVMOptions as a general solution because 
that isn't available in JDK6 JRockit for example.

3. Setting JDK_JAVA_OPTIONS is good because only JDK9 recognizes it and it is 
inherited by all nested invocations (unless there is an exec that excludes the 
environment).  You might want to use
export JDK_JAVA_OPTIONS="-XX:+IgnoreUnrecognizedVMOptions --add-modules 
java.xml.ws"

4. --add-opens is not needed starting in b175 so require that as a base.  It 
will still be noisy (a 3-line WARNING will be printed to the standard error).


-Original Message-
From: Alan Bateman 
Sent: Saturday, July 1, 2017 5:53 AM
To: Mark Thomas; jigsaw-dev@openjdk.java.net
Subject: Re: Cleanly starting apps on Java 9 and earlier

On 01/07/2017 10:18, Mark Thomas wrote:
> Hi,
>
> Apache Tomcat needs to add the following options when running on Java 9:
>
> --add-modules=java.se.ee
> --add-opens=java.base/java.lang=ALL-UNNAMED
> --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
>
> The first is because it depends on javax.xml.ws.WebServiceRef and 
> javax.xml.ws.WebServiceRefs.
> We could work around this by shipping our own implementations but that 
> sort of duplication should not be necessary.
The java.xml.ws module is deprecated for removal (along with the other modules 
shared with Java EE) so expect these modules to not be included in the JDK some 
day (exactly when is TBD as it depends on when Java SE drops them).

In the short term then `--add-modules java.se.ee` will resolve the EE modules 
included in the JDK but it may bring complications, it all depends on whether 
you have the EE java.transaction module or JAR files with annotations in the 
javax.annotation package in your environment. An important page for the JDK 9 
docs is a page with instructions and deployments options for those using these 
APIs.


>
> The second and third are required by Tomcat's memory leak detection 
> and prevention code. In an ideal world, web applications wouldn't have 
> memory leaks. Unfortunately, the world isn't ideal and the memory leak 
> detection and prevention code has proven immensely valuable over the years.
Both of these packages are open since jdk-9+175 so the hacks to null fields 
will continue to work.

That said, I thought the issue with TCCL in sun.rmi.transport.GC was fixed via 
JDK-8157570. Have you tested that?


> The problem we have is that Tomcat needs to run on Java 9 though 6. If
> the above options aren't provided, Java 6 through 8 are fine but on Java
> 9 at best the users see a bunch of errors and at worst Tomcat won't
> start. If the above options are included, Java 9 is fine but then Tomcat
> fails to start on Java 6 though 8.
>
The launch script could examine the JAVA_VERSION property in the 
`release` file. Another approach is to set the JDK_JAVA_OPTIONS 
environment variable as that is new 9 and so will be ignored by older 
releases. There is also -XX:+IgnoreUnrecognizedVMOptions to ignore 
unrecognized options.

-Alan

gradle 3.x runs without setting _JAVA_OPTIONS on jdk-9+175 (and later)

[Kevin Rushforth]

Now that '--illegal-access=permit' is the default for JDK 9 (as of build 
175) I can confirm that gradle 3.x works without needing to specify a 
bunch of '--add-opens' options. I was able to do an entire build / test 
of JavaFX without setting _JAVA_OPTIONS at all. I hope this will give 
the groovy and gradle teams the time they need to fix all remaining issues.


-- Kevin

Re: Cleanly starting apps on Java 9 and earlier

[Enrico Olivelli]

Il sab 1 lug 2017, 11:53 Alan Bateman  ha scritto:

> On 01/07/2017 10:18, Mark Thomas wrote:
> > Hi,
> >
> > Apache Tomcat needs to add the following options when running on Java 9:
> >
> > --add-modules=java.se.ee
> > --add-opens=java.base/java.lang=ALL-UNNAMED
> > --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
> >
> > The first is because it depends on javax.xml.ws.WebServiceRef and
> > javax.xml.ws.WebServiceRefs.
> > We could work around this by shipping our own implementations but that
> > sort of duplication should not be necessary.
> The java.xml.ws module is deprecated for removal (along with the other
> modules shared with Java EE) so expect these modules to not be included
> in the JDK some day (exactly when is TBD as it depends on when Java SE
> drops them).
>
> In the short term then `--add-modules java.se.ee` will resolve the EE
> modules included in the JDK but it may bring complications, it all
> depends on whether you have the EE java.transaction module or JAR files
> with annotations in the javax.annotation package in your environment. An
> important page for the JDK 9 docs is a page with instructions and
> deployments options for those using these APIs.
>

Alan,
Can you give some poonters to this page?
Thank you

Enrico Olivelli

>
>
> >
> > The second and third are required by Tomcat's memory leak detection and
> > prevention code. In an ideal world, web applications wouldn't have
> > memory leaks. Unfortunately, the world isn't ideal and the memory leak
> > detection and prevention code has proven immensely valuable over the
> years.
> Both of these packages are open since jdk-9+175 so the hacks to null
> fields will continue to work.
>
> That said, I thought the issue with TCCL in sun.rmi.transport.GC was
> fixed via JDK-8157570. Have you tested that?
>
>
> > The problem we have is that Tomcat needs to run on Java 9 though 6. If
> > the above options aren't provided, Java 6 through 8 are fine but on Java
> > 9 at best the users see a bunch of errors and at worst Tomcat won't
> > start. If the above options are included, Java 9 is fine but then Tomcat
> > fails to start on Java 6 though 8.
> >
> The launch script could examine the JAVA_VERSION property in the
> `release` file. Another approach is to set the JDK_JAVA_OPTIONS
> environment variable as that is new 9 and so will be ignored by older
> releases. There is also -XX:+IgnoreUnrecognizedVMOptions to ignore
> unrecognized options.
>
> -Alan
>
-- 


-- Enrico Olivelli

Re: Exporting a package with no Java sources

[Alan Bateman]

On 01/07/2017 10:09, Peter Levart wrote:

Hi Alexander,

Have you tried to put a package-info.java into the exported package? It
might work.

I don't think so, but a dummy class/interface will do (it doesn't have 
to be public). There is a lengthy discussion on this topic in JIRA from 
2016 that would be useful to link to (but I can't find it just now 
because JIRA is down for maintenance).


-Alan

Re: Cleanly starting apps on Java 9 and earlier

[Alan Bateman]

On 01/07/2017 10:18, Mark Thomas wrote:

Hi,

Apache Tomcat needs to add the following options when running on Java 9:

--add-modules=java.se.ee
--add-opens=java.base/java.lang=ALL-UNNAMED
--add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED

The first is because it depends on javax.xml.ws.WebServiceRef and
javax.xml.ws.WebServiceRefs.
We could work around this by shipping our own implementations but that
sort of duplication should not be necessary.
The java.xml.ws module is deprecated for removal (along with the other 
modules shared with Java EE) so expect these modules to not be included 
in the JDK some day (exactly when is TBD as it depends on when Java SE 
drops them).


In the short term then `--add-modules java.se.ee` will resolve the EE 
modules included in the JDK but it may bring complications, it all 
depends on whether you have the EE java.transaction module or JAR files 
with annotations in the javax.annotation package in your environment. An 
important page for the JDK 9 docs is a page with instructions and 
deployments options for those using these APIs.





The second and third are required by Tomcat's memory leak detection and
prevention code. In an ideal world, web applications wouldn't have
memory leaks. Unfortunately, the world isn't ideal and the memory leak
detection and prevention code has proven immensely valuable over the years.
Both of these packages are open since jdk-9+175 so the hacks to null 
fields will continue to work.


That said, I thought the issue with TCCL in sun.rmi.transport.GC was 
fixed via JDK-8157570. Have you tested that?




The problem we have is that Tomcat needs to run on Java 9 though 6. If
the above options aren't provided, Java 6 through 8 are fine but on Java
9 at best the users see a bunch of errors and at worst Tomcat won't
start. If the above options are included, Java 9 is fine but then Tomcat
fails to start on Java 6 though 8.

The launch script could examine the JAVA_VERSION property in the 
`release` file. Another approach is to set the JDK_JAVA_OPTIONS 
environment variable as that is new 9 and so will be ignored by older 
releases. There is also -XX:+IgnoreUnrecognizedVMOptions to ignore 
unrecognized options.


-Alan

Cleanly starting apps on Java 9 and earlier

[Mark Thomas]

Hi,

Apache Tomcat needs to add the following options when running on Java 9:

--add-modules=java.se.ee
--add-opens=java.base/java.lang=ALL-UNNAMED
--add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED

The first is because it depends on javax.xml.ws.WebServiceRef and
javax.xml.ws.WebServiceRefs.
We could work around this by shipping our own implementations but that
sort of duplication should not be necessary.

The second and third are required by Tomcat's memory leak detection and
prevention code. In an ideal world, web applications wouldn't have
memory leaks. Unfortunately, the world isn't ideal and the memory leak
detection and prevention code has proven immensely valuable over the years.

The problem we have is that Tomcat needs to run on Java 9 though 6. If
the above options aren't provided, Java 6 through 8 are fine but on Java
9 at best the users see a bunch of errors and at worst Tomcat won't
start. If the above options are included, Java 9 is fine but then Tomcat
fails to start on Java 6 though 8.

What is the recommended approach for applications that need to use one
or more of the options above and need to start cleanly on multiple Java
versions including 9 and earlier using a single, common start-up script?

To date, Tomcat has always been Java version agnostic as long as at
least the minimum Java version as specified by the Java EE spec has been
used. We really don't want to have to change that.

Suggestions welcome.

Mark

Re: Exporting a package with no Java sources

[Peter Levart]

Hi Alexander,

Have you tried to put a package-info.java into the exported package? It
might work.

Regards, Peter

On Jun 30, 2017 6:42 PM, "Alexander Udalov" 
wrote:

> I'm trying to figure out how to compile a mixed-language (in this
> case, Java + Kotlin) JVM module and having a problem in case the
> module tries to export a package without any .java sources in it. The
> javac error I get is:
>
> src/module-info.java:2: error: package is empty or does not exist: foo
> exports foo;
> ^
>
> Now, through experiments, I found out that it's actually possible to
> workaround this error by
> 1) always compiling non-.java sources first, and
> 2) compiling .java sources to the same directory where non-.java
> sources are compiled to on step 1.
>
> However, with Gradle deprecating single-output directory builds for
> projects using multiple JVM languages [1], this workaround is not
> always going to be possible.
> Is there some other way to suggest to javac that .class files in a
> particular location on the disk are a part of the same module, so that
> it would be possible to export the package?
> If there isn't, would it make sense to relax the severity of this
> compiler message to a warning?
>
> Thank you in advance!
>
> Alexander
>
> [1] https://docs.gradle.org/4.0/release-notes.html#multiple-
> class-directories-for-a-single-source-set
>

hg: jigsaw/jake/nashorn: 2 new changesets

[alan . bateman]

Changeset: b25986e36b28
Author:lana
Date:  2017-06-29 17:26 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/b25986e36b28

Added tag jdk-9+176 for changeset 3c6fbdf6e785

! .hgtags

Changeset: e93bc38cf3f3
Author:alanb
Date:  2017-07-01 07:58 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/e93bc38cf3f3

Merge

! .hgtags

hg: jigsaw/jake/corba: 2 new changesets

[alan . bateman]

Changeset: 76cebcdca958
Author:lana
Date:  2017-06-29 17:26 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/76cebcdca958

Added tag jdk-9+176 for changeset 40fb9f229471

! .hgtags

Changeset: ace27af8942f
Author:alanb
Date:  2017-07-01 07:58 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/ace27af8942f

Merge

! .hgtags

hg: jigsaw/jake/jaxp: 2 new changesets

[alan . bateman]

Changeset: 332ad9f92632
Author:lana
Date:  2017-06-29 17:26 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/332ad9f92632

Added tag jdk-9+176 for changeset 38cf34e23280

! .hgtags

Changeset: 712c8f06dd80
Author:alanb
Date:  2017-07-01 07:58 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/712c8f06dd80

Merge

! .hgtags

hg: jigsaw/jake/hotspot: 3 new changesets

[alan . bateman]

Changeset: 2ab74e5dbdc2
Author:roland
Date:  2017-06-23 09:33 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2ab74e5dbdc2

8181742: Load that bypasses arraycopy has wrong memory state
Summary: Set load memory edge to the memory state right before the arraycopy.
Reviewed-by: kvn, thartmann

! src/share/vm/opto/arraycopynode.cpp
! src/share/vm/opto/arraycopynode.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/memnode.hpp
+ test/compiler/arraycopy/TestLoadBypassACWithWrongMem.java

Changeset: 1ca8f038fceb
Author:lana
Date:  2017-06-29 17:26 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1ca8f038fceb

Added tag jdk-9+176 for changeset 2ab74e5dbdc2

! .hgtags

Changeset: 354453651ff7
Author:alanb
Date:  2017-07-01 07:57 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/354453651ff7

Merge

! .hgtags
! src/share/vm/opto/library_call.cpp

hg: jigsaw/jake/jdk: 4 new changesets

[alan . bateman]

Changeset: 2425838cfb5e
Author:mullan
Date:  2017-06-23 14:32 -0400
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2425838cfb5e

8182652: RuntimePermission("usePolicy") is not a Java SE permission
Reviewed-by: mchung

! src/java.base/share/classes/java/lang/RuntimePermission.java

Changeset: 9f27d513658d
Author:jjg
Date:  2017-06-26 18:48 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9f27d513658d

8182736: javadoc generates bad names and broken module graph links
Reviewed-by: jjg, bpatel, darcy, ksrini
Contributed-by: bhavesh.pa...@oracle.com, jonathan.gibb...@oracle.com

! make/src/classes/build/tools/taglet/ModuleGraph.java

Changeset: 473db5c4c2c9
Author:lana
Date:  2017-06-29 17:26 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/473db5c4c2c9

Added tag jdk-9+176 for changeset 9f27d513658d

! .hgtags

Changeset: f140e400a7f0
Author:alanb
Date:  2017-07-01 07:57 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f140e400a7f0

Merge

! .hgtags
! src/java.base/share/classes/java/lang/RuntimePermission.java

hg: jigsaw/jake/jaxws: 2 new changesets

[alan . bateman]

Changeset: 880541212285
Author:lana
Date:  2017-06-29 17:26 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/880541212285

Added tag jdk-9+176 for changeset ea819b6009d3

! .hgtags

Changeset: 7c7fed544711
Author:alanb
Date:  2017-07-01 07:58 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/7c7fed544711

Merge

! .hgtags

hg: jigsaw/jake/langtools: 3 new changesets

[alan . bateman]

Changeset: 0d0ac75b0f6c
Author:jjg
Date:  2017-06-26 18:48 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/0d0ac75b0f6c

8182736: javadoc generates bad names and broken module graph links
Reviewed-by: jjg, bpatel, darcy, ksrini
Contributed-by: bhavesh.pa...@oracle.com, jonathan.gibb...@oracle.com

! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ModuleSummaryBuilder.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/IndexBuilder.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java
! test/jdk/javadoc/doclet/testModules/TestModules.java
+ test/jdk/javadoc/doclet/testModules/test.moduleFullName/module-info.java
+ 
test/jdk/javadoc/doclet/testModules/test.moduleFullName/testpkgmdlfullname/TestClassInTestModuleFullName.java

Changeset: 552f8fdfba55
Author:lana
Date:  2017-06-29 17:26 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/552f8fdfba55

Added tag jdk-9+176 for changeset 0d0ac75b0f6c

! .hgtags

Changeset: 1dce953430d8
Author:alanb
Date:  2017-07-01 07:57 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/1dce953430d8

Merge

! .hgtags
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ModuleSummaryBuilder.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java
! test/jdk/javadoc/doclet/testModules/TestModules.java