RFR  Need a way to suppress message when picking up JAVA_TOOL_OPTIONS
ivan.gerasimov at oracle.com
Thu Apr 3 16:03:19 UTC 2014
On 03.04.2014 19:39, Daniel D. Daugherty wrote:
> On 4/3/14 9:30 AM, Ivan Gerasimov wrote:
>> Thanks Staffan for your opinion!
>> On 03.04.2014 18:40, Staffan Larsen wrote:
>>> On 3 apr 2014, at 16:28, Ivan Gerasimov <ivan.gerasimov at oracle.com>
>>>> Thanks Staffan!
>>>>>> We've got a customer who is annoyed by this message.
>>>>>> They use the env variable to pass additional options to the jvm.
>>>>>> Currently they have to add some additional processing of the
>>>>>> output to scrape the stderr and get rid of this message.
>>>>> It sounds like they have a good solution in place and no change is
>>>>> required on our part.
>>>>> Seriously, we have way too many options already and we cannot
>>>>> please everyone by adding options for every single use case.
>>>> The solution they use now isn't good, that's why they complained.
>>>> The proposed option might be useful by its own, in the case anyone
>>>> else will be annoyed by the message about picking up the env
>>>> variable content.
>>>> Please also note, that it's not meant to be a command line option.
>>>> It will only be used as a part of the env variable content.
>>>> Your point that there are already plenty of other options is true,
>>>> but doesn't really suggests anything for this particular situation.
>>> I suggest not solving this situation. As I said: "we cannot please
>>> everyone by adding options for every single use case.”
>> Let's see if we can find an alternative approach to not solving it :)
>> There are two env variables which can be used to pass the options:
>> standard JAVA_TOOL_OPTIONS and non-standard _JAVA_OPTIONS.
>> What if we introduce another variable, say _QUIET_JAVA_OPTIONS, which
>> will act in the same way, but with no additional noise?
>> This would be even easier to implement and use.
>> What would you say about another env var instead of another option?
> The VM squawks about JAVA_TOOL_OPTIONS and _JAVA_OPTIONS being used
> because they are dangerous. Adding an option that would allow the
> same mechanism to be used without warning would be... well...
> even more dangerous.
The customer already has a way to get rid of the warning: Preprocess the
output and filter the warning out.
This approach is ugly, hard to make general and leads to errors.
I think we should provide an option to achieve the same effect but
without that hard work around.
> Please read the note that I added to your bug.
>> Sincerely yours,
More information about the hotspot-dev