| Re: [eclipse.org-architecture-council] JEP 411: Deprecate the Security Manager for Removal |
----- Original message -----
From: "Thomas Watson" <tjwatson@xxxxxxxxxx>
Sent by: "eclipse.org-architecture-council" <eclipse.org-architecture-council-bounces@xxxxxxxxxxx>
To: eclipse.org-architecture-council@xxxxxxxxxxx
Cc:
Subject: [EXTERNAL] Re: [eclipse.org-architecture-council] JEP 411: Deprecate the Security Manager for Removal
Date: Tue, Apr 20, 2021 8:09 AM
We actually do use the same trick to call getClassContext in the framework to support the following1) The ContextFinder - the thread context class loader set by the framework that is used to make the buddy class loading solution work2) Implementing the multiplexing URLStreamHnaderFactory implementation.3) Part of implementing the ancient bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=92924 which worked around what I considered a JVM bug with respect to assumptions about classloader hierarchy delegation. With Java 9 modules I cannot see how the JVM still has this issue though. I imagine this work around is no longer needed.For the other cases we do need an alternative to getting the class context which I have to believe already exists.
Tom
----- Original message -----
From: Mickael Istria <mistria@xxxxxxxxxx>
Sent by: "eclipse.org-architecture-council" <eclipse.org-architecture-council-bounces@xxxxxxxxxxx>
To: "eclipse.org-architecture-council" <eclipse.org-architecture-council@xxxxxxxxxxx>, "Eclipse platform general developers list." <platform-dev@xxxxxxxxxxx>, "Eclipse JDT general developers list." <jdt-dev@xxxxxxxxxxx>, eclipse-pmc@xxxxxxxxxxx
Cc:
Subject: [EXTERNAL] Re: [eclipse.org-architecture-council] JEP 411: Deprecate the Security Manager for Removal
Date: Tue, Apr 20, 2021 2:49 AM
Hi,In Eclipse SDK, I see SecurityManager used and extended in the Ant (extended as AntSecurityManager) support and in JDT's JavaEditor (extended as AccessChecker).I guess AntSecurityManager#checkExit is important for Ant mostly to not shutdown the IDE in undesired situations; and Eclipse IDE would share the same concerns as NetBeans as *some* Ant executions (but not all, and the ones that run inside the IDE are more typically internal usage) do run inside the IDE and not as a separate process. I think the fact that Ant does rely heavily on SecurityManager is a concern that is also to be expressed by Ant itself. But Ant has had for a long time some solution for it with explicit permissions ( https://ant.apache.org/manual/Tasks/java.html#permissions ), that are to be adopted by people using the dangerous tasks that can cause a System.exit(), and I do not see worrying occurrences of System.exit() in Ant codebase (https://github.com/apache/ant/search?p=2&q=system.exit ). So overall, it's not a big deal to loose security manager here; there might be some cases where the IDE fails if one uses internal Ant which use the Java task without forking, without setting permissions and the invoked code calls System.exit(), but this case can easily be perceived a bad usage scenario we don't really mind reducing support for.For JDT, it looks like the goal is just to access the getClassContext() utility publicly. I imagine other solutions can be found for that, can't they?As mentioned by Thomas, I don't think other concerns expressed by NetBeans do apply to Eclipse Platform._______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-architecture-council_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-architecture-council