jakartaee
Deprecate ServletContext.getClassLoader() SecurityManager requirement?
I'd like to see a discussion around ServletContext.getClassLoader() and the SecurityManager requirement.
The javadoc for ServletContext.getClassLoader() has a SecurityManager requirement that says ...
From: https://docs.oracle.com/javaee/7/api/javax/servlet/ServletContext.html#getClassLoader--
Gets the class loader of the web application represented by this ServletContext. If a security manager exists, and the caller's class loader is not the same as, or an ancestor of the requested class loader, then the security manager's checkPermission method is called with a RuntimePermission("getClassLoader") permission to check whether access to the requested class loader should be granted.
Note the deprecation and removal of sun.reflect.Reflection.getCallerClass() in Java 9+ - https://bugs.openjdk.java.net/browse/JDK-8179424
It seems this caller classloader requirement is getting more difficult to honor correctly. The commentary on https://bugs.openjdk.java.net/browse/JDK-8020968 (Provide a replacement for sun.reflect.Reflection.getCallerClass) talks about the problems with the new features in Java (lamdas, new reflection, invoker api, etc) and this kind of get caller classloader requirement.
Is the existing servlet-dev mailing list just for committers on this project?
If so, is there a servlet-users mailing list yet?
Is the existing
servlet-devmailing list just for committers on this project?
I think that is a decision the Servlet community can make (and not one that has been made so far).
If so, is there a
servlet-usersmailing list yet?
No. This is the only project mailing list at the moment.
I'd argue that it is better to keep a single mailing list at this point. My experience in the Servlet EG of splitting the mailing lists was that it was not helpful. Pretty much every discussion was split across the two lists with people who only followed one list missing bits of the conversation.
Given that the Security Manager is deprecated for removal in JDK 17, I think it's best to remove this requirement ASAP.
