Re: The javax.annotation.Generated and annotation processors

On Fri, Apr 22, 2016 at 8:47 PM, Alan Bateman wrote: > On 22/04/2016 19:55, Sanne Grinovero wrote: >> >> Hello all, >> >> related to https://bugs.openjdk.java.net/browse/JDK-8152842 >> >> I'm having to patch our annotation processors to avoid the @Generated >> annotation, as I can't use the propos

Re: The javax.annotation.Generated and annotation processors

On 22/04/2016 19:55, Sanne Grinovero wrote: Hello all, related to https://bugs.openjdk.java.net/browse/JDK-8152842 I'm having to patch our annotation processors to avoid the @Generated annotation, as I can't use the proposed workaround to use `-addmods java.annotations.common`: our build also r

Re: Root modules (was Re: JMH and JDK9)

On 22/04/2016 20:01, Sanne Grinovero wrote: : Thanks! Indeed, it's working great. [tested 9-ea+114-2016-04-19-162931.javare.4880.nc] Ironically this means we can make more progress testing using the Jigsaw EA builds, while I'm completely blocked on the "mainline". Thanks for confirming. W

Re: JMH and JDK9

On Wed, Apr 20, 2016 at 3:15 PM, Stephen Felts wrote: > 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 > li

Re: Root modules (was Re: JMH and JDK9)

On Wed, Apr 20, 2016 at 1:57 PM, Alan Bateman wrote: > > (dropping hotspot-dev and change the subject line as this discussion thread > has moved on) > > On 20/04/2016 13:28, Sanne Grinovero wrote: >> >> : >> Agreed: excellent idea! >> >> I'm eager to try it out so that we can resume testing of eve

The javax.annotation.Generated and annotation processors

Hello all, related to https://bugs.openjdk.java.net/browse/JDK-8152842 I'm having to patch our annotation processors to avoid the @Generated annotation, as I can't use the proposed workaround to use `-addmods java.annotations.common`: our build also requires `-target 1.7` and the two options are

Re: RFR: JDK-8069079 - jimage extract / list to organize classes by modules

Hi Jim, > On Apr 22, 2016, at 6:12 AM, Jim Laskey (Oracle) > wrote: > > Listing is by module, extract has been by module for some time. > > http://cr.openjdk.java.net/~jlaskey/8069079/webrev/index.html > JDK-8069079 was filed l

Re: Build craziness

I don't recognize this it looks to be the DTrace support. I also see it is jdk9/dev. You might be better bringing it to build-dev with more details on the tool chain used. -Alan On 22/04/2016 15:59, Jim Laskey (Oracle) wrote: make clean ; make images Building target 'images' in configurati

Build craziness

make clean ; make images Building target 'images' in configuration 'macosx-x86_64-normal-server-fastdebug' Building JVM variant 'server' with features 'all-gcs cds compiler1 compiler2 dtrace fprof jni-check jvmci jvmti management nmt services vm-structs' Compiling 8 files for BUILD_TOOLS_LANGTOO

Re: RFR: JDK-8154090 - Remove support for jimage recreate

Thank you. > On Apr 22, 2016, at 10:53 AM, Alan Bateman wrote: > > > > On 22/04/2016 14:12, Jim Laskey (Oracle) wrote: >> http://cr.openjdk.java.net/~jlaskey/8154090/webrev/index.html >> >> https://bugs.openjdk.java.net/browse/JD

Re: RFR: JDK-8069079 - jimage extract / list to organize classes by modules

Thank you, will wait. > On Apr 22, 2016, at 10:55 AM, Alan Bateman wrote: > > > > On 22/04/2016 14:12, Jim Laskey (Oracle) wrote: >> Listing is by module, extract has been by module for some time. >> >> http://cr.openjdk.java.net/~jlaskey/8069079/webrev/index.html >>

Re: RFR: JDK-8082537 - jimage should print usage when started with no args

Will change. Thank you. > On Apr 22, 2016, at 10:59 AM, Alan Bateman wrote: > > > > On 22/04/2016 14:54, Jim Laskey (Oracle) wrote: >> It can be outside, does the change add value? >> >> > I think so as it's always been odd that the jimage tool would exit without > printing anything when c

Re: RFR: JDK-8082537 - jimage should print usage when started with no args

