From fenix_young at hotmail.com Mon Apr 8 09:52:00 2019 From: fenix_young at hotmail.com (xiaofeng Young) Date: Mon, 8 Apr 2019 09:52:00 +0000 Subject: JMH JDK Microbenchmarks refer to Oracle internal infras? Message-ID: Hi, not sure if this alias is suitable. I'm trying to build and run JDK micro-benchmarks with following guides Wiki: http://openjdk.java.net/projects/code-tools/jmh-jdk-microbenchmarks/ Repo: http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/a644f3612e8d/README.md After cloning the repo, a simple build with "mvn clean install" fails. It refers an oracle infra, http://maven.se.oracle.com/nexus/content/groups/public. http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/a644f3612e8d/pom.xml Stockholm Repository http://maven.se.oracle.com/nexus/content/groups/public Is it an internal one? How can I fix or workaround? See the mvn failure: [INFO] OpenJDK Microbenchmark Corpus (JDK 8) .............. FAILURE [ 0.259 s] [INFO] OpenJDK Microbenchmark Corpus (Uber-Package) 1.0-SNAPSHOT SKIPPED [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 1.019 s [INFO] Finished at: 2019-04-08T17:26:12+08:00 [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal on project micros-jdk8: Could not resolve dependencies for project org.openjdk:micros-jdk8:jar:1.0-SNAPSHOT: Failed to collect dependencies at org.openjdk:micros-util:jar:1.0-SNAPSHOT: Failed to read artifact descriptor for org.openjdk:micros-util:jar:1.0-SNAPSHOT: Could not transfer artifact org.openjdk:micros-util:pom:1.0-SNAPSHOT from/to Stockholm Repository (http://maven.se.oracle.com/nexus/content/groups/public): maven.se.oracle.com: Unknown host maven.se.oracle.com -> [Help 1] Thank you very much! Felix Yang From eric.caspole at oracle.com Mon Apr 8 14:41:48 2019 From: eric.caspole at oracle.com (Eric Caspole) Date: Mon, 8 Apr 2019 10:41:48 -0400 Subject: JMH JDK Microbenchmarks refer to Oracle internal infras? In-Reply-To: References: Message-ID: Hi Felix, Thanks for pointing this out, that repo is not used in the build and I will fix the pom in the repo later today. In the mean time you can remove it: $ hg diff diff -r a644f3612e8d pom.xml --- a/pom.xml Tue Mar 26 15:56:51 2019 -0400 +++ b/pom.xml Mon Apr 08 10:38:29 2019 -0400 @@ -291,13 +291,6 @@ - - - Stockholm Repository - http://maven.se.oracle.com/nexus/content/groups/public - - - Regards, Eric On 4/8/19 05:52, xiaofeng Young wrote: > Hi, > not sure if this alias is suitable. I'm trying to build and run JDK micro-benchmarks with following guides > Wiki: http://openjdk.java.net/projects/code-tools/jmh-jdk-microbenchmarks/ > Repo: http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/a644f3612e8d/README.md > > After cloning the repo, a simple build with "mvn clean install" fails. It refers an oracle infra, http://maven.se.oracle.com/nexus/content/groups/public. > http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/a644f3612e8d/pom.xml > > > > Stockholm Repository > http://maven.se.oracle.com/nexus/content/groups/public > > > > > Is it an internal one? How can I fix or workaround? > > See the mvn failure: > > [INFO] OpenJDK Microbenchmark Corpus (JDK 8) .............. FAILURE [ 0.259 s] > [INFO] OpenJDK Microbenchmark Corpus (Uber-Package) 1.0-SNAPSHOT SKIPPED > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 1.019 s > [INFO] Finished at: 2019-04-08T17:26:12+08:00 > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal on project micros-jdk8: Could not resolve dependencies for project org.openjdk:micros-jdk8:jar:1.0-SNAPSHOT: Failed to collect dependencies at org.openjdk:micros-util:jar:1.0-SNAPSHOT: Failed to read artifact descriptor for org.openjdk:micros-util:jar:1.0-SNAPSHOT: Could not transfer artifact org.openjdk:micros-util:pom:1.0-SNAPSHOT from/to Stockholm Repository (http://maven.se.oracle.com/nexus/content/groups/public): maven.se.oracle.com: Unknown host maven.se.oracle.com -> [Help 1] > > Thank you very much! > Felix Yang > From fenix_young at hotmail.com Wed Apr 10 10:14:16 2019 From: fenix_young at hotmail.com (xiaofeng Young) Date: Wed, 10 Apr 2019 10:14:16 +0000 Subject: JMH JDK Microbenchmarks refer to Oracle internal infras? In-Reply-To: References: , Message-ID: Hi Eric, thanks for the quick update. After remove the repo, it exposes another issue to fail with jdk 8. micros-util/src/main/java/org/openjdk/bench/util/InMemoryJavaCompiler.java refers a constant PATCH_MODULE_PATH, overrides methods of getLocationForModule() and inferModuleName() , which are all since jdk 9. Not sure if these are necessary. I removed them and the tests run well. See the patch below: http://cr.openjdk.java.net/~xiaofeya/code-tools/webrev.00/ Thanks, Felix Yang ________________________________ From: code-tools-dev on behalf of Eric Caspole Sent: Monday, April 8, 2019 22:41 To: code-tools-dev at openjdk.java.net Subject: Re: JMH JDK Microbenchmarks refer to Oracle internal infras? Hi Felix, Thanks for pointing this out, that repo is not used in the build and I will fix the pom in the repo later today. In the mean time you can remove it: $ hg diff diff -r a644f3612e8d pom.xml --- a/pom.xml Tue Mar 26 15:56:51 2019 -0400 +++ b/pom.xml Mon Apr 08 10:38:29 2019 -0400 @@ -291,13 +291,6 @@ - - - Stockholm Repository - http://maven.se.oracle.com/nexus/content/groups/public - - - Regards, Eric On 4/8/19 05:52, xiaofeng Young wrote: > Hi, > not sure if this alias is suitable. I'm trying to build and run JDK micro-benchmarks with following guides > Wiki: http://openjdk.java.net/projects/code-tools/jmh-jdk-microbenchmarks/ > Repo: http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/a644f3612e8d/README.md > > After cloning the repo, a simple build with "mvn clean install" fails. It refers an oracle infra, http://maven.se.oracle.com/nexus/content/groups/public. > http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/a644f3612e8d/pom.xml > > > > Stockholm Repository > http://maven.se.oracle.com/nexus/content/groups/public > > > > > Is it an internal one? How can I fix or workaround? > > See the mvn failure: > > [INFO] OpenJDK Microbenchmark Corpus (JDK 8) .............. FAILURE [ 0.259 s] > [INFO] OpenJDK Microbenchmark Corpus (Uber-Package) 1.0-SNAPSHOT SKIPPED > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 1.019 s > [INFO] Finished at: 2019-04-08T17:26:12+08:00 > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal on project micros-jdk8: Could not resolve dependencies for project org.openjdk:micros-jdk8:jar:1.0-SNAPSHOT: Failed to collect dependencies at org.openjdk:micros-util:jar:1.0-SNAPSHOT: Failed to read artifact descriptor for org.openjdk:micros-util:jar:1.0-SNAPSHOT: Could not transfer artifact org.openjdk:micros-util:pom:1.0-SNAPSHOT from/to Stockholm Repository (http://maven.se.oracle.com/nexus/content/groups/public): maven.se.oracle.com: Unknown host maven.se.oracle.com -> [Help 1] > > Thank you very much! > Felix Yang > From eric.caspole at oracle.com Wed Apr 10 22:32:28 2019 From: eric.caspole at oracle.com (eric.caspole at oracle.com) Date: Wed, 10 Apr 2019 18:32:28 -0400 Subject: JMH JDK Microbenchmarks refer to Oracle internal infras? In-Reply-To: References:

