RFR [8039152] Need a way to suppress message when picking up JAVA_TOOL_OPTIONS

[Daniel D. Daugherty]

On 4/3/14 9:55 AM, Ivan Gerasimov wrote:
> Thank you Daniel for your complete analysis!
>
> If I get it correctly, your main point is that we should always warn 
> the user about using a dangerous way to pass the options.
> While I tend to agree with it respecting to the standard 
> JAVA_TOOL_OPTIONS, I think if we can make a compromise dealing with a 
> non-standard env variable.
> If a user is using a non-standard variable, one should already be 
> aware of the danger.
>
> Introducing a new variable which will specifically be said to be quiet 
> would not break the existing behavior.

The problem is that the new variable would not be limited to use
by people aware of the danger. The new variable could be used by
anyone wanting a quiet avenue of attack into the VM...

Dan


>
> Sincerely yours,
> Ivan
>
> On 03.04.2014 19:06, Daniel D. Daugherty wrote:
>> On 4/3/14 8:40 AM, Staffan Larsen wrote:
>>> On 3 apr 2014, at 16:28, Ivan Gerasimov <ivan.gerasimov at oracle.com> 
>>> wrote:
>>>
>>>> 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.”
>>
>> I've added a somewhat long evaluation to the bug report.
>>
>> My summary line:
>>
>>    I strongly recommend that we don't try to change this behavior.
>>
>> Dan
>>
>>
>>>
>>> Sorry,
>>> /Staffan
>>>
>>>> Sincerely yours,
>>>> Ivan
>>>>
>>
>>
>>
>