On 22/04/2016 14:54, Jim Laskey (Oracle) wrote: It can be outside, does the change add value? I think so as it's always been odd that the jimage tool would exit without printing anything when calling without any arguments. My comment on the place of the check is that it wasn't clear why it

Re: RFR: JDK-8069079 - jimage extract / list to organize classes by modules

On 22/04/2016 14:12, Jim Laskey (Oracle) wrote: Listing is by module, extract has been by module for some time. http://cr.openjdk.java.net/~jlaskey/8069079/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8069079

Re: RFR: JDK-8082537 - jimage should print usage when started with no args

It can be outside, does the change add value? > On Apr 22, 2016, at 10:12 AM, Jim Laskey (Oracle) > wrote: > > Now prints usage. > > http://cr.openjdk.java.net/~jlaskey/8082537/webrev/index.html > > https://bugs.openjdk.java.net/

Re: RFR: JDK-8154090 - Remove support for jimage recreate

On 22/04/2016 14:12, Jim Laskey (Oracle) wrote: http://cr.openjdk.java.net/~jlaskey/8154090/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8154090 This looks to me

Re: RFR: JDK-8082537 - jimage should print usage when started with no args

On 22/04/2016 14:12, Jim Laskey (Oracle) wrote: Now prints usage. http://cr.openjdk.java.net/~jlaskey/8082537/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8082537

Re: java.lang.reflect.Module.WeakSet is not thread-safe

Hi Alan, Thanks for taking a look. On 04/21/2016 10:41 PM, Alan Bateman wrote: On 21/04/2016 20:52, Rémi Forax wrote: I remember seeing this codd an thinking that synchronized should do the job. I don't believe this use case requires something more complex. Remi I've taken a first pass over

Re: RFR: JDK-8154179 - BasicImageReader activating ImageBufferCache when not used

+1 On 2016-04-22 15:12, Jim Laskey (Oracle) wrote: The unused cache is being unnecessarily activated (ThreadLocal) when buffers are being released. http://cr.openjdk.java.net/~jlaskey/8154179/webrev/index.html https://bugs.openjd

Re: RFR: JDK-8153930 - Compiler crashed (intermittently)

Hi Jim, the openers field could (maybe even should) be final, otherwise this looks really good! Thanks! /Claes On 2016-04-22 15:12, Jim Laskey (Oracle) wrote: Two race conditions eliminated and ImageReader made idempotent. http://cr.openjdk.java.net/~jlaskey/8153930/webrev/index.html

RFR: JDK-8147634 - Need a JImage API that given a JImageLocationRef returns class name

Implemented as requested by the runtime team. http://cr.openjdk.java.net/~jlaskey/8147634/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8147634

RFR: JDK-8069079 - jimage extract / list to organize classes by modules

Listing is by module, extract has been by module for some time. http://cr.openjdk.java.net/~jlaskey/8069079/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8069079

RFR: JDK-8154179 - BasicImageReader activating ImageBufferCache when not used

The unused cache is being unnecessarily activated (ThreadLocal) when buffers are being released. http://cr.openjdk.java.net/~jlaskey/8154179/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8154179

RFR: JDK-8147426 - Missing definition for JIMAGE_NOT_FOUND

JIMAGE_NOT_FOUND was defined in the hotspot jimage.hpp header but not in the jdk jimage.hpp header. Brought the headers in line. http://cr.openjdk.java.net/~jlaskey/8147426/webrev/index.html https://bugs.openjdk.java.net/browse/JDK

RFR: JDK-8153930 - Compiler crashed (intermittently)

Two race conditions eliminated and ImageReader made idempotent. http://cr.openjdk.java.net/~jlaskey/8153930/webrev/index.html (Note webrev fails to diff ImageReader.java, best to view new file.) https://bugs.openjdk.java.net/browse/

RFR: JDK-8154090 - Remove support for jimage recreate

http://cr.openjdk.java.net/~jlaskey/8154090/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8154090

RFR: JDK-8082537 - jimage should print usage when started with no args

Now prints usage. http://cr.openjdk.java.net/~jlaskey/8082537/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8082537

Re: requires public for automatic modules

On 22/04/2016 11:36, Paul Bakker wrote: Thanks for the answer Remi. I'm wondering if a (optional) build step is considered. During build the byte code analysis that jdeps does could be used to generate better metadata for automatic modules. This would be a compromise between using automatic m

