hg: jigsaw/jake/jaxp: 4 new changesets

Changeset: e6d6c8126a36 Author:jjg Date: 2017-05-16 17:36 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/e6d6c8126a36 8180385: Fix HTML5 issues in the java.xml module Reviewed-by: joehw, lancea ! src/java.xml/share/classes/javax/xml/catalog/CatalogFeatures.java !

hg: jigsaw/jake: 11 new changesets

Changeset: 9c70f25ca307 Author:ihse Date: 2017-05-17 12:42 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/9c70f25ca307 8180472: Pandoc should generate html5 from markdown Reviewed-by: erikj ! common/doc/building.html ! common/doc/testing.html !

hg: jigsaw/jake/jdk: 28 new changesets

Changeset: 3e92641a337d Author:psandoz Date: 2017-05-09 15:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3e92641a337d 8177153: LambdaMetafactory has default constructor Reviewed-by: psandoz Contributed-by: ron.press...@oracle.com !

hg: jigsaw/jake/langtools: 7 new changesets

Changeset: ee84b7d44339 Author:jjg Date: 2017-05-09 17:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ee84b7d44339 8179479: Add new styles to enable HTML 5 tables Reviewed-by: bpatel !

hg: jigsaw/jake/jaxws: 2 new changesets

Changeset: 139e7c786ee4 Author:lana Date: 2017-05-18 14:54 + URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/139e7c786ee4 Added tag jdk-9+170 for changeset e75d3abe579a ! .hgtags Changeset: eb19676ed32f Author:mchung Date: 2017-05-18 14:18 -0700 URL:

hg: jigsaw/jake: 16 new changesets

Changeset: 7583288d0802 Author:ihse Date: 2017-05-10 09:02 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/7583288d0802 8178278: Move Standard Algorithm Names document to specs directory Reviewed-by: erikj ! make/Javadoc.gmk Changeset: 4635fa3adac6 Author:erikj Date:

hg: jigsaw/jake/corba: 4 new changesets

Changeset: a3e210a93f90 Author:jjg Date: 2017-05-10 15:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/a3e210a93f90 8180041: Fix HTML 5 issues in java.corba Reviewed-by: alanb, lancea ! src/java.corba/share/classes/com/sun/corba/se/spi/monitoring/package.html !

hg: jigsaw/jake/hotspot: 8 new changesets

Changeset: 830c73c1bd96 Author:ihse Date: 2017-05-11 09:00 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/830c73c1bd96 8174848: Remove gpl templates from hotspot/make Reviewed-by: erikj - make/templates/gpl-cp-header - make/templates/gpl-header Changeset:

hg: jigsaw/jake/nashorn: 3 new changesets

Changeset: 550bfc15779f Author:sdama Date: 2017-05-12 12:12 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/550bfc15779f 8179891: JavaDoc for for..in is incorrect Summary: Fixed javadoc typo error Reviewed-by: sundar, hannesw, jlaskey Contributed-by:

hg: jigsaw/jake/jaxp: 5 new changesets

Changeset: e79b44a9d2bd Author:joehw Date: 2017-05-09 18:26 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/e79b44a9d2bd 8179868: Java API Docs of javax.xml.transform.stax contains TODOs Reviewed-by: lancea, bpb !

Re: Request Review: JDK-8181639 Add tool and services information to module summary

I updated the javadoc per your comment/suggestion. My reply to some of your comments are inlined below. Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8181639/webrev.01/ Module summary pages: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8181639/api/ > On Jun 7, 2017, at 3:36

Re: Request Review: JDK-8181639 Add tool and services information to module summary

> On Jun 7, 2017, at 1:39 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 07/06/2017 18:58, Mandy Chung wrote: >> I updated the javadoc per your comment/suggestion. My reply to some >> of your comments are inlined below. >> >> Webrev: >&

Re: 8181087: Module system implementation refresh (6/2017 update)

> On Jun 14, 2017, at 9:52 AM, Alan Bateman wrote: > > It's time to bring the changes accumulated in the jake forest into jdk9/dev. > I'm hoping we are near the end of these updates and that we can close the > jake forest soon. > > A summary of the changes that have

Re: Review Request JDK-8182032: Make java.compiler upgradeable

The langtools modules are not intended nor required to be upgradeable. JDK 9 javap will only work with JDK 9 java.compiler. When IDE upgrades java.compiler to JDK 10 and runs on JDK 9, it would have to deliver a Java compiler implementing JDK 10 JavaCompiler API and could also implement the

