Integrated: JDK-8281001 Class::forName(String) defaults to system class loader if the caller is null

2022-06-08 Thread Tim Prinzing
On Sat, 14 May 2022 00:30:00 GMT, Tim Prinzing  wrote:

> The Class::forName behavior change to match JNI FindClass is a compatible 
> change and seems pretty attractive as it would be expected that 
> Class::forName would give the same behavior as FindClass which uses the 
> system classloader.  The test for 8281006 was enhanced to test for this 
> change.  Merged master to pick up fixes to unrelated test failures to reduce 
> noise.

This pull request has now been integrated.

Changeset: b92ce269
Author:Tim Prinzing 
Committer: Mandy Chung 
URL:   
https://git.openjdk.java.net/jdk/commit/b92ce2699b604cff638db583215863da8e253db8
Stats: 15 lines in 4 files changed: 8 ins; 3 del; 4 mod

8281001: Class::forName(String) defaults to system class loader if the caller 
is null

Reviewed-by: mchung

-

PR: https://git.openjdk.java.net/jdk/pull/8711


Re: RFR: JDK-8281001 Class::forName(String) defaults to system class loader if the caller is null [v6]

2022-06-08 Thread Tim Prinzing
> The Class::forName behavior change to match JNI FindClass is a compatible 
> change and seems pretty attractive as it would be expected that 
> Class::forName would give the same behavior as FindClass which uses the 
> system classloader.  The test for 8281006 was enhanced to test for this 
> change.  Merged master to pick up fixes to unrelated test failures to reduce 
> noise.

Tim Prinzing has updated the pull request incrementally with one additional 
commit since the last revision:

  append bug id being fixed rather than sorted insert

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8711/files
  - new: https://git.openjdk.java.net/jdk/pull/8711/files/3ce3a61a..95d7044d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=8711=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8711=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8711.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8711/head:pull/8711

PR: https://git.openjdk.java.net/jdk/pull/8711


Re: RFR: JDK-8281001 Class::forName(String) defaults to system class loader if the caller is null [v5]

2022-06-07 Thread Tim Prinzing
> The Class::forName behavior change to match JNI FindClass is a compatible 
> change and seems pretty attractive as it would be expected that 
> Class::forName would give the same behavior as FindClass which uses the 
> system classloader.  The test for 8281006 was enhanced to test for this 
> change.  Merged master to pick up fixes to unrelated test failures to reduce 
> noise.

Tim Prinzing has updated the pull request with a new target base due to a merge 
or a rebase. The pull request now contains eight commits:

 - formatting improvement
 - Merge branch 'master' into JDK-8281001
 - Fixed the build of the native c++ test NullCallerTest to specify
   the c++ std library as part of the build.  Changed the test to
   use iostream instead of printf.  Enabled the test for Class::forName
   which is now located in test/jdk/jni/nullCaller (as part of the
   merge of JDK-8287171).
 - Merge branch 'master' into JDK-8281001
 - make javadoc consistent with other caller sensitve methods
 - Added javadoc comment
 - Merge branch 'master' into JDK-8281001
 - JDK-8281001 Examine the behavior of Class::forName if the caller is null

-

Changes: https://git.openjdk.java.net/jdk/pull/8711/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8711=04
  Stats: 15 lines in 4 files changed: 8 ins; 3 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8711.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8711/head:pull/8711

PR: https://git.openjdk.java.net/jdk/pull/8711


Re: RFR: JDK-8281001 Examine the behavior of Class::forName if the caller is null [v4]

2022-06-02 Thread Tim Prinzing
> The Class::forName behavior change to match JNI FindClass is a compatible 
> change and seems pretty attractive as it would be expected that 
> Class::forName would give the same behavior as FindClass which uses the 
> system classloader.  The test for 8281006 was enhanced to test for this 
> change.  Merged master to pick up fixes to unrelated test failures to reduce 
> noise.

Tim Prinzing has updated the pull request with a new target base due to a merge 
or a rebase. The pull request now contains six commits:

 - Fixed the build of the native c++ test NullCallerTest to specify
   the c++ std library as part of the build.  Changed the test to
   use iostream instead of printf.  Enabled the test for Class::forName
   which is now located in test/jdk/jni/nullCaller (as part of the
   merge of JDK-8287171).
 - Merge branch 'master' into JDK-8281001
 - make javadoc consistent with other caller sensitve methods
 - Added javadoc comment
 - Merge branch 'master' into JDK-8281001
 - JDK-8281001 Examine the behavior of Class::forName if the caller is null

-

Changes: https://git.openjdk.java.net/jdk/pull/8711/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8711=03
  Stats: 19 lines in 5 files changed: 10 ins; 3 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8711.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8711/head:pull/8711

PR: https://git.openjdk.java.net/jdk/pull/8711


Integrated: 8287171: Refactor null caller tests to a single directory

2022-06-02 Thread Tim Prinzing
On Sat, 28 May 2022 11:50:19 GMT, Tim Prinzing  wrote:

> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates 
> a test module with some resources in it for the actual tests that occur at 
> the native level. The native part was switched to c++ instead of c to make it 
> easier to create helper objects that reduce the redundant code performing 
> error checking. The two helper classes InstanceCall and StaticCall were 
> placed in an include file called CallHelper.hpp. The main part of the tests 
> are in exeNullCallerTest.cpp, and there is a separate function for each of 
> the bug reports.

This pull request has now been integrated.

Changeset: e51ca1de
Author:Tim Prinzing 
Committer: Mandy Chung 
URL:   
https://git.openjdk.java.net/jdk/commit/e51ca1dee33d69c74f7f1dc2292db2f04c4ccf4c
Stats: 1303 lines in 19 files changed: 520 ins; 780 del; 3 mod

8287171: Refactor null caller tests to a single directory

Reviewed-by: ihse, mchung

-

PR: https://git.openjdk.java.net/jdk/pull/8934


Re: RFR: 8287171: Refactor null caller tests to a single directory [v8]

2022-06-01 Thread Tim Prinzing
> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates 
> a test module with some resources in it for the actual tests that occur at 
> the native level. The native part was switched to c++ instead of c to make it 
> easier to create helper objects that reduce the redundant code performing 
> error checking. The two helper classes InstanceCall and StaticCall were 
> placed in an include file called CallHelper.hpp. The main part of the tests 
> are in exeNullCallerTest.cpp, and there is a separate function for each of 
> the bug reports.

