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.
_______________________________________________
platform-dev mailing list
[email protected]
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Reply via email to