RE: Feature complete?

I have come to a similar concern about command line options. First, it won't be acceptable for customers to change their scripts that say 'java myjavacommand'. The best that I have come up with so far is to hide JDK9 command line options in _JAVA_OPTIONS (it's likely that things will still need

RE: Unnamed module and duplicate package

We allowed classes in the classpath that were provided by the JDK to go silently unchallenged. I think making this an error will be a big problem. -Original Message- From: Paul Benedict [mailto:pbened...@apache.org] Sent: Thursday, March 10, 2016 4:25 PM To: Alex Buckley Cc:

RE: Unnamed module and duplicate package

-JDK8 and/or I know they won’t be re-released for a couple of years.       From: Paul Benedict [mailto:pbened...@apache.org] Sent: Thursday, March 10, 2016 11:43 PM To: Stephen Felts Cc: Alex Buckley; ML OpenJDK Jigsaw Developers Subject: Re: Unnamed module and duplicate package   On Thu, Mar 10

RE: Unnamed module and duplicate package

Benedict [mailto:pbened...@apache.org] Sent: Thursday, March 10, 2016 10:16 PM To: Stephen Felts Cc: Alex Buckley; ML OpenJDK Jigsaw Developers Subject: Re: Unnamed module and duplicate package   Stephen, regarding your first paragraph, I would like some more detail. Are you running your application

RE: argsfile problem

For you gradle experts, the syntax below is obviously wrong. options.compilerArgs << '@/argsfile' Maybe we can get the gradle folks to recognize @filename and expand it into their argsfile? -Original Message- From: Stephen Felts Sent: Tuesday, March 29, 2016 12:33 PM To: jigs

RE: running Groovy on JDK9

You should start with Gradle 2.10. It has most of the fixes needed to run with JDK9. I found that it was easiest to run with an argument file (though originally I had it all on the command line). It's needed for both gradle and the daemon. export GRADLE_OPTS="@${argsfile} -Xmx2048m

RE: running Groovy on JDK9

ursion). -Original Message- From: Stephen Felts Sent: Sunday, April 10, 2016 3:50 PM To: Jochen Theodorou; jigsaw-dev@openjdk.java.net Subject: RE: running Groovy on JDK9 You should start with Gradle 2.10. It has most of the fixes needed to run with JDK9. I found that it was easiest

RE: Need help testing the EA builds

This will be a significant problem for a lot of people with respect to tools not working. Gradle junit - basic problem fixed in upcoming release Jython Ant - certain cases with classloader JDT - doesn't work at all Asm - never tracked down issue Jmockit Simplestub Of course, these are problems

RE: Need help testing the EA builds

the junit problem). -Original Message- From: Alan Bateman Sent: Wednesday, March 02, 2016 11:13 AM To: Stephen Felts; jigsaw-dev Subject: Re: Need help testing the EA builds On 02/03/2016 15:26, Stephen Felts wrote: > This will be a significant problem for a lot of people with resp

Ant break

I'm seeing a problem using ant that I suspect is related to the classloading. I think it came in build 107 or 108. The following Is failing with /mydir/build.xml:27: taskdef class "ignore"/> cannot be found using the classloader

RE: modulepath and classpath mixture

Having spent 3 years using OSGI, fragment bundles were a great feature that we used to overcome this type of problem and others. I like the idea but I don't think it will be popular in Jigsaw (and OSGI is a four-letter word). -Original Message- From: Ali Ebrahimi

RE: Mutable modules

I was on a project using OSGi where some of the applications relied on removing and replacing modules. Generally they replaced applications modules at the top with no dependencies into the module. For example, in one application that dealt with RFID, it was common for new RFID clients to be

RE: JMH and JDK9

There was a bug that was just fixed yesterday such that the Java EE classes were not hidden. It should have been fixed in the last nightly 114 build. As long as the necessary Java EE API classes are on the classpath, no command line options are needed. If you have the Java EE JTA API jar in

RE: JDK9 Modules

Well you need the leading underscore.   From: Malachi de Ælfweald [mailto:malac...@gmail.com] Sent: Tuesday, July 05, 2016 4:36 PM To: Stephen Felts Cc: Remi Forax; jigsaw-dev@openjdk.java.net Subject: Re: JDK9 Modules   adding that (without the leading underscore) I still get

