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.
