I try to be supportive of the rather disruptive changes that Java 9 introduces but this one would really do more harm than good.
I work a lot with customers that build tools, many of them would be affected by this change in a negative way. Did you evaluate the use of the dynamic attachment API? Dynamic attachment has been around for more than ten years and you are attempting to cripple this feature in a footnote. I really believe that you are underestimating the impacts of this change. The entire point of a Java agent is to attach to a process after it was already started. I know of numerous use cases where the need for an agent is only discovered after a Java process is already running and the attachment is used as a means to adjusting a process without restarting it. And please bear in mind that tools departments or vendors do often not control the deployment procedure for Java processes and cannot dicatate start-up parameters as the one you suggest. It is an important feature of a Java agent to work independently of the JVM's deployment which you are taking away. (This is in particularly true for microservice setups where there are too many JVMs and not interfering with the deployment supports dev-ops culture.) Security was always a big argument for justifing these change but as dynamic attachment requires running as the same user, there is no security benefit to gain in this context. And I do not see how the integrity argument adds a notable benefit. Migrating to Java 9 is already imposing a big challange and this change will make it even harder. Please do not add this constraint.