RE: JDK9 Modules

That option is overkill.  It includes all modules.  Instead of using ALL-SYSTEM, add just the modules that you need comma separated or java.se.ee.     From: Malachi de Ælfweald [mailto:malac...@gmail.com] Sent: Tuesday, July 05, 2016 5:00 PM To: Stephen Felts Cc: Remi Forax; jigsaw-dev

RE: JDK9 Modules

exports where you need to start at jdk.launcher.addexports.0 and monotonically increase with no gaps, and maintain that over time with packages added/deleted).   From: Malachi de Ælfweald [mailto:malac...@gmail.com] Sent: Tuesday, July 05, 2016 5:24 PM To: Stephen Felts Cc: Remi Forax; jigsaw-dev

RE: JDK9 Modules

Add -Djdk.launcher.addexports.0=java.base/sun.nio.ch=ALL-UNNAMED to _JAVA_OPTIONS. Also, kill the daemon before running. -Original Message- From: Malachi de Ælfweald [mailto:malac...@gmail.com] Sent: Tuesday, July 05, 2016 4:50 PM To: Alan Bateman Cc: jigsaw-dev@openjdk.java.net

RE: JDK9 Modules

I sometimes find tracking down JDK9 related fixes difficult. Obviously some are easy like PermSize on the command line. Anything that depends on rt.jar or finding tools.jar is broken. Some tools validate the jdk directory by looking for rt.jar. Some like jython use it to resolve class names.

JDK9 encapsulation problem

We have an application that is running into a problem with a utility program.  Below is a standalone reproducer.   The program does not import the SPI package sun.nio.ch - it isn't aware of it, and SocketChannel.isConnected() is a public method of a public type. In short, it does not break

JDK 9 configuration options

It’s common in enterprise applications to have multiple frameworks running in the same JVM.  For example, and application server might have Spring or Birt used in the application.  There are even cases where part of one application server might be used as a library running in the same JVM as

RE: JDK9 encapsulation problem

have code that works in JDK 9 and is broken when someone decides to re-implement something directly using an internal package in JDK 10.         -Original Message- From: Peter Levart [mailto:peter.lev...@gmail.com] Sent: Friday, September 09, 2016 11:54 AM To: Stephen Felts; jigsaw-de

RE: Corba and Transaction module problems with JDK9-ea+138

I have the following: Module path: javax.enterprise.cdi.api.jar javax.interceptor.javax.interceptor.api.jar Upgrade module path: java.transaction.jar javax.annotation-api-1.2.jar I'm not sure how much of that you will need. -Original Message- From: Alan Bateman Sent: Wednesday,

RE: Maven annotation processing fails with JDK9-ea+138

In JDK9, the java.xml.bind module is hidden by default. You can normally turn it on by specifying --add-modules=java.xml.bind -Original Message- From: Christian Beikov [mailto:christian.bei...@gmail.com] Sent: Tuesday, October 04, 2016 2:22 PM To: jigsaw-dev@openjdk.java.net Subject:

RE: NoClassDefFoundError: Could not initialize, class com.google.inject.internal.cglib.core.$ReflectUtils

I have raised the issue of command line options several times.  I think the summary is the following. 1. I don't always have control of the command line. 2. I don't always own the main. 3. When multiple projects are merged into the same JVM, there is not a good way to merge command line

Javassist 3.21

I picked up javassist 3.21 to work around Jigsaw problems on JDK 9. It works great. The only problem is that it no longer works on JDK 8. Has anyone seen this problem? Don't you hate it when you can't find java.lang.String? :) java.lang.RuntimeException: javassist.NotFoundException:

Gradle not working on Jigsaw

I have the line def branch = file('..').name in build.gradle. Running 'gradle' on build 140 Jdk-9 - runs fine JDK-9 Jigsaw gets * What went wrong: A problem occurred evaluating root project 'dir'. > No such property: name for class: java.io.File To run on Jigsaw, I also need to set

RE: Gradle not working on Jigsaw

