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