Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] JEP 411: Deprecate the Security Manager for Removal
Looks like java.lang.StackWalker is the thing to use for Java 9+. By the time SecurityManager goes away for good everything should have moved off of Java 8 (I really hope) and we can easily move to StackWalker I think.

Tom
 
 
 
----- 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:25 AM
 
There is 
 
StackTraceElement[] elements = Thread.currentThread().getStackTrace();
 
But it may not perform as well as the security manager (https://bugs.eclipse.org/bugs/show_bug.cgi?id=559036) Also it doesn't give you the actual class objects which is required to implement the ContextFinder and the multiplexing URLStreamHandlerFactory.

Tom
 
 
 
----- 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 following
 
1) The ContextFinder - the thread context class loader set by the framework that is used to make the buddy class loading solution work
2) 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
 
 
_______________________________________________
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
 

Back to the top