age- From: Stephen Felts Sent: Wednesday, October 19, 2016 10:43 PM To: jigsaw-dev@openjdk.java.net Subject: Gradle not working on Jigsaw I have the line def branch = file('..').name in build.gradle. Running 'gradle' on build 140 Jdk-9 - runs fine JDK-9 Jigsaw gets * What went wrong: A prob

RE: Gradle not working on Jigsaw

what I need. I'm also running with the daemon so it seems to need java.base/sun.net.www java.base/sun.net.www.protocol.file java.base/java.lang.invoke. -Original Message- From: Stephen Felts Sent: Wednesday, October 19, 2016 10:43 PM To: jigsaw-dev@openjdk.java.net Subject: Gradle

Problem reading resources on Jigsaw in unnamed modules

It's happening on multiple resources in our build. Below is the best stack trace. Note that the only difference between JDK9 (where it works) and Jigsaw (where it fails) on build 140 in java/util/ResourceBundle.java is 3170c3168 < URL url =

RE: javassist broken on Jake

It turns out that the trick of using 3.21 doesn't work for Jake any more. So I guess there is no work-around for me on that platform and I won't be working on it. -Original Message- From: Alan Bateman Sent: Saturday, November 12, 2016 9:17 AM To: Stephen Felts; jigsaw-dev

javassist broken on Jake

I've been trying to get a javassist that works in all environments. For a while, I created a multi release jar file that used Javassist 3.20 for pre-jdk9 and Javassist 3.21 for JDK9/Jake. The JDK team wasn't happy about this use of multi release jar files but it worked great. Then 3.22.0-CR1

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Gradle/groovy are known to have problems with the restricted module access of b148.   You can get around this specific problem by using the environment variable _JAVA_OPTIONS=--add-opens=java.base/java.lang=ALL-UNNAMED   The packages that you need to open depend on what Java methods your

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Message- From: Kevin Rushforth Sent: Friday, December 09, 2016 6:33 PM To: Stephen Felts Cc: Uwe Schindler; jigsaw-dev@openjdk.java.net; Core-Libs-Dev Subject: Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch I second the recommendation of using

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

I would highly recommend running with _JAVA_OPTIONS=-Dsun.reflect.debugModuleAccessChecks=true It will tell you what add-options are required. One minor downside is that it will produce the warning in cases where the software is already correctly handling the exception from setAccessible, so

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

use cases and estimates of developer and end-user impact, are welcome". So you should make clear exactly API's that you want exposed. -Original Message- From: Uwe Schindler [mailto:uschind...@apache.org] Sent: Friday, December 09, 2016 6:22 PM To: Stephen Felts; jigsaw-dev@openjd

Using Eclipse batch compiler

Can someone tell me how to use the Eclipse batch compiler with JDK9? I've tried java --add-modules=java.se.ee -jar ecj-4.6.2.jar HelloWorld.java java --add-modules=java.se.ee -jar ecj-4.7M4.jar Helloworld.java 1. ERROR in HelloWorld.java (at line 1) class HelloWorld { ^ The type

RE: JDK9 approach to limiting package to one module

-Original Message- From: Alan Bateman Sent: Thursday, March 30, 2017 3:36 AM To: Stephen Felts; jigsaw-dev@openjdk.java.net Subject: Re: JDK9 approach to limiting package to one module On 30/03/2017 03:41, Stephen Felts wrote: > We ran into a problem today caused by the JDK 9 single-mod

JDK9 approach to limiting package to one module

We ran into a problem today caused by the JDK 9 single-module package limitation. We have an Apache jar file that references org.w3c.dom.ls.DocumentLS that is in another jar on the classpath. However, the incomplete org.w3c.dom.ls package is also in the JDK so the JDK wins and we get a class

RE: jake -> jdk9/dev

The jlr.Module -> jl.Module can cause some other problems.   It breaks source code compatibility that is totally unrelated to JDK9 (code that has been compiling for 20 years).  Unfortunately, the name Module is pretty popular – I saw 7 occurrences of the following.   $ cat Test.java import

RE: Disallowing the dynamic loading of agents by default

One of the key problems with the current proposal is the required use of the command line to enabled this feature. Alternative proposals (besides suggesting moving this to JDK10, which I agree with) have suggested other ways to configure the option. Since JDK9 has set the precedent of