Tim Prinzing has updated the pull request incrementally with one additional 
commit since the last revision:

  comment changes

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8934/files
  - new: https://git.openjdk.java.net/jdk/pull/8934/files/865713fc..30fd6e27

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=8934=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8934=06-07

  Stats: 20 lines in 1 file changed: 14 ins; 4 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8934.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8934/head:pull/8934

PR: https://git.openjdk.java.net/jdk/pull/8934


Re: RFR: 8287171: Refactor null caller tests to a single directory [v7]

2022-06-01 Thread Tim Prinzing
> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates 
> a test module with some resources in it for the actual tests that occur at 
> the native level. The native part was switched to c++ instead of c to make it 
> easier to create helper objects that reduce the redundant code performing 
> error checking. The two helper classes InstanceCall and StaticCall were 
> placed in an include file called CallHelper.hpp. The main part of the tests 
> are in exeNullCallerTest.cpp, and there is a separate function for each of 
> the bug reports.

Tim Prinzing has updated the pull request incrementally with one additional 
commit since the last revision:

  formatting cleanup

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8934/files
  - new: https://git.openjdk.java.net/jdk/pull/8934/files/8bf4f597..865713fc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=8934=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8934=05-06

  Stats: 21 lines in 3 files changed: 2 ins; 10 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8934.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8934/head:pull/8934

PR: https://git.openjdk.java.net/jdk/pull/8934


Re: RFR: 8287171: Refactor null caller tests to a single directory [v6]

2022-05-31 Thread Tim Prinzing
> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates 
> a test module with some resources in it for the actual tests that occur at 
> the native level. The native part was switched to c++ instead of c to make it 
> easier to create helper objects that reduce the redundant code performing 
> error checking. The two helper classes InstanceCall and StaticCall were 
> placed in an include file called CallHelper.hpp. The main part of the tests 
> are in exeNullCallerTest.cpp, and there is a separate function for each of 
> the bug reports.

Tim Prinzing has updated the pull request incrementally with one additional 
commit since the last revision:

  move jni/nullCaller tests to jdk_lang group

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8934/files
  - new: https://git.openjdk.java.net/jdk/pull/8934/files/777c4f5f..8bf4f597

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=8934=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8934=04-05

  Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8934.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8934/head:pull/8934

PR: https://git.openjdk.java.net/jdk/pull/8934


Re: RFR: 8287171: Refactor null caller tests to a single directory [v5]

2022-05-31 Thread Tim Prinzing
On Wed, 1 Jun 2022 02:45:24 GMT, Tim Prinzing  wrote:

>> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates 
>> a test module with some resources in it for the actual tests that occur at 
>> the native level. The native part was switched to c++ instead of c to make 
>> it easier to create helper objects that reduce the redundant code performing 
>> error checking. The two helper classes InstanceCall and StaticCall were 
>> placed in an include file called CallHelper.hpp. The main part of the tests 
>> are in exeNullCallerTest.cpp, and there is a separate function for each of 
>> the bug reports.
>
> Tim Prinzing has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   improve comment

The tests are mostly java/lang, but also java/util so I was looking for 
something else.  The jdk_lang seems fairly reasonable and they run tier1 as the 
tests used to run before the move if I put them there.  I'll update TEST.groups.

-

PR: https://git.openjdk.java.net/jdk/pull/8934


Re: RFR: 8287171: Refactor null caller tests to a single directory [v5]

2022-05-31 Thread Tim Prinzing
> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates 
> a test module with some resources in it for the actual tests that occur at 
> the native level. The native part was switched to c++ instead of c to make it 
> easier to create helper objects that reduce the redundant code performing 
> error checking. The two helper classes InstanceCall and StaticCall were 
> placed in an include file called CallHelper.hpp. The main part of the tests 
> are in exeNullCallerTest.cpp, and there is a separate function for each of 
> the bug reports.

Tim Prinzing has updated the pull request incrementally with one additional 
commit since the last revision:

  improve comment

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8934/files
  - new: https://git.openjdk.java.net/jdk/pull/8934/files/7eb5dbcb..777c4f5f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=8934=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8934=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8934.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8934/head:pull/8934

PR: https://git.openjdk.java.net/jdk/pull/8934


Re: RFR: 8287171: Refactor null caller tests to a single directory [v4]

2022-05-31 Thread Tim Prinzing
> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates 
> a test module with some resources in it for the actual tests that occur at 
> the native level. The native part was switched to c++ instead of c to make it 
> easier to create helper objects that reduce the redundant code performing 
> error checking. The two helper classes InstanceCall and StaticCall were 
> placed in an include file called CallHelper.hpp. The main part of the tests 
> are in exeNullCallerTest.cpp, and there is a separate function for each of 
> the bug reports.

Tim Prinzing has updated the pull request incrementally with one additional 
commit since the last revision:

  Moved the tests test/jdk/jni/nullCaller.  Added to the jdk_other group
  which runs as part of tier2.  Made the other requested changes such as
  not using the bugid as the function name for the test and using the
  name of the main method being tested instead.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8934/files
  - new: https://git.openjdk.java.net/jdk/pull/8934/files/f1406a45..7eb5dbcb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=8934=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8934=02-03

  Stats: 13 lines in 10 files changed: 1 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8934.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8934/head:pull/8934

PR: https://git.openjdk.java.net/jdk/pull/8934


Re: RFR: 8287171: Refactor null caller tests to a single directory [v3]

2022-05-29 Thread Tim Prinzing
> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates 
> a test module with some resources in it for the actual tests that occur at 
> the native level. The native part was switched to c++ instead of c to make it 
> easier to create helper objects that reduce the redundant code performing 
> error checking. The two helper classes InstanceCall and StaticCall were 
> placed in an include file called CallHelper.hpp. The main part of the tests 
> are in exeNullCallerTest.cpp, and there is a separate function for each of 
> the bug reports.

Tim Prinzing has updated the pull request incrementally with one additional 
commit since the last revision:

  problem with iostream on Windows, use printf

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8934/files
  - new: https://git.openjdk.java.net/jdk/pull/8934/files/a54aa747..f1406a45

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=8934=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8934=01-02

  Stats: 14 lines in 2 files changed: 8 ins; 2 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8934.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8934/head:pull/8934

PR: https://git.openjdk.java.net/jdk/pull/8934


Re: RFR: 8287171: Refactor null caller tests to a single directory [v2]

2022-05-29 Thread Tim Prinzing
> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates 
> a test module with some resources in it for the actual tests that occur at 
> the native level. The native part was switched to c++ instead of c to make it 
> easier to create helper objects that reduce the redundant code performing 
> error checking. The two helper classes InstanceCall and StaticCall were 
> placed in an include file called CallHelper.hpp. The main part of the tests 
> are in exeNullCallerTest.cpp, and there is a separate function for each of 
> the bug reports.

Tim Prinzing has updated the pull request with a new target base due to a merge 
or a rebase. The incremental webrev excludes the unrelated changes brought in 
by the merge/rebase. The pull request contains two additional commits since the 
last revision:

 - Merge branch 'master' into JDK-8287171
 - 8287171: Refactor null caller tests to a single directory

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8934/files
  - new: https://git.openjdk.java.net/jdk/pull/8934/files/5eba965b..a54aa747

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=8934=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8934=00-01

  Stats: 2803 lines in 65 files changed: 1631 ins; 617 del; 555 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8934.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8934/head:pull/8934

PR: https://git.openjdk.java.net/jdk/pull/8934


RFR: 8287171: Refactor null caller tests to a single directory

2022-05-28 Thread Tim Prinzing
Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a 
test module with some resources in it for the actual tests that occur at the 
native level. The native part was switched to c++ instead of c to make it 
easier to create helper objects that reduce the redundant code performing error 
checking. The two helper classes InstanceCall and StaticCall were placed in an 
include file called CallHelper.hpp. The main part of the tests are in 
exeNullCallerTest.cpp, and there is a separate function for each of the bug 
reports.

-

Commit messages:
 - 8287171: Refactor null caller tests to a single directory

Changes: https://git.openjdk.java.net/jdk/pull/8934/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8934=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287171
  Stats: 1293 lines in 18 files changed: 511 ins; 780 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8934.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8934/head:pull/8934

PR: https://git.openjdk.java.net/jdk/pull/8934


Re: RFR: JDK-8281001 Examine the behavior of Class::forName if the caller is null [v3]

2022-05-26 Thread Tim Prinzing
> The Class::forName behavior change to match JNI FindClass is a compatible 
> change and seems pretty attractive as it would be expected that 
> Class::forName would give the same behavior as FindClass which uses the 
> system classloader.  The test for 8281006 was enhanced to test for this 
> change.  Merged master to pick up fixes to unrelated test failures to reduce 
> noise.

Tim Prinzing has updated the pull request incrementally with one additional 
commit since the last revision:

  make javadoc consistent with other caller sensitve methods

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8711/files
  - new: https://git.openjdk.java.net/jdk/pull/8711/files/9d054ea6..4e5f8c2b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=8711=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8711=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8711.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8711/head:pull/8711

PR: https://git.openjdk.java.net/jdk/pull/8711


Re: RFR: JDK-8281001 Examine the behavior of Class::forName if the caller is null [v2]

2022-05-17 Thread Tim Prinzing
> The Class::forName behavior change to match JNI FindClass is a compatible 
> change and seems pretty attractive as it would be expected that 
> Class::forName would give the same behavior as FindClass which uses the 
> system classloader.  The test for 8281006 was enhanced to test for this 
> change.  Merged master to pick up fixes to unrelated test failures to reduce 
> noise.

Tim Prinzing has updated the pull request incrementally with one additional 
commit since the last revision:

  Added javadoc comment

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8711/files
  - new: https://git.openjdk.java.net/jdk/pull/8711/files/5b10f0d2..9d054ea6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=8711=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8711=00-01

  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8711.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8711/head:pull/8711

PR: https://git.openjdk.java.net/jdk/pull/8711


Re: RFR: JDK-8281001 Examine the behavior of Class::forName if the caller is null

2022-05-17 Thread Tim Prinzing
On Mon, 16 May 2022 18:55:42 GMT, Mandy Chung  wrote:

> `Class::forName(String)` javadoc should specify which class loader to use 
> when invoked with null caller similar to the other APIs you fixed for null 
> callers.
> 
> I think this new test case does not belong to `NullCallerGetResource.java` 
> which is a test for `Module::getResource`. It's better to be placed under the 
> `test/jdk/java/lang/Class/forName` directory that makes it clear it's a test 
> for `Class::forName`.
> 
> Alternatively, we could move all the tests for null caller under a new 
> clearly-named directory, maybe `test/jdk/jdk/nullCaller`. This may allow to 
> do some refactoring and remove the duplicated code in these test cases. What 
> do you think?

I like the idea of moving all the null caller tests to a clearly named 
directory to avoid duplication.

-

PR: https://git.openjdk.java.net/jdk/pull/8711


RFR: JDK-8281001 Examine the behavior of Class::forName if the caller is null

2022-05-13 Thread Tim Prinzing
The Class::forName behavior change to match JNI FindClass is a compatible 
change and seems pretty attractive as it would be expected that Class::forName 
would give the same behavior as FindClass which uses the system classloader.  
The test for 8281006 was enhanced to test for this change.  Merged master to 
pick up fixes to unrelated test failures to reduce noise.

-

Commit messages:
 - Merge branch 'master' into JDK-8281001
 - JDK-8281001 Examine the behavior of Class::forName if the caller is null

Changes: https://git.openjdk.java.net/jdk/pull/8711/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8711=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281001
  Stats: 19 lines in 3 files changed: 18 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8711.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8711/head:pull/8711

PR: https://git.openjdk.java.net/jdk/pull/8711


Integrated: JDK-8281006 Module::getResourceAsStream should check if the resource is open unconditionally when caller is null

2022-04-20 Thread Tim Prinzing
On Thu, 7 Apr 2022 00:38:07 GMT, Tim Prinzing  wrote:

> Created a test called NullCallerGetResource to test 
> Module::getResourceAsStream and Class::getResourceAsStream from the native 
> level.
> 
> At the java level the test builds a test module called 'n' which opens the 
> package 'open' to everyone. There is also a package 'closed' which is neither 
> opened or exported. Both packages have a text file called 'test.txt'. The 
> open package has a class called OpenResources and the closed package has a 
> class called ClosedResources. The native test is launched with the test 
> module n added.
> 
> At the native level the test tries to read both the open and closed resource 
> from both the classes and the module. It performs the equivalent of the 
> following java operations:
> 
> Class c = open.OpenResources.fetchClass();
> InputStream in = c.getResourceAsStream("test.txt");
> assert(in != null); in.close();
> 
> Module n = c.getModule();
> in = n.getResourceAsStream("open/test.txt");
> assert(in != null); in.close();
> 
> Class closed = closed.ClosedResources.fetchClass();
> assert(closedsStream("test.txt") == null);
> assert(n.getResourceAsStream("closed/test.txt") == null);
> 
> The test initially threw an NPE when trying to fetch the open resource. The 
> Module class was fixed by removing the fragment with the (caller == null) 
> test in getResourceAsStream, and changing the call to isOpen(String,Module) 
> to use EVERYONE_MODULE if the caller module is null.