Re: Review Request JDK-8182416: Clean up module-info.java like move requires transitive adjacent to exports

> On Jun 17, 2017, at 7:26 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 17/06/2017 07:27, Mandy Chung wrote: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8182416/webrev.00/ >> >> This patch cleans up module-info.java mainly moving requires tr

Review Request JDK-8182416: Clean up module-info.java like move requires transitive adjacent to exports

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8182416/webrev.00/ This patch cleans up module-info.java mainly moving requires transitive before exports, group exports/opens (packages) together and uses/provides (services) next. Document if a module is upgradeable. jdeps —-generate-module-info

hg: jigsaw/jake/langtools: Clean up jdk.jdeps module-info.java

Changeset: 046969a94992 Author:mchung Date: 2017-06-14 08:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/046969a94992 Clean up jdk.jdeps module-info.java ! src/jdk.jdeps/share/classes/module-info.java

Review Request JDK-8182032: Make java.compiler upgradeable

Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8182032/webrev.00/ java.compiler is a standalone technology that allows to be running on older JDK, in particular for IDE to support new language features. This patch takes out the make logic to find the modules that directly and

Re: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline

Hi Kevin, > On May 1, 2017, at 5:21 PM, Kevin Rushforth > wrote: > > This review is being cross-posted to both openjfx-dev and jigsaw-dev. > > Please review the proposed fix for: > > https://bugs.openjdk.java.net/browse/JDK-8177566 >

Re: Review Request: JDK-8020801: Apply the restriction of invoking MethodHandles.lookup to j.l.r.Method.invoke

ter Levart <peter.lev...@gmail.com> wrote: > > > On 05/02/2017 06:56 PM, Mandy Chung wrote: >>> On May 2, 2017, at 3:14 AM, Peter Levart <peter.lev...@gmail.com> >>> <mailto:peter.lev...@gmail.com> wrote: >>> >>> I don't quite understand

Re: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline

> On May 2, 2017, at 2:22 PM, Kevin Rushforth > wrote: > > Here is the message: > > IllegalAccessException: class com.sun.javafx.property.MethodHelper cannot > access class com.foo (in module foo.app) because module foo.app does not open > com.foo to javafx.base

hg: jigsaw/jake: Specify OS_* properties to release file at build time. Restore JDK 8 values

Changeset: cc2f50bc047d Author:mchung Date: 2017-05-01 21:10 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/cc2f50bc047d Specify OS_* properties to release file at build time. Restore JDK 8 values ! common/autoconf/generated-configure.sh ! common/autoconf/platform.m4 !

hg: jigsaw/jake/jdk: Do not define TARGET_PLATFORM property in release file

Changeset: a20dcd573138 Author:mchung Date: 2017-05-01 21:11 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a20dcd573138 Do not define TARGET_PLATFORM property in release file ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ReleaseInfoPlugin.java !

Re: 8178380: Module system implementation refresh (5/2017 update)

> On May 2, 2017, at 4:28 AM, Alan Bateman wrote: > > I think this would clutter the class description and it might be better if we > added a note to the getPackages method. > That’s an alternative. >>

Re: 8178380: Module system implementation refresh (5/2017 update)

