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

[Rafael Winterhalter]

Hi Andrew,

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.

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.

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.

Best regards, Rafael

2017-05-19 13:41 GMT+02:00 Andrew Dinn <adinn at redhat.com>:

> HI Rafael,
>
> On 19/05/17 11:57, Rafael Winterhalter wrote:
> > Hi Alan,
> > I understand your current time constraint, I still want to point out that
> > this is a heavily used functionality and it not being available would
> cause
> > problems in basically all production environments I am aware of where the
> > lack of this API is not uncovered before running the application in some
> > production or production-like environment. And while JVMTI might be
> > optional in the spec, this is not how it is treated in practice.
> Therefore,
> > I want to make this point against not having JVMTI available on the
> default
> > jlink image but rather to include it by default. This can always change
> in
> > a future version when this issue is better understood. As said, while it
> is
> > not used by many people, a large number of Java users rely on it for
> their
> > and third party application as basically any Java tooling is built around
> > this. I just verified that this would be an issue for my current client
> > where a lack of JVMTI would result in an infinite restart loop.
> > Best regards, Rafael
>
> I think you have the cart before the horse here. This is only going to
> affect those who deploy apps which use custom images. It is not going to
> affect anyone using a standard JDK release image.  For all practical
> purposes this is unlikely to be a common circumstance.
>
> Your desire to stop people painting themselves into a corner is, no
> doubt, morally commendable. However, it is an error from which those
> affected will be able to obtain remedy without your help (by fixing
> their image). Personally, I think it would be better to leave anyone who
> puts themselves in such an unhappy situation to implement the solution
> for themselves. I will, of course, still do my best to educate all
> Byteman users about the pitfalls that might accompany careless drawing
> up of interior decor procedures. I don't really see why the JDK team
> need to do that job for me.
>
> 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
>