This pull request has now been integrated.

Changeset: e8016f74
Author:Tim Prinzing 
Committer: Mandy Chung 
URL:   
https://git.openjdk.java.net/jdk/commit/e8016f74438ca5c64a8aab81e2fc2533e9b9f8ad
Stats: 393 lines in 8 files changed: 385 ins; 0 del; 8 mod

8281006: Module::getResourceAsStream should check if the resource is open 
unconditionally when caller is null

Reviewed-by: alanb, erikj, mchung

-

PR: https://git.openjdk.java.net/jdk/pull/8134


Re: RFR: JDK-8281006 Module::getResourceAsStream should check if the resource is open unconditionally when caller is null [v5]

2022-04-19 Thread Tim Prinzing
> Created a test called NullCallerGetResource to test 
> Module::getResourceAsStream and Class::getResourceAsStream from the native 
> level.
> 
> At the java level the test builds a test module called 'n' which opens the 
> package 'open' to everyone. There is also a package 'closed' which is neither 
> opened or exported. Both packages have a text file called 'test.txt'. The 
> open package has a class called OpenResources and the closed package has a 
> class called ClosedResources. The native test is launched with the test 
> module n added.
> 
> At the native level the test tries to read both the open and closed resource 
> from both the classes and the module. It performs the equivalent of the 
> following java operations:
> 
> Class c = open.OpenResources.fetchClass();
> InputStream in = c.getResourceAsStream("test.txt");
> assert(in != null); in.close();
> 
> Module n = c.getModule();
> in = n.getResourceAsStream("open/test.txt");
> assert(in != null); in.close();
> 
> Class closed = closed.ClosedResources.fetchClass();
> assert(closedsStream("test.txt") == null);
> assert(n.getResourceAsStream("closed/test.txt") == null);
> 
> The test initially threw an NPE when trying to fetch the open resource. The 
> Module class was fixed by removing the fragment with the (caller == null) 
> test in getResourceAsStream, and changing the call to isOpen(String,Module) 
> to use EVERYONE_MODULE if the caller module is null.

Tim Prinzing has updated the pull request incrementally with one additional 
commit since the last revision:

  some cleanup of the test

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8134/files
  - new: https://git.openjdk.java.net/jdk/pull/8134/files/c5fef46b..15de2394

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=8134=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8134=03-04

  Stats: 62 lines in 4 files changed: 21 ins; 27 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8134.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8134/head:pull/8134

PR: https://git.openjdk.java.net/jdk/pull/8134


Re: RFR: JDK-8281006 Module::getResourceAsStream should check if the resource is open unconditionally when caller is null [v4]

2022-04-10 Thread Tim Prinzing
> Created a test called NullCallerGetResource to test 
> Module::getResourceAsStream and Class::getResourceAsStream from the native 
> level.
> 
> At the java level the test builds a test module called 'n' which opens the 
> package 'open' to everyone. There is also a package 'closed' which is neither 
> opened or exported. Both packages have a text file called 'test.txt'. The 
> open package has a class called OpenResources and the closed package has a 
> class called ClosedResources. The native test is launched with the test 
> module n added.
> 
> At the native level the test tries to read both the open and closed resource 
> from both the classes and the module. It performs the equivalent of the 
> following java operations:
> 
> Class c = open.OpenResources.fetchClass();
> InputStream in = c.getResourceAsStream("test.txt");
> assert(in != null); in.close();
> 
> Module n = c.getModule();
> in = n.getResourceAsStream("open/test.txt");
> assert(in != null); in.close();
> 
> Class closed = closed.ClosedResources.fetchClass();
> assert(closedsStream("test.txt") == null);
> assert(n.getResourceAsStream("closed/test.txt") == null);
> 
> The test initially threw an NPE when trying to fetch the open resource. The 
> Module class was fixed by removing the fragment with the (caller == null) 
> test in getResourceAsStream, and changing the call to isOpen(String,Module) 
> to use EVERYONE_MODULE if the caller module is null.

Tim Prinzing has updated the pull request incrementally with one additional 
commit since the last revision:

  requested changes

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8134/files
  - new: https://git.openjdk.java.net/jdk/pull/8134/files/912896d7..c5fef46b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=8134=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8134=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8134.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8134/head:pull/8134

PR: https://git.openjdk.java.net/jdk/pull/8134


Re: RFR: JDK-8281006 Module::getResourceAsStream should check if the resource is open unconditionally when caller is null [v3]

2022-04-07 Thread Tim Prinzing
> Created a test called NullCallerGetResource to test 
> Module::getResourceAsStream and Class::getResourceAsStream from the native 
> level.
> 
> At the java level the test builds a test module called 'n' which opens the 
> package 'open' to everyone. There is also a package 'closed' which is neither 
> opened or exported. Both packages have a text file called 'test.txt'. The 
> open package has a class called OpenResources and the closed package has a 
> class called ClosedResources. The native test is launched with the test 
> module n added.
> 
> At the native level the test tries to read both the open and closed resource 
> from both the classes and the module. It performs the equivalent of the 
> following java operations:
> 
> Class c = open.OpenResources.fetchClass();
> InputStream in = c.getResourceAsStream("test.txt");
> assert(in != null); in.close();
> 
> Module n = c.getModule();
> in = n.getResourceAsStream("open/test.txt");
> assert(in != null); in.close();
> 
> Class closed = closed.ClosedResources.fetchClass();
> assert(closedsStream("test.txt") == null);
> assert(n.getResourceAsStream("closed/test.txt") == null);
> 
> The test initially threw an NPE when trying to fetch the open resource. The 
> Module class was fixed by removing the fragment with the (caller == null) 
> test in getResourceAsStream, and changing the call to isOpen(String,Module) 
> to use EVERYONE_MODULE if the caller module is null.

Tim Prinzing has updated the pull request incrementally with one additional 
commit since the last revision:

  revert Module::isOpen

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8134/files
  - new: https://git.openjdk.java.net/jdk/pull/8134/files/4b344e4d..912896d7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=8134=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8134=01-02

  Stats: 10 lines in 2 files changed: 5 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8134.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8134/head:pull/8134