> On May 2, 2017, at 3:11 AM, Chris Hegarty <chris.hega...@oracle.com> wrote: > > Mandy, > > On 02/05/17 03:47, Mandy Chung wrote: >> >>> ... >> src/jdk.jartool/share/classes/sun/tools/jar/Main.java >> 619 if (dflag) { &

Re: Review Request: JDK-8020801: Apply the restriction of invoking MethodHandles.lookup to j.l.r.Method.invoke

> On May 2, 2017, at 3:14 AM, Peter Levart wrote: > > I don't quite understand the need for bypassing the inflation of native into > generated method accessor The VM native reflection implementation does not know about this alternate `reflected$XXX` mechanism. No VM

Re: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline

Looks good. "Deploying an Application as a Module” section is duplicated in several JavaBean*Property classes. One alternative is to move it to the package summary. I have no objection to leave it as is. Mandy > On May 3, 2017, at 4:30 PM, Kevin Rushforth >

Re: Review Request: JDK-8181033: Confusing message: A JNI error has occurred, please check your installation and try again

> On May 25, 2017, at 12:24 AM, David Holmes <david.hol...@oracle.com> wrote: > > Correction ... > > On 25/05/2017 5:00 PM, David Holmes wrote: >> Hi Mandy >> On 25/05/2017 8:10 AM, Mandy Chung wrote: >>> http://cr.openjdk.java.net/~mchung/jdk9/webr

Review Request: JDK-8181033: Confusing message: A JNI error has occurred, please check your installation and try again

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8181033/webrev.00/ This fixes the launcher to print the exception being thrown rather than the confusing message "Error: A JNI error has occurred, please check your installation and try again”. A few attempts to improve this to catch

Re: 8186738: (sl) ServiceLoader::stream doesn't update cache

On 10/13/17 6:51 AM, Alan Bateman wrote: On 12/10/2017 23:54, mandy chung wrote: : test/jdk/java/util/ServiceLoader/security/test/p/Tests.java 184 assertTrue(e.getCause() instanceof Error); I think it's more precise to check e.getCause().getClass() == Error.class. You are right, that test

Re: RFR(S): 8138600: eliminate the need of ModuleLoaderMap.dat for CDS

(I move this thread from jdk10-dev to jigsaw-dev which can review the jdk change). The JDK change looks good to me. Mandy On 9/12/17 3:14 PM, Calvin Cheung wrote: With the fix for JDK-8186842 , we no longer need the ModuleLoaderMap to

Review Request: JDK-8186145: tools/launcher/modules/validate/ValidateModulesTest.java fails when launched with -XX:+EnableJVMCI

java --validate-modules requires only java.base to do the validation and hence the current implementation creates a minimum boot layer with java.base only.  It fails when running with -XX:+EnableJVMCI when VM attempts to load JVMCI class which is not in the boot layer.  This patch changes the

Re: Review Request: JDK-8186145: tools/launcher/modules/validate/ValidateModulesTest.java fails when launched with -XX:+EnableJVMCI

On 8/24/17 11:21 AM, Alan Bateman wrote: On 24/08/2017 19:05, mandy chung wrote: java --validate-modules requires only java.base to do the validation and hence the current implementation creates a minimum boot layer with java.base only.  It fails when running with -XX:+EnableJVMCI when VM

Re: """error: module testng reads package test from both test and testng"""

-- Test results: failed: 1 On Mon, Aug 21, 2017 at 12:12 PM, mandy chung <mandy.ch...@oracle.com <mailto:mandy.ch...@oracle.com>> wrote: The test itself is a module that depends on testng. So testng.jar is added as an automatic module. This test passes on my setup.

Re: """error: module testng reads package test from both test and testng"""

The test itself is a module that depends on testng. So testng.jar is added as an automatic module. This test passes on my setup. I am puzzling how jcommander.jar is added to the module path. Can you send the .jtr file and list what's in JTwork/modules directory? Mandy On 8/17/17 6:22 PM,

Re: 8186738: (sl) ServiceLoader::stream doesn't update cache

On 10/12/17 2:11 PM, Alan Bateman wrote: There are are two issues in ServiceLoader that we crept in with re-write here in JDK 9. One is with the new stream method where the Provider elements are specified to be cached but the implementation dropped it in the final version. The second is

Re: RFR 8189777: jlink --module-path default value and automatic addition of $JAVA_HOME/jmods if java.base is missing

On 10/23/17 3:37 AM, Sundararajan Athijegannathan wrote: Updated for getDefaultModulePath. moduleFinder uses three instance fields - modulepaths, limitmods and modules. We may have to pass all to the static method... http://cr.openjdk.java.net/~sundar/8189777/webrev.01 What happens to this

Re: 8192973: Adding "Resolution" to javadoc search index

+1 Mandy On 12/4/17 6:45 AM, Alan Bateman wrote: I'd like to add a search term to the javadoc search to make it easy to find the Resolution spec. Attached is the proposed patch. In terms we will need to do the same for service binding. -Alan $ hg diff

Re: RFR 8177471: jlink should use the version from java.base.jmod to find modules

Looks good.  Thanks for fixing this. Mandy On 11/13/17 2:02 AM, Sundararajan Athijegannathan wrote: Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8177471 Webrev: http://cr.openjdk.java.net/~sundar/8177471/webrev.00/index.html Thanks to Mandy for initial (internal) round of

Re: Regression in getImplementationVersion from Jigsaw

Hi Michael, It is indeed a bug and I file:    https://bugs.openjdk.java.net/browse/JDK-8190987 The patch looks good and I will sponsor this patch for you. Thanks for the regression test.  It'd be good to wrap the long lines and I will clean that up before I push. thanks Mandy On 11/8/17

Re: Regression in getImplementationVersion from Jigsaw

the limit was on line lengths, so I will watch and learn :) Thanks Michael On 9 November 2017 at 13:22, mandy chung <mandy.ch...@oracle.com> wrote: Hi Michael, It is indeed a bug and I file: https://bugs.openjdk.java.net/browse/JDK-8190987 The patch looks good and I will sponsor this

