On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato wrote:
> The gist of the issue is that the test case now always creates the boot
> classpath with non-ASCII chars appended, because the default encoding is
> fixed to UTF-8 with the fix to JDK-8260265.
>
> On macOS, javaagent tries to load the class
On Wed, 8 Sep 2021 23:38:38 GMT, David Holmes wrote:
> Pre-existing: The initialization logic in this code is quite odd for the case
> when no conversion is necessary (we call `utfInitialize` on every call to
> `convertUtf8ToPlatformString`!), but I assume we do not call
>
On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato wrote:
> The gist of the issue is that the test case now always creates the boot
> classpath with non-ASCII chars appended, because the default encoding is
> fixed to UTF-8 with the fix to JDK-8260265.
>
> On macOS, javaagent tries to load the class
On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato wrote:
> The gist of the issue is that the test case now always creates the boot
> classpath with non-ASCII chars appended, because the default encoding is
> fixed to UTF-8 with the fix to JDK-8260265.
>
> On macOS, javaagent tries to load the class
On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato wrote:
> The gist of the issue is that the test case now always creates the boot
> classpath with non-ASCII chars appended, because the default encoding is
> fixed to UTF-8 with the fix to JDK-8260265.
>
> On macOS, javaagent tries to load the class
