RFR: 8343982: Remove usage of security manager from ClassLoader and related classes

Alan Bateman alanb at openjdk.org
Thu Nov 14 11:01:09 UTC 2024


On Thu, 14 Nov 2024 10:44:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Remove the code for the now defunct SecurityManager execution mode from ClassLoader and the built-in class loader implementations. The override of getPermissions is removed from the application class loader, and from the class loaders used to support module layers.
>> 
>> URLCassLoader (and its implementation URLClassPath) will be handled separately as there are spec changes required, and code in URLClassPath that requires special attention.
>
> src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java line 296:
> 
>> 294:             }
>> 295:         } else {
>> 296:             URL url = findResource(name);
> 
> Hello Alan, before the change in this PR, when the module name `mn` was `null`, we used to call `findResource(mn, name)` (on previously line number 298). The `findResource(String, String)` would then effectively end up calling `findResourceOnClassPath(name)` without doing anything more. 
> 
> With this change, we now call `findResource(String)` when module name is `null`. The implementation of `findResource(String)` has additional code which does resource's package name to module mapping and few other things before it can decide whether `findResourceOnClassPath(String)` needs to be called for this resource name. 
> 
> Should the change on this line instead have been `findResource(null, name)`?

The change was deliberate but you are right that when we know we are looking for a resource on the class path that it would be better to stick with findResource(null, name).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22097#discussion_r1842021462


More information about the core-libs-dev mailing list