Review Request JDK-8192945: Need stable sort for MODULES entry in the release file

The MODULES list in the `release` file is topologically sorted. For a given module graph, the patch traverses the graph in a stable order during the topological sort that will produce the same result for the same module graph. Webrev at:

Re: RFR 8185130: jlink should throw error if target image and current JDK versions don't match

On 12/5/17 6:42 AM, Sundararajan Athijegannathan wrote: Updated to check minor version as well -> http://cr.openjdk.java.net/~sundar/8185130/webrev.01/index.html 454 throw new IllegalArgumentException(String.format("jlink version %d.%d != java.base version %d.%d", 455

Re: RFR 8185130: jlink should throw error if target image and current JDK versions don't match

On 12/5/17 9:43 AM, Sundararajan Athijegannathan wrote: Updated: http://cr.openjdk.java.net/~sundar/8185130/webrev.02/ Looks good.  Thanks for the update. Mandy

Re: 8182742: ClassLoader.getResourceXXX throws NPE when ClassLoader created by defineModulesWithXXX

+1 Mandy On 12/5/17 6:11 AM, Alan Bateman wrote: I need a Reviewer for a trivial change to the class loaders that support the ModuleLayer defineModulesWithXXXLoader methods. These methods create one or many class loaders to load classes/resources from the modules in the layer. The parent

Re: Proposal for New Functionality: Allow module-info merging in GenModuleInfoSource.java

/java/lang/management/internal/ManagementUtils.java - com/ibm/java/lang/management/internal/LoggingMXBeanImpl.java - java/lang/management/PlatformLoggingMXBean.java Ideally it'd be good to keep this functionality in these classes. Best Regards Adam Farley From: Adam Farley8/UK/IBM To: mandy chung <mandy

Re: Proposal for New Functionality: Allow module-info merging in GenModuleInfoSource.java

Can you send some example module-info.java & .extra files and source location that shows what functionality you depend on? Mandy On 12/7/17 4:20 AM, Adam Farley8 wrote: Update: OpenJ9 appears to need this functionality. Best Regards Adam Farley From: Adam Farley8/UK/IBM To: mandy c

Re: 8191867: Module attribute in 54.0+ class file cannot contains a requires java.base with ACC_TRANSITIVE or ACC_STATIC_PHASE

On 12/7/17 6:56 AM, Alan Bateman wrote: On 06/12/2017 17:17, mandy chung wrote: or it can print "java.base includes " + mods? I've adjusted the exception text so that it reads:    "The requires entry for java.base has ACC_TRANSITIVE set" and updated the webrev in

Re: Proposal for New Functionality: Allow module-info merging in GenModuleInfoSource.java

Moving this to jigsaw-dev On 12/6/17 8:38 AM, Adam Farley8 wrote: Hi All, Currently, GenModuleInfoSource.java does not allow you to merge extra module-info files into the primary module-info file (for a given module) at build time. This tool intends to augment platform-specific

Re: Review Request JDK-8192945: Need stable sort for MODULES entry in the release file

Okay this is a better version (traversing the graph keyset directly): http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8192945/webrev.02/ Mandy

Re: 8191867: Module attribute in 54.0+ class file cannot contains a requires java.base with ACC_TRANSITIVE or ACC_STATIC_PHASE

On 12/6/17 9:00 AM, Paul Sandoz wrote: On 6 Dec 2017, at 07:42, Alan Bateman wrote: The draft JVMS for Java SE 10 forbids an entry in the requires table of a Module attribute in a 54.0 or newer class file to require java.base with the ACC_TRANSITIVE or

Re: Review Request JDK-8192945: Need stable sort for MODULES entry in the release file