PR: https://git.openjdk.java.net/jdk/pull/8134


Re: RFR: JDK-8281006 Module::getResourceAsStream should check if the resource is open unconditionally when caller is null [v2]

2022-04-07 Thread Tim Prinzing
On Thu, 7 Apr 2022 05:52:24 GMT, Alan Bateman  wrote:

> Tim - this creates a conflict between the spec and implementation, the 
> changes to the 2-arg isOpen method need to be dropped so that it continues to 
> throw NPE if module is null.

okay

-

PR: https://git.openjdk.java.net/jdk/pull/8134


Re: RFR: JDK-8281006 Module::getResourceAsStream should check if the resource is open unconditionally when caller is null [v2]

2022-04-06 Thread Tim Prinzing
> Created a test called NullCallerGetResource to test 
> Module::getResourceAsStream and Class::getResourceAsStream from the native 
> level.
> 
> At the java level the test builds a test module called 'n' which opens the 
> package 'open' to everyone. There is also a package 'closed' which is neither 
> opened or exported. Both packages have a text file called 'test.txt'. The 
> open package has a class called OpenResources and the closed package has a 
> class called ClosedResources. The native test is launched with the test 
> module n added.
> 
> At the native level the test tries to read both the open and closed resource 
> from both the classes and the module. It performs the equivalent of the 
> following java operations:
> 
> Class c = open.OpenResources.fetchClass();
> InputStream in = c.getResourceAsStream("test.txt");
> assert(in != null); in.close();
> 
> Module n = c.getModule();
> in = n.getResourceAsStream("open/test.txt");
> assert(in != null); in.close();
> 
> Class closed = closed.ClosedResources.fetchClass();
> assert(closedsStream("test.txt") == null);
> assert(n.getResourceAsStream("closed/test.txt") == null);
> 
> The test initially threw an NPE when trying to fetch the open resource. The 
> Module class was fixed by removing the fragment with the (caller == null) 
> test in getResourceAsStream, and changing the call to isOpen(String,Module) 
> to use EVERYONE_MODULE if the caller module is null.

Tim Prinzing has updated the pull request incrementally with one additional 
commit since the last revision:

  update copyright date

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8134/files
  - new: https://git.openjdk.java.net/jdk/pull/8134/files/b702cae4..4b344e4d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=8134=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8134=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8134.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8134/head:pull/8134

PR: https://git.openjdk.java.net/jdk/pull/8134


RFR: JDK-8281006 Module::getResourceAsStream should check if the resource is open unconditionally when caller is null

2022-04-06 Thread Tim Prinzing
Created a test called NullCallerGetResource to test Module::getResourceAsStream 
and Class::getResourceAsStream from the native level.

At the java level the test builds a test module called 'n' which opens the 
package 'open' to everyone. There is also a package 'closed' which is neither 
opened or exported. Both packages have a text file called 'test.txt'. The open 
package has a class called OpenResources and the closed package has a class 
called ClosedResources. The native test is launched with the test module n 
added.

At the native level the test tries to read both the open and closed resource 
from both the classes and the module. It performs the equivalent of the 
following java operations:

Class c = open.OpenResources.fetchClass();
InputStream in = c.getResourceAsStream("test.txt");
assert(in != null); in.close();

Module n = c.getModule();
in = n.getResourceAsStream("open/test.txt");
assert(in != null); in.close();

Class closed = closed.ClosedResources.fetchClass();
assert(closedsStream("test.txt") == null);
assert(n.getResourceAsStream("closed/test.txt") == null);

The test initially threw an NPE when trying to fetch the open resource. The 
Module class was fixed by removing the fragment with the (caller == null) test 
in getResourceAsStream, and changing the call to isOpen(String,Module) to use 
EVERYONE_MODULE if the caller module is null.

-

Commit messages:
 - JDK-8281006 Module::getResourceAsStream should check if the resource is open 
unconditionally when caller is null

Changes: https://git.openjdk.java.net/jdk/pull/8134/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8134=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281006
  Stats: 397 lines in 7 files changed: 391 ins; 5 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8134.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8134/head:pull/8134

PR: https://git.openjdk.java.net/jdk/pull/8134


Integrated: JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame

2022-03-08 Thread Tim Prinzing
On Wed, 2 Mar 2022 18:56:40 GMT, Tim Prinzing  wrote:

> The caller class returned by Reflection::getCallerClass was used to gain 
> access to it's module in most cases and class loader in one case. I added a 
> method to translate the caller class to caller module so that the decision of 
> what module represents the caller with no stack frame is made in a single 
> place. Calls made to caller.getModule() were replaced with 
> getCallerModule(caller) which returns the system class loader unnamed module 
> if the caller is null.
> 
> The one place a class loader was produced from the caller in getBundleImpl it 
> was rewritten to route through the getCallerModule method:
> 
> final ClassLoader loader = (caller != null) ?
> caller.getClassLoader() : getLoader(getCallerModule(caller));
> 
> A JNI test was added which calls getBundle to fetch a test bundle from a 
> location added to the classpath, fetches a string out of the bundle and 
> verifies it, and calls clearCache.
> 
> The javadoc was updated for the caller sensitive methods changed.

This pull request has now been integrated.

Changeset: 31ad80a2
Author:Tim Prinzing 
Committer: Mandy Chung 
URL:   
https://git.openjdk.java.net/jdk/commit/31ad80a229e3f67823ff8f1fc914c5503f184b57
Stats: 218 lines in 4 files changed: 207 ins; 3 del; 8 mod

8280902: ResourceBundle::getBundle may throw NPE when invoked by JNI code with 
no caller frame

Reviewed-by: naoto, mchung, ihse

-

PR: https://git.openjdk.java.net/jdk/pull/7663


Re: RFR: JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame [v5]

2022-03-08 Thread Tim Prinzing
> The caller class returned by Reflection::getCallerClass was used to gain 
> access to it's module in most cases and class loader in one case. I added a 
> method to translate the caller class to caller module so that the decision of 
> what module represents the caller with no stack frame is made in a single 
> place. Calls made to caller.getModule() were replaced with 
> getCallerModule(caller) which returns the system class loader unnamed module 
> if the caller is null.
> 
> The one place a class loader was produced from the caller in getBundleImpl it 
> was rewritten to route through the getCallerModule method:
> 
> final ClassLoader loader = (caller != null) ?
> caller.getClassLoader() : getLoader(getCallerModule(caller));
> 
> A JNI test was added which calls getBundle to fetch a test bundle from a 
> location added to the classpath, fetches a string out of the bundle and 
> verifies it, and calls clearCache.
> 
> The javadoc was updated for the caller sensitive methods changed.

