[jdk8u-dev] RFR: 8288483: JAVA_TOOL_OPTIONS are silently truncated if they exceed 1024 bytes [v2]

[Dmitry Samersoff]

On Fri, 17 Jun 2022 13:08:58 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

>> The JAVA_TOOL_OPTIONS environment variable is used to pass additional JVM arguments.
>> 
>> The current implementation in jdk8 has an internal limit on the length of the option variable (1024 bytes) and the number of options (64).
>> 
>> A longer variable will be silently truncated and some options will be lost or the VM will exist with an unrecognized option error.
>> 
>> The fix is not a direct backport of the changes in the later JDKs, but I kept the code as close as possible to what we have in the latest jdk.
>> 
>> It's partial backport of relevant changes from JDK-8135195, JDK-8074895, JDK-8061999
>
> Dmitry Samersoff has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8288483: JAVA_TOOL_OPTIONS are silently truncated if they exceed 1024 bytes

The main rationally behind these changes is to fix spec violation. JDK 8 specification **does not set any limits for JAVA_TOOL_OPTIONS length and number of items**, so every time when a customer steps into this problem, it gets escalated, and it is not possible to argue that this is the expected OpenJDK behavior. 
This issue can happen, for example, when someone moves a setup with command line arguments pointing to a long path on the filesystem, or when moving an existing setup to buildpacks. From a regular user standpoint, the current behavior of simply skipping of some options leaves the user with unusable command line parameters. Worse, the user may not even notice that some options has been skipped. 

Please look at the testcase https://github.com/dsamersoff/jdk_8288483_scratchpad/pull/2/files (this testcase is not a part of PR because it doesn’t exist in the upstream)

Codewise, the code is essentially the same to what we have in 11u with some minimal changes required to accommodate API difference. 
The code in 11u is the result of several sequential changes that have been made under different CRs listed above. I chose to port the final code rather than come in with set of backports. But I can create a direct backport of code from jdk9 that was replaced later, if you think that it is less risky.

Please, look at https://github.com/dsamersoff/jdk_8288483_scratchpad/pull/1/files for difference between 11u (left) and what is proposed to 8u (right).

-------------

PR: https://git.openjdk.org/jdk8u-dev/pull/74