RFR 12 : 8072130 : java/lang/instrument/BootClassPath/BootClassPathTest.sh fails on Mac OSX
xueming.shen at oracle.com
Tue Sep 18 17:01:52 UTC 2018
On 9/18/18, 9:42 AM, Brent Christian wrote:
> Any thoughts on this change? -B
> On 9/11/18 3:41 PM, Brent Christian wrote:
>> Please review this change to how the platform encoding is determined
>> on Mac when loading agents.
>> Webrev: http://cr.openjdk.java.net/~bchristi/8072130/webrev.01.cleanned/
>> Additional details in the bug report:
>> Some background:
>> Since JDK 8, if MacOS reports an encoding of US-ASCII, but no
>> encoding hints are provided in environment variables (LANG, LC_ALL,
>> LC_CTYPE), the JDK uses UTF-8 instead; see JDK-8011194. (This
>> allowed apps launched via double-clicked jar to display files
>> correctly for non-ASCII languages).
>> A similar encoding tweak was not made in the code path used for
>> loading agents.
>> This can come into play when an agent jar includes a Boot-Class-Path
>> entry containing non-ASCII characters. iconv() gets setup to convert
>> UTF-8 to US-ASCII, but will fail when encountering extended
>> characters in the entry, so the path in question is not added to the
>> bootclasspath. This will likely lead to a ClassNotFoundException.
>> When java/lang/instrument/BootClassPath/BootClassPathTest.sh is run
>> on a Mac with no values for LANG/LC_ALL/LC_CTYPE, Setup.java sees a
>> default encoding of UTF-8 (per 8011194) and creates Agent.jar with
>> a Boot-Class-Path that includes non-ASCII characters. But the
>> Boot-Class-Path entry gets skipped when loading Agent.jar, so the
>> AgentSupport class can't be found.
>> I propose this be fixed by adding the same UTF-8 encoding adjustment
>> on MacOS from 8011194 to the agent loading code path.
>> An additional note:
>> This bug was challenging to reproduce, in large part because the
>> 8011194 code checks for an absent env var (getenv() == null), but not
>> for env vars with a blank/empty string value (getenv() == ""), so the
>> test environment had to be setup in a specific way (e.g. 'unset LANG'
>> vs 'export LANG=') to reproduce this bug. So I'd like to update the
>> code to also check for empty string. I also added a couple small
>> improvements to the test.
>> 1. https://bugs.openjdk.java.net/browse/JDK-8011194
More information about the core-libs-dev