Re: requires public for automatic modules

Hi Alan, Thanks, the -addmods hint is a very useful one, I had not tried that yet. After adding the jackson.core and jackson.annotations explicitly to -addmods, I can compile/run without depending on them in my demonstrator module. That's a good workaround. Paul > On 22 Apr 2016, at 13:16,

Re: requires public for automatic modules

On 22/04/2016 09:52, Paul Bakker wrote: Why don't automatic modules take better care of transitive dependencies, so that the application's module-info looks similar to what it would after transforming the dependencies to named modules? As Rémi said, there isn't any static analysis done at com

Re: requires public for automatic modules

Thanks for the answer Remi. I'm wondering if a (optional) build step is considered. During build the byte code analysis that jdeps does could be used to generate better metadata for automatic modules. This would be a compromise between using automatic modules without this metadata and actually a

hg: jigsaw/jake/hotspot: 265 new changesets

Changeset: 70375b3285d9 Author:mgerdin Date: 2016-03-07 17:23 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/70375b3285d9 8151178: Move the collection set out of the G1 collector policy Summary: Create a G1CollectionSet class Reviewed-by: jwilhelm, tbenson, tschatzl

hg: jigsaw/jake/jdk: 75 new changesets

Changeset: 463463e306e0 Author:smarks Date: 2016-04-11 11:45 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/463463e306e0 8145461: finalize and integrate @Deprecated annotation specification change Reviewed-by: scolebourne, chegar, lancea ! src/java.base/share/classes/jav

hg: jigsaw/jake/corba: 3 new changesets

Changeset: 7bab1b1b3682 Author:chegar Date: 2016-04-15 16:19 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/7bab1b1b3682 8137058: Clear out all non-Critical APIs from sun.reflect Reviewed-by: alanb, jfranck, mchung ! src/java.corba/share/classes/sun/corba/Bridge.java

hg: jigsaw/jake/nashorn: 3 new changesets

Changeset: 295ac208a444 Author:chegar Date: 2016-04-15 16:19 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/295ac208a444 8137058: Clear out all non-Critical APIs from sun.reflect Reviewed-by: alanb, jfranck, mchung ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/

hg: jigsaw/jake: 26 new changesets

Changeset: 2abe79f8c412 Author:erikj Date: 2016-04-12 15:20 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/2abe79f8c412 8154070: Configuration script unable to detect boot JDK's modules support Reviewed-by: alanb ! common/autoconf/boot-jdk.m4 ! common/autoconf/generated-conf

hg: jigsaw/jake/jaxws: 2 new changesets

Changeset: 529f0bf896e5 Author:lana Date: 2016-04-21 12:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/529f0bf896e5 Added tag jdk-9+115 for changeset 4ff86e5489e4 ! .hgtags Changeset: 892b6c3e7ea7 Author:alanb Date: 2016-04-22 07:43 +0100 URL: http:/

hg: jigsaw/jake/langtools: 8 new changesets

Changeset: 73717a51063b Author:rfield Date: 2016-04-12 22:23 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/73717a51063b 8143955: JShell tool (UX): Output structure 8143956: JShell tool (UX): default prompts Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/i

hg: jigsaw/jake/jaxp: 5 new changesets

Changeset: 8be5606f3ea3 Author:joehw Date: 2016-04-12 14:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/8be5606f3ea3 8151162: Public entries not searched when prefer='system' Reviewed-by: lancea ! src/java.xml/share/classes/javax/xml/catalog/CatalogResolverImpl.java

Re: requires public for automatic modules

Hi Paul, - Mail original - > De: "Paul Bakker" > À: jigsaw-dev@openjdk.java.net > Envoyé: Vendredi 22 Avril 2016 10:52:23 > Objet: requires public for automatic modules > > Hello, > > I'm experimenting with automatic modules again. I have a module > "demonstrator" that uses Jackson Data

requires public for automatic modules

Hello, I'm experimenting with automatic modules again. I have a module "demonstrator" that uses Jackson Databind. import com.fasterxml.jackson.databind.ObjectMapper; ObjectMapper mapper = new ObjectMapper(); String json = mapper.writeValueAsString(modularity