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 META-INF/MAN
.
From: Greg Wilkins [mailto:gr...@webtide.com]
Sent: Monday, September 18, 2017 9:33 PM
To: Stephen Felts
Cc: Paul Sandoz ; jigsaw-dev
; core-libs-...@openjdk.java.net
Subject: Re: Scanning multi
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 versi
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
META-INF/versions/9/com/
"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
modules
It looks like exporting a p
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 conventi
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 surprise
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 (cur
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.
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
3, 2017 2:37 AM
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 th
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 o
: 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
wrote:
Hi Stephen,
>Wouldn't it be possible to add an enhancement to allow for a module to
>add a package to
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, 20
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
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.
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 corre
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
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
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 o
Original Message-
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 sur
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 clas
---Original Message-
From: Alan 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 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 the
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, con
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
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 t
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 configuring
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 anyway,
files
-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 singl
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 de
I've been doing some testing with this option for development and testing.
The original implementation with output from --add-opens broke our tests so
quieter is better.
This is really a useful feature. Ideally the goal would be to run with this
option in product build, unit test, and functiona
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 java.
ginal 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
world
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-
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
the
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
gra
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;
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 wa
That means in the next build as of tomorrow the class format is changed and
classes need to be re-generated?
-Original Message-
From: Alan Bateman
Sent: Monday, October 31, 2016 1:20 PM
To: Paul Bakker; jigsaw-dev@openjdk.java.net
Subject: Re: New proposal for #ReflectiveAccessToNonExpor
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 = loader.getResource
different from
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
I’m not sure that I understand. I did a jar xf on the class and ran jad on it.
Are you saying it’s somehow by-passing this class?
From: Cédric Champeau [mailto:cedric.champ...@gmail.com]
Sent: Thursday, October 20, 2016 1:33 PM
To: Stephen Felts
Cc: jigsaw-dev
Subject: Re: Gradle not
Message-
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
> A trySetAccessible is possible although a @CS variant of accessCheck (like in
> MH.Lookup) might be more general. I think we need to be cautious about adding
> APIs here and so would be interesting to get some performance data here (I >
> don't think I've seen the bulk setAccessible used very
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 _JAVA_OPTI
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, Octob
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: Mav
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: java.lang
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 option
in the JDK, then I might 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:
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 ano
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 any
In the next few weeks, the options will change to the new format and your build
will be broken.
From: Malachi de Ælfweald [mailto:malac...@gmail.com]
Sent: Wednesday, July 06, 2016 10:30 AM
To: Alan Bateman
Cc: Stephen Felts; jigsaw-dev@openjdk.java.net
Subject: Re: JDK9 Modules
I
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
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
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
Subject
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
Try running with
export _JAVA_OPTIONS=”-Djdk.launcher.addmods=ALL-SYSTEM”
From: Malachi de Ælfweald [mailto:malac...@gmail.com]
Sent: Tuesday, July 05, 2016 3:29 PM
To: Stephen Felts
Cc: Remi Forax; jigsaw-dev@openjdk.java.net
Subject: Re: JDK9 Modules
That's a very u
Remove -addmods java.annotation.common
Or change it to java.annotations.common
You should get use to using
jimage list --dir=. $JAVA_HOME/lib/modules > t
textedit t
From: Malachi de Ælfweald [mailto:malac...@gmail.com]
Sent: Tuesday, July 05, 2016 2:34 PM
To: Stephen Felts
Cc: R
e Ælfweald [mailto:malac...@gmail.com]
Sent: Tuesday, July 05, 2016 1:52 PM
To: Stephen Felts
Cc: Remi Forax; jigsaw-dev@openjdk.java.net
Subject: Re: JDK9 Modules
Adding the fork and forkOptions got me further on the Dagger test. I also
added -verbose.
I can see:
[loading /modules/java.annotati
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.
T
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 intr
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 the
properly handle
recursion).
-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
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 -Dorg.gradl
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 P
Here’s an interesting problem.
I have a lot of JDK9-specific command line options.
I decided to try to put them into an argsfile.
I then tried to use the @argsfile in a gradle script using something like
options.compilerArgs=’@/argsfile’
I was getting a ‘javac: invalid flag: @/argsfil
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 [mailto:ali.ebrahimi1.
-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
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
I'm aware of classes in our application server (not javax) that are unused when
running with our own JVM and used when running with another JVM.
In that case, the packages are duplicate of classes in the JDK. I would not
want that usage to generate a fatal error.
This is unrelated to endorsed ja
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: jigsaw-de
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 AntClassLoader[/mydir_build/ant-contrib-1.0b3.ja
e from 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 wi
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 th
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
I agree. I would much rather be able to see the information using unzip -p and
update it using a text editor or any tool that can write text.
-Original Message-
From: Paul Benedict [mailto:pbened...@apache.org]
Sent: Wednesday, December 02, 2015 9:53 AM
To: Remi Forax
Cc: jigsaw-dev@o
78 matches
Mail list logo