RE: Disallowing the dynamic loading of agents by default

I agree with Andrew's position that if the argument is added in JDK9, it should default to allow dynamic loading of agents. Arguing from the position "Isn't it already the case, however, that migrating existing applications to JDK 9 is often going to require the use of a few new options

RE: Disallowing the dynamic loading of agents by default (revised)

I have a problem with the second point. Oracle's application server has "FAST SWAP" functionality similar to JRebel built-in so that a developer can speed up the "edit -> build -> deploy -> test" cycle. It uses an internal agent that attaches to the server so customers don't need to see it,

RE: Disallowing the dynamic loading of agents by default (revised)

The description below leaves out the " ancestor of the current process". Which way is it - do we need to start two processes or one to work around this? -Original Message- From: Alan Bateman Sent: Monday, April 10, 2017 2:39 PM To: jigsaw-dev@openjdk.java.net Subject: Re: Disallowing

RE: How to actually ship JSR-250?

- From: David M. Lloyd [mailto:david.ll...@redhat.com] Sent: Thursday, April 20, 2017 6:49 PM To: Stephen Felts; Alan Bateman; jigsaw-dev Subject: Re: How to actually ship JSR-250? To address the first point only... I think if Java EE 8 required Java SE 9, that would be surprising news for all

RE: How to actually ship JSR-250?

First, I'm not sure that Java EE 8 (corresponding to Java SE 9) will define modules. It seems that the RI will tolerate JDK9 (remove internal JDK API calls) as opposed to adopting the new module system. Since javax.annotation.* classes are now hidden in JDK 9, every project that uses these

RE: feedback on --permit-illegal-access

I have been using _JAVA_OPTIONS to get gradle working for over a year. I recently ran a build with --permit-illegal-access turned on (and --add-options taken out) and filed/updated bugs for several third-party jar files. There are problems with ant, xstream, simplestub, javassist, jmockit, jboss

RE: Disallowing the dynamic loading of agents by default (revised)

Bateman Sent: Tuesday, April 11, 2017 3:01 AM To: Stephen Felts; jigsaw-dev@openjdk.java.net Subject: Re: Disallowing the dynamic loading of agents by default (revised) On 11/04/2017 05:31, Stephen Felts wrote: > The description below leaves out the " ancestor of the current

RE: trySetAccessible​

I have asked for a mechanism to avoid the warnings multiple times and there is no way to do it. That's unfortunate because there are multiple projects that have been modified to work with JDK9 and they still produce a warning. I have resorted to keeping a list of known warnings that are OK

RE: trySetAccessible​

Right. We need an API that returns false with no warning. -Original Message- From: Alan Bateman Sent: Monday, July 10, 2017 5:56 AM To: Cédric Champeau Cc: jigsaw-dev Subject: Re: trySetAccessible​ On 10/07/2017 09:49, Cédric Champeau wrote: > I second Uwe's comment here: I was

RE: Cleanly starting apps on Java 9 and earlier

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

RE: jake -> jdk9/dev

I think that there is one large item in that change that should not be included. The requirement for using -Djdk.attach.allowAttachSelf=true is in Jake but not jdk9/dev. I think that the Java community made it clear that this feature should not be included in JDK9, including going to the effort

RE: jake -> jdk9/dev