Tim Prinzing has updated the pull request with a new target base due to a merge 
or a rebase. The incremental webrev excludes the unrelated changes brought in 
by the merge/rebase. The pull request contains seven additional commits since 
the last revision:

 - Merge branch 'master' into JDK-8280902
 - remove unnecessary variable
 - more suggested changes
 - suggested changes
 - Update src/java.base/share/classes/java/util/ResourceBundle.java
   
   Co-authored-by: Mandy Chung 
 - Use the unnamed module defined to the system class loader instead of the
   boot class loader.
 - JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code 
with no caller frame

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7663/files
  - new: https://git.openjdk.java.net/jdk/pull/7663/files/45f9b37b..6600e1f5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7663=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7663=03-04

  Stats: 17900 lines in 516 files changed: 12667 ins; 3251 del; 1982 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7663.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7663/head:pull/7663

PR: https://git.openjdk.java.net/jdk/pull/7663


Re: RFR: JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame [v4]

2022-03-03 Thread Tim Prinzing
> The caller class returned by Reflection::getCallerClass was used to gain 
> access to it's module in most cases and class loader in one case. I added a 
> method to translate the caller class to caller module so that the decision of 
> what module represents the caller with no stack frame is made in a single 
> place. Calls made to caller.getModule() were replaced with 
> getCallerModule(caller) which returns the system class loader unnamed module 
> if the caller is null.
> 
> The one place a class loader was produced from the caller in getBundleImpl it 
> was rewritten to route through the getCallerModule method:
> 
> final ClassLoader loader = (caller != null) ?
> caller.getClassLoader() : getLoader(getCallerModule(caller));
> 
> A JNI test was added which calls getBundle to fetch a test bundle from a 
> location added to the classpath, fetches a string out of the bundle and 
> verifies it, and calls clearCache.
> 
> The javadoc was updated for the caller sensitive methods changed.

Tim Prinzing has updated the pull request incrementally with one additional 
commit since the last revision:

  more suggested changes

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7663/files
  - new: https://git.openjdk.java.net/jdk/pull/7663/files/eeb2d0fa..45f9b37b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7663=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7663=02-03

  Stats: 31 lines in 2 files changed: 2 ins; 13 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7663.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7663/head:pull/7663

PR: https://git.openjdk.java.net/jdk/pull/7663


Re: RFR: JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame [v3]

2022-03-03 Thread Tim Prinzing
On Wed, 2 Mar 2022 22:21:03 GMT, Mandy Chung  wrote:

>> Tim Prinzing has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   suggested changes
>
> test/jdk/java/util/ResourceBundle/exeNullCallerResourceBundle/exeNullCallerResourceBundle.c
>  line 28:
> 
>> 26: 
>> 27: #include "jni.h"
>> 28: #undef NDEBUG
> 
> is this line unintended?

Forcing the assert() seems like a good idea in a test

-

PR: https://git.openjdk.java.net/jdk/pull/7663


Re: RFR: JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame [v3]

2022-03-02 Thread Tim Prinzing
> The caller class returned by Reflection::getCallerClass was used to gain 
> access to it's module in most cases and class loader in one case. I added a 
> method to translate the caller class to caller module so that the decision of 
> what module represents the caller with no stack frame is made in a single 
> place. Calls made to caller.getModule() were replaced with 
> getCallerModule(caller) which returns the system class loader unnamed module 
> if the caller is null.
> 
> The one place a class loader was produced from the caller in getBundleImpl it 
> was rewritten to route through the getCallerModule method:
> 
> final ClassLoader loader = (caller != null) ?
> caller.getClassLoader() : getLoader(getCallerModule(caller));
> 
> A JNI test was added which calls getBundle to fetch a test bundle from a 
> location added to the classpath, fetches a string out of the bundle and 
> verifies it, and calls clearCache.
> 
> The javadoc was updated for the caller sensitive methods changed.

Tim Prinzing has updated the pull request incrementally with one additional 
commit since the last revision:

  suggested changes

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7663/files
  - new: https://git.openjdk.java.net/jdk/pull/7663/files/9e8fb193..eeb2d0fa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7663=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7663=01-02

  Stats: 48 lines in 1 file changed: 6 ins; 41 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7663.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7663/head:pull/7663

PR: https://git.openjdk.java.net/jdk/pull/7663


Re: RFR: JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame [v2]

2022-03-02 Thread Tim Prinzing
> The caller class returned by Reflection::getCallerClass was used to gain 
> access to it's module in most cases and class loader in one case. I added a 
> method to translate the caller class to caller module so that the decision of 
> what module represents the caller with no stack frame is made in a single 
> place. Calls made to caller.getModule() were replaced with 
> getCallerModule(caller) which returns the system class loader unnamed module 
> if the caller is null.
> 
> The one place a class loader was produced from the caller in getBundleImpl it 
> was rewritten to route through the getCallerModule method:
> 
> final ClassLoader loader = (caller != null) ?
> caller.getClassLoader() : getLoader(getCallerModule(caller));
> 
> A JNI test was added which calls getBundle to fetch a test bundle from a 
> location added to the classpath, fetches a string out of the bundle and 
> verifies it, and calls clearCache.
> 
> The javadoc was updated for the caller sensitive methods changed.

Tim Prinzing has updated the pull request incrementally with one additional 
commit since the last revision:

  Update src/java.base/share/classes/java/util/ResourceBundle.java
  
  Co-authored-by: Mandy Chung 

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7663/files
  - new: https://git.openjdk.java.net/jdk/pull/7663/files/30778063..9e8fb193

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7663=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7663=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7663.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7663/head:pull/7663

PR: https://git.openjdk.java.net/jdk/pull/7663


RFR: JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame

2022-03-02 Thread Tim Prinzing
The caller class returned by Reflection::getCallerClass was used to gain access 
to it's module in most cases and class loader in one case. I added a method to 
translate the caller class to caller module so that the decision of what module 
represents the caller with no stack frame is made in a single place. Calls made 
to caller.getModule() were replaced with getCallerModule(caller) which returns 
the system class loader unnamed module if the caller is null.

The one place a class loader was produced from the caller in getBundleImpl it 
was rewritten to route through the getCallerModule method:

final ClassLoader loader = (caller != null) ?
caller.getClassLoader() : getLoader(getCallerModule(caller));