Message-ID: Hi Felix, I fixed this here: http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/rev/d0fab231915f I moved the test needing the in memory compiler to the JDK 11 dir where it probably should have been in the first place. So now it builds with 8, 11, 12 etc. Give it a try. Thanks for finding these problems! Eric On 4/10/19 6:14 AM, xiaofeng Young wrote: > Hi Eric, > thanks?for the quick update. After remove the repo, it exposes another > issue to fail with? jdk 8. > micros-util/src/main/java/org/openjdk/bench/util/InMemoryJavaCompiler.java > refers a constant PATCH_MODULE_PATH, overrides?methods of > getLocationForModule() and?inferModuleName()? , which are all since > jdk 9. > > Not sure if these are necessary. I removed them and the tests run > well. See the patch below: > > http://cr.openjdk.java.net/~xiaofeya/code-tools/webrev.00/ > > > Thanks, > Felix Yang > ------------------------------------------------------------------------ > *From:* code-tools-dev on > behalf of Eric Caspole > *Sent:* Monday, April 8, 2019 22:41 > *To:* code-tools-dev at openjdk.java.net > *Subject:* Re: JMH JDK Microbenchmarks refer to Oracle internal infras? > Hi Felix, > Thanks for pointing this out, that repo is not used in the build and I > will fix the pom in the repo later today. > > In the mean time you can remove it: > > $ hg diff > diff -r a644f3612e8d pom.xml > --- a/pom.xml?? Tue Mar 26 15:56:51 2019 -0400 > +++ b/pom.xml?? Mon Apr 08 10:38:29 2019 -0400 > @@ -291,13 +291,6 @@ > ????????? > ????? > > -??? > -??????? > -??????????? Stockholm Repository > - > http://maven.se.oracle.com/nexus/content/groups/public > -??????? > -??? > - > > Regards, > Eric > > > On 4/8/19 05:52, xiaofeng Young wrote: > > Hi, > >???? not sure if this alias is suitable. I'm trying to build and run > JDK micro-benchmarks with following guides > > Wiki: > http://openjdk.java.net/projects/code-tools/jmh-jdk-microbenchmarks/ > > Repo: > http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/a644f3612e8d/README.md > > > > After cloning the repo, a simple build with "mvn clean install" > fails. It refers an oracle infra, > http://maven.se.oracle.com/nexus/content/groups/public. > > > http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/a644f3612e8d/pom.xml > > > > > > > > > >????????????? Stockholm > Repository > > > http://maven.se.oracle.com/nexus/content/groups/public > > > > > > > > > > > > Is it an internal one? How can I fix or workaround? > > > > See the mvn failure: > > > > [INFO] OpenJDK Microbenchmark Corpus (JDK 8) .............. FAILURE > [? 0.259 s] > > [INFO] OpenJDK Microbenchmark Corpus (Uber-Package) 1.0-SNAPSHOT SKIPPED > > [INFO] > ------------------------------------------------------------------------ > > [INFO] BUILD FAILURE > > [INFO] > ------------------------------------------------------------------------ > > [INFO] Total time: 1.019 s > > [INFO] Finished at: 2019-04-08T17:26:12+08:00 > > [INFO] > ------------------------------------------------------------------------ > > [ERROR] Failed to execute goal on project micros-jdk8: Could not > resolve dependencies for project > org.openjdk:micros-jdk8:jar:1.0-SNAPSHOT: Failed to collect > dependencies at org.openjdk:micros-util:jar:1.0-SNAPSHOT: Failed to > read artifact descriptor for org.openjdk:micros-util:jar:1.0-SNAPSHOT: > Could not transfer artifact org.openjdk:micros-util:pom:1.0-SNAPSHOT > from/to Stockholm Repository > (http://maven.se.oracle.com/nexus/content/groups/public): > maven.se.oracle.com: Unknown host maven.se.oracle.com -> [Help 1] > > > > Thank you very much! > > Felix Yang > > From fenix_young at hotmail.com Thu Apr 11 04:27:22 2019 From: fenix_young at hotmail.com (xiaofeng Young) Date: Thu, 11 Apr 2019 04:27:22 +0000 Subject: JMH JDK Microbenchmarks refer to Oracle internal infras? In-Reply-To: References:

