Alan, it is exactly this kind of comment from the team which just tears apart the whole view that you might actually be considering what everyone in the Java community needs. There are people who always deploy with a security manager because they are deploying Java on a network or with Subjects active or any number of other reasons why a SecurityManager might be active.
I just feels like the team is completely out of touch with anyone who isn’t just running a web server or some other “app” server on a cloud environment. Java is used in so many other ways. Just like you’ve found that people are using introspection to access parts of the Java runtime that you’d like for them not to use, people are using ALL of the features of Java in ways you apparently are not aware of, or don’t seem to have considered. The repeated dismissal of the SecurityManager and the whole missing focus on “java users” as opposed to java developers is just amazing from my perspective… Gregg > On Apr 3, 2017, at 11:32 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 03/04/2017 17:28, Reto Merz wrote: > >> It was already suggested in another thread by Gregg Wonderly: >> Why not introduce a new method java.lang.SecurityManager#checkAttachAgent(x)? >> So the implementation can accept/reject an "attach agent request" >> dynamically at runtime. >> x could be some additional infos provided by the agent (eg: certificate). > The issue here is nothing to do with the security manager, assume no security > manager in the picture. > > Also, FWIW, VirtualMachine.attach has always specified a security manager for > the (probably rare) cases where a tool is run with a security manager. > > -Alan