A JNI test was added which calls getBundle to fetch a test bundle from a 
location added to the classpath, fetches a string out of the bundle and 
verifies it, and calls clearCache.

The javadoc was updated for the caller sensitive methods changed.

-

Commit messages:
 - Use the unnamed module defined to the system class loader instead of the
 - JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code 
with no caller frame

Changes: https://git.openjdk.java.net/jdk/pull/7663/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7663=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280902
  Stats: 265 lines in 4 files changed: 254 ins; 3 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7663.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7663/head:pull/7663

PR: https://git.openjdk.java.net/jdk/pull/7663


Integrated: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null

2022-02-17 Thread Tim Prinzing
On Fri, 11 Feb 2022 20:36:26 GMT, Tim Prinzing  wrote:

> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is 
> null

This pull request has now been integrated.

Changeset: a6f8a386
Author:    Tim Prinzing 
Committer: Mandy Chung 
URL:   
https://git.openjdk.java.net/jdk/commit/a6f8a386efa7af162f4b815951287f0a9bc1f396
Stats: 216 lines in 5 files changed: 216 ins; 0 del; 0 mod

8281000: ClassLoader::registerAsParallelCapable throws NPE if caller is null

Reviewed-by: erikj, ihse, mchung, bchristi

-

PR: https://git.openjdk.java.net/jdk/pull/7448


Re: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null [v7]

2022-02-16 Thread Tim Prinzing
> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is 
> null

Tim Prinzing has updated the pull request with a new target base due to a merge 
or a rebase. The pull request now contains 10 commits:

 - Merge master
 - fix test breakage from rename
 - reformat test summary
 - reformat test summary
 - improve test name and remove experimental test code
 - fix copyright date
 - More changes from feedback.
   
   The javadoc is improved to reflect InvalidCallerException is thrown with
   a caller that can't be assigned to a ClassLoader as well as a null
   caller frame.  Added a test IsParallelCapableBadCaller that uses
   reflection hackery to create a case where called with an invalid caller
   on the call stack.
 - Changes from feedback.
   
   - Copyright dates fixed
   - IllegalCallerException thrown for no caller frame, and associated
   javadoc changes
   - test changed to look for IllegalCallerException thrown.
 - Merge branch 'master' into JDK-8281000
 - JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is 
null

-

Changes: https://git.openjdk.java.net/jdk/pull/7448/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7448=06
  Stats: 216 lines in 5 files changed: 216 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7448.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7448/head:pull/7448

PR: https://git.openjdk.java.net/jdk/pull/7448


Re: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null [v6]

2022-02-16 Thread Tim Prinzing
> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is 
> null

Tim Prinzing has updated the pull request incrementally with one additional 
commit since the last revision:

  fix test breakage from rename

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7448/files
  - new: https://git.openjdk.java.net/jdk/pull/7448/files/a449acdc..977162db

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7448=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7448=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7448.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7448/head:pull/7448

PR: https://git.openjdk.java.net/jdk/pull/7448


Integrated: JDK-8281003 - MethodHandles::lookup throws NPE if caller is null

2022-02-16 Thread Tim Prinzing
On Fri, 11 Feb 2022 20:32:46 GMT, Tim Prinzing  wrote:

> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null

This pull request has now been integrated.

Changeset: 67763df4
Author:    Tim Prinzing 
Committer: Mandy Chung 
URL:   
https://git.openjdk.java.net/jdk/commit/67763df4dce387da33da6d93d0f5d80e54cf8e5b
Stats: 160 lines in 4 files changed: 158 ins; 0 del; 2 mod

8281003: MethodHandles::lookup throws NPE if caller is null

Reviewed-by: ihse, mchung, jrose, alanb

-

PR: https://git.openjdk.java.net/jdk/pull/7447


Re: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null [v5]

2022-02-16 Thread Tim Prinzing
> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is 
> null

Tim Prinzing has updated the pull request incrementally with three additional 
commits since the last revision:

 - reformat test summary
 - reformat test summary
 - improve test name and remove experimental test code

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7448/files
  - new: https://git.openjdk.java.net/jdk/pull/7448/files/533a0660..a449acdc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7448=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7448=03-04

  Stats: 129 lines in 3 files changed: 58 ins; 70 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7448.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7448/head:pull/7448

PR: https://git.openjdk.java.net/jdk/pull/7448


Re: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is null [v5]

2022-02-16 Thread Tim Prinzing
> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null

Tim Prinzing has updated the pull request incrementally with one additional 
commit since the last revision:

  fix copyright date

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7447/files
  - new: https://git.openjdk.java.net/jdk/pull/7447/files/7d1b97fe..ecfd125f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7447=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7447=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7447.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7447/head:pull/7447

PR: https://git.openjdk.java.net/jdk/pull/7447


Re: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null [v4]

2022-02-16 Thread Tim Prinzing
> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is 
> null

Tim Prinzing has updated the pull request incrementally with one additional 
commit since the last revision:

  fix copyright date

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7448/files
  - new: https://git.openjdk.java.net/jdk/pull/7448/files/d67bbb16..533a0660

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7448=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7448=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7448.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7448/head:pull/7448

PR: https://git.openjdk.java.net/jdk/pull/7448


Re: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null [v3]

2022-02-16 Thread Tim Prinzing
> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is 
> null

Tim Prinzing has updated the pull request incrementally with one additional 
commit since the last revision:

  More changes from feedback.
  
  The javadoc is improved to reflect InvalidCallerException is thrown with
  a caller that can't be assigned to a ClassLoader as well as a null
  caller frame.  Added a test IsParallelCapableBadCaller that uses
  reflection hackery to create a case where called with an invalid caller
  on the call stack.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7448/files
  - new: https://git.openjdk.java.net/jdk/pull/7448/files/fa66af15..d67bbb16

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7448=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7448=01-02

  Stats: 85 lines in 3 files changed: 74 ins; 5 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7448.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7448/head:pull/7448

PR: https://git.openjdk.java.net/jdk/pull/7448


Re: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null [v2]

2022-02-15 Thread Tim Prinzing
> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is 
> null

Tim Prinzing has updated the pull request incrementally with one additional 
commit since the last revision:

  Changes from feedback.
  
  - Copyright dates fixed
  - IllegalCallerException thrown for no caller frame, and associated
  javadoc changes
  - test changed to look for IllegalCallerException thrown.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7448/files
  - new: https://git.openjdk.java.net/jdk/pull/7448/files/c6d37069..fa66af15

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7448=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7448=00-01

  Stats: 33 lines in 3 files changed: 22 ins; 2 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7448.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7448/head:pull/7448