Updated webrev: http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8192945/webrev.01/ I kept the nodes as a Deque as it polls one node for traversal.   I fixed line 110-111 to use a Set. thanks Mandy

Re: 8186736: Spec clarifications for IllegalArgumentException throwing - ModuleLayer.defineX methods

Looks good to me. Mandy On 12/5/17 4:07 AM, Alan Bateman wrote: The description for the IllegalArgumentException thrown by the ModuleLayer.defineModulesXXX methods isn't very clear. Attached is the proposed patch to improve the wording, there are no implementation changes. Mandy has already

Re: RFR 8189777: jlink --module-path default value and automatic addition of $JAVA_HOME/jmods if java.base is missing

On 10/23/17 9:05 PM, Sundararajan Athijegannathan wrote: Hi, * ALL-MODULE-PATH case seems to be handled fine (in  private JlinkConfiguration initJlinkConfig() throws BadArgs { method). When no --module-path is specified, default module path is used and all default observable modules are

Re: RFR: 8202810: Remove class-for-name test

+1 I checked and this is the only test needed update. Mandy On 5/8/18 1:45 PM, Claes Redestad wrote: Hi, please review the removal of this test that explicitly attempts to run the now removed jlink --class-for-name plugin: diff -r 7f05a1e6a02a test/jdk/tools/jlink/JLinkPluginsTest.java

Re: RFR: 8202583: Remove experimental ClassForNamePlugin

On 5/7/18 6:23 AM, Claes Redestad wrote: Hi, the --class-for-name jlink plugin was added as an experiment to test and evolve the jlink plugin infrastructure. The actual effect of enabling this plugin on standard images is very limited (only a handful of Class.forName:s are replaced) and

Re: RFR(XS): 8205025: [AOT] make jdk.aot module upgradeable

On 6/14/18 9:35 AM, Doug Simon wrote: I changed the test (thanks Mandy for pointing out exactly which one), fixed the alphabetic ordering of the list and am running tests now. I reviewed http://cr.openjdk.java.net/~dnsimon/8205025/. Looks good. Mandy

Re: RFR(XS): 8205025: [AOT] make jdk.aot module upgradeable

test/jdk/jdk/modules/etc/UpgradeableModules.java needs to be updated as it keeps the list of upgradeable modules as well to verify the hashes in java.base. Mandy On 6/14/18 1:09 AM, Doug Simon wrote: In the context of JDK-8202762, we to need to make the jdk.aot module upgradeable.

Review Request JDK-8200121: Remove unused qualified exports in java.base

A simple cleanup to remove unused qualified exports in java.base. The webrev also includes a fix for JDK-8205116 (jdeps --system $java.home fails) that I uncovered through this process where I ran `jdeps --check java.base --system $java.home` on the JDK binaries on several platforms. Webrev

Re: Review Request JDK-8200121: Remove unused qualified exports in java.base

On 6/15/18 12:45 PM, Alan Bateman wrote: On 15/06/2018 20:14, mandy chung wrote: Alan, Lance, I added a test case for JDK-8205116 in test/langtools/tools/jdeps/Options.java. Updated webrev for JDK-8205116 only: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8205116/webrev.01

Review Request 8205112: Remove non-existent modules from test/jdk/jdk/modules/etc/UpgradeableModules.java

This patch cleans up the list of upgradeable modules kept in test/jdk/jdk/modules/etc/UpgradeableModules.java test verification and take out the modules that have been removed. thanks Mandy --- a/test/jdk/jdk/modules/etc/UpgradeableModules.java +++

Re: Review Request JDK-8200121: Remove unused qualified exports in java.base

Alan, Lance, I added a test case for JDK-8205116 in test/langtools/tools/jdeps/Options.java. Updated webrev for JDK-8205116 only: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8205116/webrev.01/ Mandy On 6/15/18 10:47 AM, Alan Bateman wrote: On 15/06/2018 17:34, mandy chung wrote

Re: jlink / jmods version compatibiltiy

On 6/1/18 3:24 PM, Bernd Eckenfels wrote: Hello, I am not sure what the Policy for backward/Forward compatibility for JMOD files is, but when I use JDK-9.0.4 jlink on 11ea JMODs I get a IllegalArgumentException and „error reading“ by JDK-10.0.1 with no further Details. jlink only supports

Re: RFR: 8205926: Support invokeSpecialIFC in GenerateJLIClassesPlugin

On 6/27/18 6:40 AM, Claes Redestad wrote: Hi, JDK-8200167 introduced a new DMH kind, invokeSpecialIFC, which slightly perturbed what forms we see on startup, which is linked to some minor startup regressions in 11+19 Add support for

Re: RFR 8189671: jlink should clearly report error when an automatic module is used as root

to include the pathname to the exception message. Nit: long line and good to wrap it into multiple lines. Mandy P.S.  My previous reply lost the formatting and I fixed the copy below (just as a record for easy viewing). On 10/19/17 2:58 PM, mandy chung wrote: On 10/19/17 7:04 AM, Sundararajan Athij

Re: RFR 8189671: jlink should clearly report error when an automatic module is used as root

On 10/19/17 7:04 AM, Sundararajan Athijegannathan wrote: Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8189671 Webrev: http://cr.openjdk.java.net/~sundar/8189671/webrev.00/ 441 ModuleFinder finder = config.finder(); 442 for (String root : config.getModules()) { This should

Re: RFR 8189777: jlink --module-path default value and automatic addition of $JAVA_HOME/jmods if java.base is missing

jlink --add-modules ALL-MODULE-PATH does not work in this patch since the default module is added after the roots set is computed. AppRuntimeImageBuilder could calls its moduleFinder method (that calls JlinkTask::newModuleFinder).   packager may already provide the default module path and we

Re: RFR 8189671: jlink should clearly report error when an automatic module is used

On 10/20/17 1:03 AM, Sundararajan Athijegannathan wrote: Updated: http://cr.openjdk.java.net/~sundar/8189671/webrev.03/ Looks good. Mandy

Re: jar --print-module-descriptor

I created https://bugs.openjdk.java.net/browse/JDK-8194653 to fix the docs bug.   The docs was missed to be updated when this jar option was renamed to --describe-module. Thanks for reporting this. Mandy On 1/4/18 2:16 PM, Nicolai Parlog wrote: Hi! The Java 9 jar documentation says[1]:

[10] RFR JDK-8194229: tools/jmod/JmodTest.jtr fails when no privilege to create sym link on windows

This is a simple test-only fix. IOException may be thrown when a symlink is failed to create on windows. The test should handle such case in addition to UOE. Webrev at: http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8194229/webrev.00/ Mandy

Re: How does one handle a java method which returns a non-public sub-type via reflection?

On 1/12/18 10:26 AM, jeffrey kutcher wrote: m = o.getClass().getMethod("add", new Class[] { Object.class, }); o = m.invoke(o, new Object[] { button1, }); o.getClass().getMethod(...) is an anti-pattern for finding a public method.   Object.getClass() returns the

[11] RFR JDK-8196310: jlink --suggest-providers fails with missing resource if --output specified

Webrev: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8196310/webrev.00/ Improve the error message when invalid argument is specified to --suggest-providers option. $ jlink --add-modules java.base --suggest-providers java.security.Provider --output myimage Error: --suggest-providers does

Re: [11] RFR JDK-8196310: jlink --suggest-providers fails with missing resource if --output specified

(resend with fixed formatting) Webrev: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8196310/webrev.00/ Improve the error message when invalid argument is specified to --suggest-providers option. $ jlink --add-modules java.base --suggest-providers java.security.Provider --output

Re: [11] RFR JDK-8196310: jlink --suggest-providers fails with missing resource if --output specified

he message to …does not accept *the* “-output…” or …does not *support* *the* “-output…” Best Lance On Jan 30, 2018, at 7:31 PM, mandy chung <mandy.ch...@oracle.com <mailto:mandy.ch...@oracle.com>> wrote: (resend with fixed formatting) Webrev: http://cr.openjdk.java.net/~mchung

Re: IllegalAccessException trying to load a ResourceBundle in 9u181

On 2/12/18 12:36 PM, Vitaly Davidovich wrote: Hi all, I'm not sure if core-libs is the right mailing list for jigsaw/modules questions these days (rather than jigsaw-dev), so please feel free to forward this there if it's the more appropriate list. cc'ing  jigsaw-dev I have the following

Re: RFR JDK-8170114 jimage extract to not an empty directory overwrites content of the directory

On 2/9/18 7:23 AM, Michal Vala wrote: Patch validates output directory before any jimage extracting happen. I've moved validation to extra private method as it is few lines of code. I've also added proper error message for case when output path is not a directory (JImageTask.java#449).

Re: RFR 8194922: jlink --exclude-resources should never exclude module-info.class

Looks good.  I agree that this should be an error when excluding module declaration. Mandy On 2/20/18 1:50 AM, Sundararajan Athijegannathan wrote: Throwing exception now -> http://cr.openjdk.java.net/~sundar/8194922/webrev.02/ Thanks -Sundar On 20/02/18, 2:54 PM, Alan Bateman wrote: On

Re: 8197532: Re-examine policy for the default set of modules when compiling or running code on the class path

I looked through the change and looks good. Mandy On 6/19/18 1:31 AM, Alan Bateman wrote: JEP 261 details how the default set of root modules is computed when compiling code in the unnamed module or when running code and the main class is loaded from the class path. I'd like to re-visit

Re: 8194937: Inconsistent behavior of --validate-modules when combined with -m and other options

The change looks good. I'm glad that we get rid of the need for the minimal boot layer for validation and gets the option handling consistent. thanks Mandy On 6/20/18 11:40 PM, Alan Bateman wrote: The java `--validatate-modules` option is a very useful option to scan all modules to

[12] RFR JDK-8202941: GenModuleInfoSource build tool does not detect missing semicolons

GenModuleInfoSource build tool augments module-info.java to include platform-specific qualified exports/opens and uses/provides services. This fixes the build tool to catch syntax errors as closely as javac does. The build tool remains to allow duplicated provides until JDK-8208463 is resolved.

Re: RFR: 8209003: Consolidate use of empty collections in java.lang.module

This cleanup looks fine. Mandy On 8/7/18 9:16 AM, Claes Redestad wrote: Hi, feel free to review this cleanup to consolidate some uses of Collections.empty/unmodifiableXx.. to Set/Map/List.of()/copyOf(), as appropriate. This aligns better with code already generated by jlink, so avoids

Re: RFR 8193033 remove terminally deprecated sun.misc.Unsafe.defineClass

+1 Mandy On 3/15/18 10:06 AM, Paul Sandoz wrote: Hi, Please review this patch to remove sun.misc.Unsafe.defineClass in 11. There has been much outreach, by Alan and the Jigsaw team, about its public replacement MethodHandles.Lookup.defineClass. CSR is here:

Re: RFR: 8187490: HotSpotRuntimeMBean should be moved to Graal management module

On 4/13/18 2:24 AM, Doug Simon wrote: Please review this change that removes the existing Graal service provider for hooking into the Platform MBean Server and makes jdk.internal.vm.compiler.management an upgradeable module. Please refer to

Re: RFR: 8201794: [Graal] fix regressions from JDK-8187490

Looks okay.  Have you run all jdk_core tests in addition to other hotspot tests. Mandy On 4/18/18 7:00 PM, Doug Simon wrote: I've updated the webrev with a fix for another regression caused by JDK-8187490: --- old/test/jdk/jdk/modules/etc/UpgradeableModules.java2018-04-18

Re: Avoiding sun.misc.Unsafe and embracing modules in Java libraries: missing links

Hi Rafael, FYI.  I have sent a proposal [1] for item #1 to serviceability-dev and you for discussion.  JBS issue is:    https://bugs.openjdk.java.net/browse/JDK-8200559 Mandy [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-April/023529.html On 4/2/18 5:02 AM, Rafael

Re: 8205533: Class.getPackage() fails with InternalError if class is defined to the bootstrap class loader but module is not in the boot layer

On 6/24/18 7:32 AM, Alan Bateman wrote: This is a corner case that showed up while chasing an issue in another area. If a tool uses the attach mechanism to start the JMX agent in a running VM that doesn't have the jdk.management.agent module in the boot layer then the module is resolved and

Re: Separate logging for JPMS module/layer

On 10/5/18 8:11 AM, Ralph Goers wrote: Benchmark Mode Cnt Score Error Units StackTraceBenchmark.defaultJava8 thrpt 3 113965.921 ± 119706.986 ops/s StackTraceBenchmark.securityManager thrpt 3 788004.237 ± 82578.567 ops/s StackTraceBenchmark.stackWalker thrpt 3 182902.031 ± 39018.395 ops/s

Re: Separate logging for JPMS module/layer

org>> wrote: Unfortunately, we can’t use getCallerClass. Some API methods can be called by users of the API or by other methods in the API class. Ralph On Oct 4, 2018, at 2:50 PM, Mandy Chung <mailto:mandy.ch...@oracle.com>> wrote: If you are looking for the immediate caller, you c

Re: Testing whether or not a Lookup object has access to members

Lookup.accessClass(member.getDeclaringClass()) can be used to test if the lookup class can access the declaring class of the given member. This only checks if a class is accessible.  I think unreflecting a member will do what you are looking for to check if the lookup object has access to the

Re: Testing whether or not a Lookup object has access to members

if something like this was available: boolean Lookup.isAccessible(Member member) boolean Lookup.isAccessible(Class member) /Kasper On Tue, 23 Oct 2018 at 00:07, Mandy Chung <mailto:mandy.ch...@oracle.com>> wrote: Lookup.accessClass(member.getDeclaringClass()) can be use

Re: Testing whether or not a Lookup object has access to members

You can submit from https://bugreport.java.com/bugreport/ Mandy On 10/26/18 2:48 AM, Kasper Nielsen wrote: Hi Mandy, I don't have access to JBS unfortunately. Cheers   Kasper On Wed, 24 Oct 2018 at 16:50, Mandy Chung <mailto:mandy.ch...@oracle.com>> wrote: Can you file a

Re: Separate logging for JPMS module/layer

If you are looking for the immediate caller, you can try StackWalker::getCallerClass which only walks the top few frames and intends to be lower cost. Mandy On 10/4/18 2:04 PM, Ralph Goers wrote: Hmm, it would probably be a safe assumption that a Logger will never be used outside of the

Re: Separate logging for JPMS module/layer

ive frames as I see). Mandy On Thu, Oct 4, 2018 at 3:51 PM Mandy Chung <mailto:mandy.ch...@oracle.com>> wrote: If you are looking for the immediate caller, you can try StackWalker::getCallerClass which only walks the top few frames and intends to be lower cost. Mand

Re: 8211825: ModuleLayer.defineModulesWithXXX does not setup delegation when module reads automatic module

On 10/8/18 7:46 AM, Alan Bateman wrote: This is the issue that Thomas Watson brought up here on Friday. If defineModulesWithXXX is used to create a module layer and it contains a module that reads an automatic module mapped to a different class loader (same layer or parent layer) then the

Re: Newbie Jigsaw question: How should I use 'jmod hash'

On 1/22/19 4:59 AM, Andre Tadeu de Carvalho wrote: Em ter, 22 de jan de 2019 às 10:06, Alan Bateman escreveu: On 21/01/2019 12:57, Andre Tadeu de Carvalho wrote: Hi, I am exploring the jmod utility and I am stuck with the following: I already generated the jmod file and I want to add a

Re: [Proposal] jlink plugin which replaces dynamic shared libraries

I also like this, stripping the native debug symbols, as a jlink plugin. Currently jlink does not support platform-specific plugin.   The Plugin API will need to be extended to specific the supported platforms, for example Plugin::isSupported and default to return true.   jlink will need to

Re: RFR: 8214230: Classes generated by SystemModulesPlugin.java are not reproducable

On 11/29/18 12:47 AM, Erik Helin wrote: I agree as well, nice suggestion Claes! Please see updated patches below: - incremental: http://cr.openjdk.java.net/~ehelin/8214230/00-01/ - full: http://cr.openjdk.java.net/~ehelin/8214230/01/ +1 Mandy

Re: RFR 8212137: Remove JrtFileSystem finalize method

On 12/7/18 12:47 AM, Sundararajan Athijegannathan wrote: Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8212137 Webrev: https://cr.openjdk.java.net/~sundar/8212137/webrev.00/ Looks okay to me. Mandy

Re: RFR: 8214230: Classes generated by SystemModulesPlugin.java are not reproducable

On 11/28/18 1:59 AM, Erik Helin wrote: Hi all, this small patch ensures that two classes generated by jlink's SystemModulePlugin (SystemModules$default and SystemModules$all) are generated in a reproducible manner. That is, if you run jlink two times in a row with identical input, then

Re: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries

On 2/25/19 2:49 AM, Alan Bateman wrote: On 15/02/2019 17:01, Severin Gehwolf wrote: : ->8- Plugin Name: strip-native-debug-symbols Option: --strip-native-debug-symbols= Description: Strip debug symbols from native libraries (if any).   This plugin requires at

<    4   5   6   7   8   9   10   >