, Message-ID: Hi Eric, works well, thank you very much! Felix Yang ________________________________ From: eric.caspole at oracle.com Sent: Thursday, April 11, 2019 6:32 To: xiaofeng Young; code-tools-dev at openjdk.java.net Subject: Re: JMH JDK Microbenchmarks refer to Oracle internal infras? Hi Felix, I fixed this here: http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/rev/d0fab231915f I moved the test needing the in memory compiler to the JDK 11 dir where it probably should have been in the first place. So now it builds with 8, 11, 12 etc. Give it a try. Thanks for finding these problems! Eric On 4/10/19 6:14 AM, xiaofeng Young wrote: Hi Eric, thanks for the quick update. After remove the repo, it exposes another issue to fail with jdk 8. micros-util/src/main/java/org/openjdk/bench/util/InMemoryJavaCompiler.java refers a constant PATCH_MODULE_PATH, overrides methods of getLocationForModule() and inferModuleName() , which are all since jdk 9. Not sure if these are necessary. I removed them and the tests run well. See the patch below: http://cr.openjdk.java.net/~xiaofeya/code-tools/webrev.00/ Thanks, Felix Yang ________________________________ From: code-tools-dev

on behalf of Eric Caspole Sent: Monday, April 8, 2019 22:41 To: code-tools-dev at openjdk.java.net Subject: Re: JMH JDK Microbenchmarks refer to Oracle internal infras? Hi Felix, Thanks for pointing this out, that repo is not used in the build and I will fix the pom in the repo later today. In the mean time you can remove it: $ hg diff diff -r a644f3612e8d pom.xml --- a/pom.xml Tue Mar 26 15:56:51 2019 -0400 +++ b/pom.xml Mon Apr 08 10:38:29 2019 -0400 @@ -291,13 +291,6 @@ - - - Stockholm Repository - http://maven.se.oracle.com/nexus/content/groups/public - - - Regards, Eric On 4/8/19 05:52, xiaofeng Young wrote: > Hi, > not sure if this alias is suitable. I'm trying to build and run JDK micro-benchmarks with following guides > Wiki: http://openjdk.java.net/projects/code-tools/jmh-jdk-microbenchmarks/ > Repo: http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/a644f3612e8d/README.md > > After cloning the repo, a simple build with "mvn clean install" fails. It refers an oracle infra, http://maven.se.oracle.com/nexus/content/groups/public. > http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/a644f3612e8d/pom.xml > > > > Stockholm Repository > http://maven.se.oracle.com/nexus/content/groups/public > > > > > Is it an internal one? How can I fix or workaround? > > See the mvn failure: > > [INFO] OpenJDK Microbenchmark Corpus (JDK 8) .............. FAILURE [ 0.259 s] > [INFO] OpenJDK Microbenchmark Corpus (Uber-Package) 1.0-SNAPSHOT SKIPPED > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 1.019 s > [INFO] Finished at: 2019-04-08T17:26:12+08:00 > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal on project micros-jdk8: Could not resolve dependencies for project org.openjdk:micros-jdk8:jar:1.0-SNAPSHOT: Failed to collect dependencies at org.openjdk:micros-util:jar:1.0-SNAPSHOT: Failed to read artifact descriptor for org.openjdk:micros-util:jar:1.0-SNAPSHOT: Could not transfer artifact org.openjdk:micros-util:pom:1.0-SNAPSHOT from/to Stockholm Repository (http://maven.se.oracle.com/nexus/content/groups/public): maven.se.oracle.com: Unknown host maven.se.oracle.com -> [Help 1] > > Thank you very much! > Felix Yang > From roger.calnan at oracle.com Fri Apr 12 16:14:28 2019 From: roger.calnan at oracle.com (Roger Calnan) Date: Fri, 12 Apr 2019 09:14:28 -0700 Subject: CodeTools proposal: "releasenotes" Message-ID: <9BD55ACA-DF9B-4422-8F06-CEE171D2DBD2@oracle.com> Name: releasenotes Summary: A Utility to Generate Release Notes for OpenJDK Releases Proposed by: Roger Calnan Rationale: For a few years now the release note associated with a JDK fix has been managed as a SubTask of the issue in JBS[1], rather than the previous ad-hoc model where the notes were, in the best case, a comment in the issue itself. The move to a more defined process has allowed the release notes to be generated for each build of a release[2], or a more formal set of release notes for the GA[3]. Until now, there has not been OpenJDK documentation on how to create a release note, a simple way for a developer to see what the release note would look like (the notes are written in MarkDown), nor a straightforward way to generate a collection of release notes. The releasenotes project will provide the developer user documentation, which covers the creation of a release note, and a Java application to display an individual release note or, query JBS and generate a page with all the notes for a release[4]. The proposal is to have this as an OpenJDK/codetools sub-project. [1] https://bugs.openjdk.java.net/browse/JDK-8218009 [2] https://jdk.java.net/13/release-notes [3] https://jdk.java.net/12/release-notes [4] http://cr.openjdk.java.net/~jjg/RelNotes.html From eric.caspole at oracle.com Wed Apr 17 16:12:17 2019 From: eric.caspole at oracle.com (eric.caspole at oracle.com) Date: Wed, 17 Apr 2019 12:12:17 -0400 Subject: CFV: New Code Tools Committer: Sergey Kuksenko Message-ID: <032a4727-5a6c-320e-256e-d4d883314b39@oracle.com> I hereby nominate Sergey Kuksenko to Code Tools Committer. Sergey has contributed 10 changesets to JMH and he was one of the original developers of JMH before it was contributed into OpenJDK. He is also a JDK and Valhalla Committer. Votes are due by 1pm Eastern, May 1, 2019. Only current Code Tools Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. -- Eric Caspole [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote From eric.caspole at oracle.com Wed Apr 17 16:16:08 2019 From: eric.caspole at oracle.com (eric.caspole at oracle.com) Date: Wed, 17 Apr 2019 12:16:08 -0400 Subject: CFV: New Code Tools Committer: Sergey Kuksenko In-Reply-To: <032a4727-5a6c-320e-256e-d4d883314b39@oracle.com> References: <032a4727-5a6c-320e-256e-d4d883314b39@oracle.com> Message-ID: <633edff0-56bb-cd9a-8265-28e37d7a1694@oracle.com> Vote: yes Eric On 4/17/19 12:12 PM, eric.caspole at oracle.com wrote: > I hereby nominate Sergey Kuksenko to Code Tools Committer. > > Sergey has contributed 10 changesets to JMH and he was one of the > original developers of JMH before it was contributed into OpenJDK. > > He is also a JDK and Valhalla Committer. > > Votes are due by 1pm Eastern, May 1, 2019. Only current Code Tools > Committers [1] are eligible to vote on this nomination.? Votes must be > cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > -- Eric Caspole > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From victor.rudometov at oracle.com Wed Apr 17 17:15:19 2019 From: victor.rudometov at oracle.com (victor.rudometov at oracle.com) Date: Wed, 17 Apr 2019 10:15:19 -0700 Subject: CFV: New Code Tools Committer: Sergey Kuksenko In-Reply-To: <032a4727-5a6c-320e-256e-d4d883314b39@oracle.com> References: <032a4727-5a6c-320e-256e-d4d883314b39@oracle.com> Message-ID: <8e01519e-ef32-8643-35a9-c70eac83aed5@oracle.com> Vote: yes Victor On 4/17/19 09:12, eric.caspole at oracle.com wrote: > I hereby nominate Sergey Kuksenko to Code Tools Committer. > > Sergey has contributed 10 changesets to JMH and he was one of the > original developers of JMH before it was contributed into OpenJDK. > > He is also a JDK and Valhalla Committer. > > Votes are due by 1pm Eastern, May 1, 2019. Only current Code Tools > Committers [1] are eligible to vote on this nomination. Votes must be > cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > -- Eric Caspole > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From dmitry.bessonov at oracle.com Thu Apr 18 08:12:44 2019 From: dmitry.bessonov at oracle.com (dmitry.bessonov at oracle.com) Date: Thu, 18 Apr 2019 11:12:44 +0300 Subject: CFV: New Code Tools Committer: Sergey Kuksenko In-Reply-To: <032a4727-5a6c-320e-256e-d4d883314b39@oracle.com> References: <032a4727-5a6c-320e-256e-d4d883314b39@oracle.com> Message-ID: <26b200dc-6b4a-fc36-9819-041c21e4bbf9@oracle.com> Vote: yes dmitry On 17/04/2019 19:12, eric.caspole at oracle.com wrote: > I hereby nominate Sergey Kuksenko to Code Tools Committer. > > Sergey has contributed 10 changesets to JMH and he was one of the > original developers of JMH before it was contributed into OpenJDK. > > He is also a JDK and Valhalla Committer. > > Votes are due by 1pm Eastern, May 1, 2019. Only current Code Tools > Committers [1] are eligible to vote on this nomination.? Votes must be > cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > -- Eric Caspole > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From patrick at os.amperecomputing.com Tue Apr 23 09:58:50 2019 From: patrick at os.amperecomputing.com (Patrick Zhang OS) Date: Tue, 23 Apr 2019 09:58:50 +0000 Subject: RFR: CODETOOLS-7902453: Jtreg JDK.getJDKVersion failed to load GetSystemProperty.class when debugging Message-ID: Hi, I ran into an issue that jtreg reported that it cannot determine version for JDK when debugging, while the root cause is the root directory of class files could not be located correctly. There are a couple of methods to solve the problem (see details in JBS), the proposed one is to make com/sun/javatest/regtest/config/JDK.java not overwrite the CLASSPATH env var completely, update it with added paths instead. Please review, thanks. Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902453 Webrev: http://cr.openjdk.java.net/~qpzhang/codetools-7902453/webrev.01/ Regards Patrick From jonathan.gibbons at oracle.com Tue Apr 23 14:49:47 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 23 Apr 2019 07:49:47 -0700 Subject: RFR: CODETOOLS-7902453: Jtreg JDK.getJDKVersion failed to load GetSystemProperty.class when debugging In-Reply-To: References: Message-ID: <4aa20099-0321-a90a-c54c-cd634c62b0cf@oracle.com> Since sysPropClassPath is supposed to contain the path, and does not, it would be better to fix sysPropClassPath to contain the correct value. -- Jon On 4/23/19 2:58 AM, Patrick Zhang OS wrote: > Hi, > > I ran into an issue that jtreg reported that it cannot determine version for JDK when debugging, while the root cause is the root directory of class files could not be located correctly. There are a couple of methods to solve the problem (see details in JBS), the proposed one is to make com/sun/javatest/regtest/config/JDK.java not overwrite the CLASSPATH env var completely, update it with added paths instead. > Please review, thanks. > > Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902453 > Webrev: http://cr.openjdk.java.net/~qpzhang/codetools-7902453/webrev.01/ > > Regards > Patrick > From patrick at os.amperecomputing.com Wed Apr 24 07:46:10 2019 From: patrick at os.amperecomputing.com (Patrick Zhang OS) Date: Wed, 24 Apr 2019 07:46:10 +0000 Subject: RFR: CODETOOLS-7902453: Jtreg JDK.getJDKVersion failed to load GetSystemProperty.class when debugging In-Reply-To: <4aa20099-0321-a90a-c54c-cd634c62b0cf@oracle.com> References: <4aa20099-0321-a90a-c54c-cd634c62b0cf@oracle.com> Message-ID: Hi Jon, Thanks for your review. Please see my updates: http://cr.openjdk.java.net/~qpzhang/codetools-7902453/webrev.02. Instead of modifying sysPropClassPath directly, I changed JarFinder.getPath() a little bit: if the URI is not JAR, try the root path of class files. I would like to keep the fix for CLASSPATH, which should not be overwritten regardless. Maybe there were predefined values inside from users. Regards Patrick -----Original Message----- From: Jonathan Gibbons Sent: Tuesday, April 23, 2019 10:50 PM To: Patrick Zhang OS ; code-tools-dev at openjdk.java.net Subject: Re: RFR: CODETOOLS-7902453: Jtreg JDK.getJDKVersion failed to load GetSystemProperty.class when debugging Since sysPropClassPath is supposed to contain the path, and does not, it would be better to fix sysPropClassPath to contain the correct value. -- Jon On 4/23/19 2:58 AM, Patrick Zhang OS wrote: > Hi, > > I ran into an issue that jtreg reported that it cannot determine version for JDK when debugging, while the root cause is the root directory of class files could not be located correctly. There are a couple of methods to solve the problem (see details in JBS), the proposed one is to make com/sun/javatest/regtest/config/JDK.java not overwrite the CLASSPATH env var completely, update it with added paths instead. > Please review, thanks. > > Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902453 > Webrev: > http://cr.openjdk.java.net/~qpzhang/codetools-7902453/webrev.01/ > > Regards > Patrick > From jonathan.gibbons at oracle.com Wed Apr 24 17:54:01 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 24 Apr 2019 10:54:01 -0700 Subject: RFR: CODETOOLS-7902453: Jtreg JDK.getJDKVersion failed to load GetSystemProperty.class when debugging In-Reply-To: References: <4aa20099-0321-a90a-c54c-cd634c62b0cf@oracle.com> Message-ID: <013fd618-b5ad-bcf3-db22-77937684d512@oracle.com> > I would like to keep the fix for CLASSPATH, which should not be overwritten regardless. Maybe there were predefined values inside from users. That would be inappropriate, and against long-standing jtreg policy of being susceptible to the user's environment. -- Jon On 04/24/2019 12:46 AM, Patrick Zhang OS wrote: > Hi Jon, > Thanks for your review. > Please see my updates: http://cr.openjdk.java.net/~qpzhang/codetools-7902453/webrev.02. Instead of modifying sysPropClassPath directly, I changed JarFinder.getPath() a little bit: if the URI is not JAR, try the root path of class files. > I would like to keep the fix for CLASSPATH, which should not be overwritten regardless. Maybe there were predefined values inside from users. > > Regards > Patrick > > -----Original Message----- > From: Jonathan Gibbons > Sent: Tuesday, April 23, 2019 10:50 PM > To: Patrick Zhang OS ; code-tools-dev at openjdk.java.net > Subject: Re: RFR: CODETOOLS-7902453: Jtreg JDK.getJDKVersion failed to load GetSystemProperty.class when debugging > > Since sysPropClassPath is supposed to contain the path, and does not, it would be better to fix sysPropClassPath to contain the correct value. > > -- Jon > > On 4/23/19 2:58 AM, Patrick Zhang OS wrote: >> Hi, >> >> I ran into an issue that jtreg reported that it cannot determine version for JDK when debugging, while the root cause is the root directory of class files could not be located correctly. There are a couple of methods to solve the problem (see details in JBS), the proposed one is to make com/sun/javatest/regtest/config/JDK.java not overwrite the CLASSPATH env var completely, update it with added paths instead. >> Please review, thanks. >> >> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902453 >> Webrev: >> http://cr.openjdk.java.net/~qpzhang/codetools-7902453/webrev.01/ >> >> Regards >> Patrick >> From patrick at os.amperecomputing.com Thu Apr 25 02:28:53 2019 From: patrick at os.amperecomputing.com (Patrick Zhang OS) Date: Thu, 25 Apr 2019 02:28:53 +0000 Subject: RFR: CODETOOLS-7902453: Jtreg JDK.getJDKVersion failed to load GetSystemProperty.class when debugging In-Reply-To: <013fd618-b5ad-bcf3-db22-77937684d512@oracle.com> References: <4aa20099-0321-a90a-c54c-cd634c62b0cf@oracle.com> <013fd618-b5ad-bcf3-db22-77937684d512@oracle.com> Message-ID: > That would be inappropriate, and against long-standing jtreg policy of being susceptible to the user's environment. Fine, I was thinking the change at least would not make things worse, while it sounds CLASSPATH got intentionally cleared here, and cleanly written with the path of jtreg.jar and javatest.jar. Dropped that part, please review this update: http://cr.openjdk.java.net/~qpzhang/codetools-7902453/webrev.03, thanks. Regards Patrick -----Original Message----- From: Jonathan Gibbons Sent: Thursday, April 25, 2019 1:54 AM To: Patrick Zhang OS ; code-tools-dev at openjdk.java.net Subject: Re: RFR: CODETOOLS-7902453: Jtreg JDK.getJDKVersion failed to load GetSystemProperty.class when debugging > I would like to keep the fix for CLASSPATH, which should not be overwritten regardless. Maybe there were predefined values inside from users. That would be inappropriate, and against long-standing jtreg policy of being susceptible to the user's environment. -- Jon On 04/24/2019 12:46 AM, Patrick Zhang OS wrote: > Hi Jon, > Thanks for your review. > Please see my updates: http://cr.openjdk.java.net/~qpzhang/codetools-7902453/webrev.02. Instead of modifying sysPropClassPath directly, I changed JarFinder.getPath() a little bit: if the URI is not JAR, try the root path of class files. > I would like to keep the fix for CLASSPATH, which should not be overwritten regardless. Maybe there were predefined values inside from users. > > Regards > Patrick > > -----Original Message----- > From: Jonathan Gibbons > Sent: Tuesday, April 23, 2019 10:50 PM > To: Patrick Zhang OS ; > code-tools-dev at openjdk.java.net > Subject: Re: RFR: CODETOOLS-7902453: Jtreg JDK.getJDKVersion failed to > load GetSystemProperty.class when debugging > > Since sysPropClassPath is supposed to contain the path, and does not, it would be better to fix sysPropClassPath to contain the correct value. > > -- Jon > > On 4/23/19 2:58 AM, Patrick Zhang OS wrote: >> Hi, >> >> I ran into an issue that jtreg reported that it cannot determine version for JDK when debugging, while the root cause is the root directory of class files could not be located correctly. There are a couple of methods to solve the problem (see details in JBS), the proposed one is to make com/sun/javatest/regtest/config/JDK.java not overwrite the CLASSPATH env var completely, update it with added paths instead. >> Please review, thanks. >> >> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902453 >> Webrev: >> http://cr.openjdk.java.net/~qpzhang/codetools-7902453/webrev.01/ >> >> Regards >> Patrick >>