Most project teams I come accross as a consultant broadly ignore warnings.
I would not expect that most people pay attention to a warning that an
image is not including JVMTI, especially if the implications are unclear to
the person in charge of running the build. Excluding JVMTI by default - ie
excluding JVMTI from most jlink images as I said - is therefore not a good
default in my opinion.
As for your "this is FUD" argument, I can say that I have been in
situations like I described myself. The mentioned problem does not
necessarily mean that a vendor would deliberatly change their product to
break a competitor but there is a good chance that they will not respond to
a request to include JVMTI in their image if they do not require it
themselves. Especially if this would enable a supplementary product to
compete with a (paid) feature of an open core platform's maintainer.
Personally, I did however even experience the first scenario.
Obviously, I cannot name you details due to signed NDAs and it is up to you
if you want to believe me. But if you need a specific example of this
behavior, look no further than the Apple app store and their history of
removing applications that compete with Apple's own products.
Again, I do not say that this will happen all of the time or even often,
but I expect it to happen sometimes.
Therefore, I find it reasonable to include JVMTI on any jlink image where
it comes at the cost of 130 kilobyte.
2017-05-19 14:22 GMT+02:00 Andrew Dinn <ad...@redhat.com>:
> 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
>
