Attaching to a JVM image that does not include java.instrument

[Andrew Dinn]

Hi Rafael,

On 19/05/17 13:08, Rafael Winterhalter wrote:
> do not forget that we are talking about 130 kilobyte here which come at
> the costs of removing a feature that often serves as a last resort and
> where its need is rarely anticipated. Given the little overhead of
> including this module, I do not find it reasonable to disable a feature
> that aims to making cross-cutting functionality such as monitoring or
> production-level debugging detachable from a Java program.

I am aware of what little there is to be saved here. However, what you
find reasonable others may find unreasonable. So,I am glad that omitting
the agent support is an option for those who want it.

> When working with customers, changing a product pipe-line might be
> technically trivial but still involves meetings, waitings and politics
> where every step costs money and breaks deadlines. In this context, just
> having the Java agent functionality working is a big advantage and I
> find it sad to sacrifice this property over so little gain.

I understand this too s do our support team. I will do my best to ensure
that Red Hat's own products include agent support in the images we
provide and to ensure that Red Hat makes customers aware of the benefits
of including agent support in any images they produce and distribute.
However, I don't see the need to strong arm anyone here (see below).

> Finally, there is a chance that a Java application vendor deliberately
> removes Java agent support to make a product unmonitorable for generic
> tools in order to improve their position for selling a commercial tool
> based on a proprietary API. This would of course improve their position
> but clutter the Java agent system for operation teams. Java is mostly
> used in the enterprise and Java's universal runnability is an important
> property. Having agents not run on most jlink images does not improve
> this position.

Well, your first proposition is very easy to dismiss as FUD. Do you have
any reason to fear that unscrupulous vendors will try to do what you
suggest? And if they do is that not merely a reason for Java devs/users
to resort to another vendor who doesn't behave so unscrupulously.

Also, how would it benefit any vendor to cripple their own ability to
support their product?

Also, you say blithely hypothesise "having agents not run on most jlink
images" as though this is already a fait accompli. What makes you assume
that the mere /possibility/ of not including agent support will
translate to a high number of deployments opting for that possibility?
If agents are as important as you say (and I think they probably are)
then such a move would be as foolish as it is unlikely. Sorry but this
argument looks like FUD too.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander