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

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

2022-06-08 Thread Tim Prinzing
nced 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 - Chang

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

2022-06-07 Thread Tim Prinzing
nced 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

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

2022-06-02 Thread Tim Prinzing
nced 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 t

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

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

2022-06-01 Thread Tim Prinzing
he 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.

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

2022-06-01 Thread Tim Prinzing
he 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.

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

2022-05-31 Thread Tim Prinzing
he 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.

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++ in

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

2022-05-31 Thread Tim Prinzing
he 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.

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

2022-05-31 Thread Tim Prinzing
he 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.

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

2022-05-29 Thread Tim Prinzing
he 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.

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

2022-05-29 Thread Tim Prinzing
he 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.

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

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

2022-05-26 Thread Tim Prinzing
nced 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 - Chang

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

2022-05-17 Thread Tim Prinzing
nced 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

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

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.

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

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
; 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 isOp

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
; 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 isOp

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
; 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 isOp

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:

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
; 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 isOp

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

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 o

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
ion 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

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
ion 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:

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

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
ion 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:

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
ion 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

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

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.ja

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 s

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.n

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/com

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 experimenta

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: ht

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/pul

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

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

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 -

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: ht

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 str

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

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 -

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/com

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 additio

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/com

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 s

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: