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

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

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

2022-05-25 Thread Mandy Chung
On Tue, 17 May 2022 20:16:48 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

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

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

2022-05-17 Thread Mandy Chung
On Tue, 17 May 2022 16:55:14 GMT, Tim Prinzing wrote: > I like the idea of moving all the null caller tests to a clearly named > directory to avoid duplication. +1. You can do this refactoring in a separate JBS issue and then update this PR when the tests are moved. - PR: https

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

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

2022-05-16 Thread Ioi Lam
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. T

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

2022-05-16 Thread Mandy Chung
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. T

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

2022-05-13 Thread Joe Darcy
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. T

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