Disallowing the dynamic loading of agents by default (revised)

[Gregg Wonderly]

I really believe that we can't really flip off working applications with a JDK upgrade.  It's developer and deployed cooperation no matter which way the switch are by default.  Starting with unknowing developers, deployed and users having to suffer through discovery of what will it take to make their software work again just seems like an exercise in anarchy rather than helping the community gain better opportunities out of a more flexible JRE/JDK platform.

This really is something that will negatively impact a much large body of ignorant users, who are not engaged here, than we can imagine.  

Gregg

Sent from my iPhone

> On Apr 7, 2017, at 8:20 AM, Martijn Verburg <martijnverburg at gmail.com> wrote:
> 
> Hi all,
> 
> I've come back into this thread late, but for us (jClarity) we're OK with
> the revised proposal, it will give us the time with slow moving enterprise
> customers to move to an explicit Java agent approach.
> 
> Cheers,
> Martijn
> 
>> On 7 April 2017 at 13:53, Stephen Felts <stephen.felts at oracle.com> wrote:
>> 
>> I have a problem with the second point.
>> 
>> Oracle's application server has "FAST SWAP" functionality similar to
>> JRebel built-in so that a developer can speed up the "edit -> build ->
>> deploy -> test" cycle.
>> It uses an internal agent that attaches to the server so customers don't
>> need to see it, configure it, or even know the name of it.
>> It only works on application classes in an exploded ear or war file.
>> This proposal will make it so the JRebel agent will work but our own agent
>> won't.
>> 
>> Ironically, this feature only works in development mode and developers are
>> the ones most likely to run without any scripts having the CLASSPATH set up
>> and just run java weblogic.Server.
>> So as I've said many times I don't want any JDK9 command line options.
>> 
>> In trying to protect against the guilty, you are killing the innocent.
>> 
>> It seems to me that it's late in Phase 2 of ramp-down of JDK 9 and this
>> feature is not baked or well received.  IMO no changes should be done in
>> this area for JDK 9.
>> 
>> 
>> -----Original Message-----
>> From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf
>> Of mark.reinhold at oracle.com
>> Sent: Wednesday, April 5, 2017 12:15 PM
>> To: jigsaw-dev at openjdk.java.net
>> Subject: Disallowing the dynamic loading of agents by default (revised)
>> 
>> Thanks to everyone for the quick feedback on this topic, and especially to
>> Andrew for the constructive dialogue.
>> 
>> Here's a revised proposal:
>> 
>>  - Define a new VM option, `-XX:+EnableDynamicAgentLoading`, that's
>>    on by default in JDK 9 but off by default in JDK 10.
>> 
>>    This will allow launch scripts that use this option on JDK 10 to
>>    work on JDK 9 without change, and will allow early testing of the
>>    JDK 10 behavior on JDK 9.
>> 
>>  - Revise the `com.sun.tools.attach` API to forbid attachment to the
>>    current process or to an ancestor of the current process, and
>>    define a read-only system property that allows such attachment to
>>    be enabled via the command line.
>> 
>>    This will discourage the inadvertent use of libraries that, for
>>    better or for worse, intentionally violate strong encapsulation.
>> 
>>  - Enhance the `-jar` launcher option so that if the JAR file being
>>    launched contains a `Premain-Class` attribute then it's launched
>>    as both an application and as an agent for that application.
>> 
>>    This will allow `java -jar foo.jar` to be used in place of the
>>    more verbose `java -javaagent:foo.jar -jar foo.jar` [1].
>> 
>> Taken together, these changes are intended to enable the continued use of
>> legitimate dynamically-loaded agents without change on JDK 9 and with a
>> small change on JDK 10.  That later change will align the treatment of such
>> agents with the other means of breaking encapsulation (`--add-opens`,
>> etc.) in order to ensure integrity by default for all code.
>> 
>> This proposal does not attempt to lock down platform classes as distinct
>> from user classes.  Many agents have legitimate reasons to transform
>> platform classes, so an additional mechanism to protect those classes does
>> not appear to be worthwhile.
>> 
>> Comments?
>> 
>> - Mark
>> 
>> 
>> [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-
>> April/012000.html
>>