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

Ivan Gerasimov ivan.gerasimov at oracle.com
Tue Apr 8 08:30:56 UTC 2014


Hi everyone!

That's the second round.

First, here are a few thoughts about the issue:

- When a console application is created, the user expects its output 
(both stdout and stderr) to be predictable.
If I created a 'hello world' program, I would expect it to print only 
what it's supposed to print, but nothing more.

- The runtime should not intermix its output with the program output, 
unless it is specifically told to do that.
In the documentation [1][2], it's not written that using 
JAVA_TOOL_OPTIONS environment variable will make the runtime produce 
warnings in the application stderr.

- It is already specified, that in the cases when it might be unsafe to 
pick up the options from the environment variable, the runtime does not 
process them.
Here's the extract from [2]: "Platforms may disable this feature in 
cases where security is a concern."

[1] 
http://docs.oracle.com/javase/8/docs/technotes/guides/tsgvm/envvars.html#env_var_sys_prop
[2] 
http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#tooloptions

I totally agree that with JEP-158 implemented, this warning message 
should definitely appear in the application logs.
It would always be useful it the logs, but not always is it useful in 
the application stderr, because it can make the application caller 
unnecessary complicated.

I changed the fix to implement an alternative environment variable, 
_QUIET_JAVA_OPTIONS, which behaves in the same way _JAVA_OPTIONS does, 
but does not produce the warning message.
The change is quiet simple and does not change the current behavior of 
JAVA_TOOL_OPTIONS or _JAVA_OPTIONS variables.
This variable is not meant to be documented.
We will only suggest it to the users which need to get rid of the 
warning and complain about it.

Would you please help review the new webrev:
http://cr.openjdk.java.net/~igerasim/8039152/1/webrev/

Sincerely yours,
Ivan



More information about the hotspot-dev mailing list