[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: Usage of iconv()
From:       Magnus Ihse Bursie <magnus.ihse.bursie () oracle ! com>
Date:       2024-04-30 12:16:14
Message-ID: 77bc954e-e0bb-40f3-a602-cb58cb7f74a3 () oracle ! com
[Download RAW message or body]

On 2024-04-25 20:30, Philip Race wrote:

>
>
> On 4/24/24 4:24 AM, Magnus Ihse Bursie wrote:
>> That is a good question. libiconv is used only on macOS and AIX, for 
>> a few libraries, as you say. I just tried removing -liconv from the 
>> macOS dependencies and recompiled, just to see what would happen. 
>> There were three instances for macOS: libsplashscreen, libjdwp and 
>> libinstrument.
>>
>>
>>
>> libsplashscreen uses it in splashscreen_sys.m, where it is used to 
>> convert the jar file name.
>
> This is called from the launcher, in java.base/share/native/libjli/java.c
>
>
>>
>> libjdwp uses it in utf_util.c, where it is used to convert file name 
>> and command lines, iiuc.
>>
>> It is likely that we have similar (but better) ways to convert 
>> charsets elsewhere in our libraries that can be used instead of 
>> libiconv. I guess these are not the only two places where a filename 
>> must be converted from the platform charset to UTF8.
>
> So whatever replacement there might be, it needs to be something that 
> is available very early in the life of the VM, in fact before there is 
> a VM running.

Agreed. But it seems to be that this is something that needs to be 
handled by libjli, to properly deal with paths and command lines. I'm 
wondering if the places which to *not* use iconv (or similar) is 
actually incorrect.

/Magnus

>
> -phil.
[prev in list] [next in list] [prev in thread] [next in thread]