The default is currently false in Jake (at least it's failing for me). Is this going to be reversed in Jake so that Jake and JDK9 match behavior? -Original Message- From: Alan Bateman Sent: Saturday, April 29, 2017 7:46 AM To: Stephen Felts; jigsaw-dev Subject: Re: jake -> jdk9/

RE: Proposal: Allow illegal reflective access by default in JDK 9

Right. I'm asking for a new API so code can be written to avoid the warning. -Original Message- From: Alan Bateman Sent: Friday, May 19, 2017 10:11 AM To: Stephen Felts; jigsaw-dev@openjdk.java.net Subject: Re: Proposal: Allow illegal reflective access by default in JDK 9 On 19/05/2017

RE: Proposal: Allow illegal reflective access by default in JDK 9

By the way, there is no available API so that one can write   If an object is not accessible and setAccessible on the object will succeed   call setAccessible   That means that the code needs to call setAccessible and handle the exception, which triggers a warning.      

RE: Will split-packages ever be supported?

Wouldn't it be possible to add an enhancement to allow for a module to add a package to an existing module? Sort of like OSGI fragment bundles, which are very popular. I don't understand what is so fundamental about this. -Original Message- From: Alan Bateman Sent: Tuesday, May 30,

RE: Will split-packages ever be supported?

To: jigsaw-dev@openjdk.java.net; Stephen Felts; Alan Bateman; wzberger Subject: RE: Will split-packages ever be supported? On May 30, 2017 4:28:00 PM GMT+02:00, Stephen Felts <stephen.fe...@oracle.com> wrote: Hi Stephen, >Wouldn't it be possible to add an enhancement to allow for a module

RE: jigsaw/jake/jdk: Allow illegal access by default

The latest version of Jigsaw available from http://jdk.java.net/jigsaw/ (jdk-9+172 on 06-02-2017 (#6472)) has --illegal-access= permit or deny access to members of types in named modules by code in unnamed modules. is

RE: --illegal-access to allow illegal access by default

To: Stephen Felts; jigsaw-dev@openjdk.java.net Subject: Re: --illegal-access to allow illegal access by default > This is what the output looks like. Ironically, this code in the standalone > bind implementation jar has fall-back code for running correctly on JDK9. I think the iss

RE: jake -> jdk9/dev

e included in JDK9. -Original Message- From: Alan Bateman Sent: Saturday, April 29, 2017 7:46 AM To: Stephen Felts; jigsaw-dev Subject: Re: jake -> jdk9/dev On 29/04/2017 11:04, Stephen Felts wrote: > I think that the Java community made it clear that this feature should > not

RE: Proposal: Allow illegal reflective access by default in JDK 9

Here's something to think about with respect to noise by whatever choice is made for the default for --illegal-access.   I've run a lot of code using the current --permit-illegal-access.   One of the problems with this option is that there can be errors detected for code that is working

RE: Proposal (revised): Allow illegal access to internal APIs by default in JDK 9

The new format is missing information that was useful in the earlier -Dsun.reflect.debugModuleAccessChecks=true. It printed something like 'java.base does not "opens java.text" to unnamed module ...' so it was really obvious what option was needed. -Original Message- From: jigsaw-dev

RE: "exports" directive does not open module's resources for dependent modules

"opens" is a superset of "exports". -Original Message- From: Alexander Udalov [mailto:alexander.uda...@jetbrains.com] Sent: Friday, September 15, 2017 8:14 AM To: jigsaw-dev Subject: "exports" directive does not open module's resources for dependent

RE: Scanning multi version jars?

.        From: Greg Wilkins [mailto:gr...@webtide.com] Sent: Monday, September 18, 2017 9:33 PM To: Stephen Felts <stephen.fe...@oracle.com> Cc: Paul Sandoz <paul.san...@oracle.com>; jigsaw-dev

RE: Scanning multi version jars?

We ran into this problem, where we have a closed-set class checker and it has a problem processing MR jar files. I recommend replacing all inner classes if the ordinary class is versioned. If the inner class goes away, you would need to stub it so a versioned copy exists. That is the

RE: Scanning multi version jars?

A versioned file name, JarEntry.getName(), starts with "META-INF/versions/". The version is the following string up to the next "/". The version can be parsed with Runtime.Version.parse(). If not a versioned class file name, then use Jarfile.baseVersion(). That should be sufficient to get the

RE: Scanning multi version jars?

FWIW I tracked down the MR jar file that I was having trouble with. It's the stand-alone JAXWS jar file com.sun.xml.ws.jaxws-rt.jar. Focusing on the problem class, the jar contains com/sun/xml/ws/util/xml/XmlCatalogUtil$1.class com/sun/xml/ws/util/xml/XmlCatalogUtil.class

RE: Adding module causes classloading issues

I'm trying to get javax.transaction-api-1.3-ea.jar published to Maven Central as soon as possible. In the meantime, you can make your own if you are blocked by starting with javax.transaction-api-1.2.jar, deleting the three classes in the javax.transaction.xa package, and updating