PR: https://git.openjdk.java.net/jdk/pull/7448


Re: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is null [v4]

2022-02-14 Thread Tim Prinzing
> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null

Tim Prinzing has updated the pull request incrementally with one additional 
commit since the last revision:

  remove excess description

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7447/files
  - new: https://git.openjdk.java.net/jdk/pull/7447/files/c803a93b..7d1b97fe

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7447=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7447=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7447.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7447/head:pull/7447

PR: https://git.openjdk.java.net/jdk/pull/7447


Re: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is null [v3]

2022-02-14 Thread Tim Prinzing
> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null

Tim Prinzing has updated the pull request incrementally with one additional 
commit since the last revision:

  missing dot

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7447/files
  - new: https://git.openjdk.java.net/jdk/pull/7447/files/02d00ecb..c803a93b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7447=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7447=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7447.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7447/head:pull/7447

PR: https://git.openjdk.java.net/jdk/pull/7447


Re: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is null [v2]

2022-02-14 Thread Tim Prinzing
> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null

Tim Prinzing has updated the pull request incrementally with one additional 
commit since the last revision:

  Changes from feedback.
  
  - Improved javadoc.
  - Single copyright date in new files.
  - Informative string in exception that is thrown.
  - Shortened the test name.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7447/files
  - new: https://git.openjdk.java.net/jdk/pull/7447/files/1bb6316f..02d00ecb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7447=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7447=00-01

  Stats: 152 lines in 5 files changed: 77 ins; 70 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7447.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7447/head:pull/7447

PR: https://git.openjdk.java.net/jdk/pull/7447


Re: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null

2022-02-11 Thread Tim Prinzing
On Fri, 11 Feb 2022 20:36:26 GMT, Tim Prinzing  wrote:

> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is 
> null

Yes, I like the IllegalCallerException.

-

PR: https://git.openjdk.java.net/jdk/pull/7448


RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null

2022-02-11 Thread Tim Prinzing
JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null

-

Commit messages:
 - Merge branch 'master' into JDK-8281000
 - JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is 
null

Changes: https://git.openjdk.java.net/jdk/pull/7448/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7448=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281000
  Stats: 140 lines in 4 files changed: 139 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7448.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7448/head:pull/7448

PR: https://git.openjdk.java.net/jdk/pull/7448


RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is null

2022-02-11 Thread Tim Prinzing
JDK-8281003 - MethodHandles::lookup throws NPE if caller is null

-

Commit messages:
 - Merge branch 'master' into JDK-8281003
 - Merge branch 'master' into JDK-8281003
 - removed commented out code
 - Moved null caller MethodHandles.lookup() test to a more reasonable location
 - JDK-8281003 - MethodHandles::lookup throws NPE if caller is null

Changes: https://git.openjdk.java.net/jdk/pull/7447/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7447=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281003
  Stats: 88 lines in 4 files changed: 82 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7447.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7447/head:pull/7447

PR: https://git.openjdk.java.net/jdk/pull/7447


Integrated: JDK-8276681: Additional malformed Javadoc inline tags in JDK source

2021-12-02 Thread Tim Prinzing
On Sat, 20 Nov 2021 04:09:51 GMT, Tim Prinzing  wrote:

> JDK-8276681: Additional malformed Javadoc inline tags in JDK source

This pull request has now been integrated.

Changeset: b8ac0d20
Author:    Tim Prinzing 
Committer: Lance Andersen 
URL:   
https://git.openjdk.java.net/jdk/commit/b8ac0d20ceec26b3a1dd0b9577817fa6320ea9ef
Stats: 11 lines in 9 files changed: 0 ins; 0 del; 11 mod

8276681: Additional malformed Javadoc inline tags in JDK source

Reviewed-by: lancea

-

PR: https://git.openjdk.java.net/jdk/pull/6486


Re: RFR: JDK-8276681: Additional malformed Javadoc inline tags in JDK source [v2]

2021-12-02 Thread Tim Prinzing
> JDK-8276681: Additional malformed Javadoc inline tags in JDK source

Tim Prinzing has updated the pull request with a new target base due to a merge 
or a rebase. The incremental webrev excludes the unrelated changes brought in 
by the merge/rebase. The pull request contains three additional commits since 
the last revision:

 - Merge branch 'master' into JDK-8276681
 - Merge branch 'master' into JDK-8276681
 - Fix missing '@' in javadoc for JDK-8276681

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6486/files
  - new: https://git.openjdk.java.net/jdk/pull/6486/files/e8071197..8eaf05bc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=6486=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=6486=00-01

  Stats: 29529 lines in 653 files changed: 17761 ins; 7341 del; 4427 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6486.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6486/head:pull/6486

PR: https://git.openjdk.java.net/jdk/pull/6486


Integrated: JDK-8276674 : Malformed Javadoc inline tags in JDK source

2021-12-02 Thread Tim Prinzing
On Thu, 18 Nov 2021 03:22:50 GMT, Tim Prinzing  wrote:

> JDK-8276674 : Malformed Javadoc inline tags in JDK source

This pull request has now been integrated.

Changeset: 652b5f85
Author:    Tim Prinzing 
Committer: Brent Christian 
URL:   
https://git.openjdk.java.net/jdk/commit/652b5f8546d0453238166f8fcd0cd3d882886bb4
Stats: 13 lines in 8 files changed: 0 ins; 0 del; 13 mod

8276674: Malformed Javadoc inline tags in JDK source

Reviewed-by: jjg, rriggs, prappo, bchristi

-

PR: https://git.openjdk.java.net/jdk/pull/6443


Re: RFR: JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream [v2]

2021-12-01 Thread Tim Prinzing
> JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream

Tim Prinzing has updated the pull request with a new target base due to a merge 
or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into JDK-8276674
 - Fixed @code and @link in some javadoc for JDK-8276674

-

Changes: https://git.openjdk.java.net/jdk/pull/6443/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6443=01
  Stats: 13 lines in 8 files changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6443.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6443/head:pull/6443

PR: https://git.openjdk.java.net/jdk/pull/6443


RFR: JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream

2021-11-24 Thread Tim Prinzing
JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream

-

Commit messages:
 - Fixed @code and @link in some javadoc for JDK-8276674

Changes: https://git.openjdk.java.net/jdk/pull/6443/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6443=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276674
  Stats: 14 lines in 9 files changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6443.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6443/head:pull/6443

PR: https://git.openjdk.java.net/jdk/pull/6443