On Mon, 15 May 2023 00:28:41 GMT, Ichiroh Takiguchi
wrote:
> According to "JDK 20 Internationalization Guide"
> https://docs.oracle.com/en/java/javase/20/intl/supported-encodings.html
> Following Solaris related charsets are in "contained in jdk.charsets module&quo
On Sat, 20 May 2023 17:26:53 GMT, Naoto Sato wrote:
>> Hello @naotoj .
>> I'd like to confirm about DoubleByte-X.java.template and
>> EUC_JP.java.template.
>> I think the values are package-private.
>> Even if class is changed to `public`, the classes in`sun.nio.cs.ext` package
>> could not acc
On Sat, 20 May 2023 17:26:53 GMT, Naoto Sato wrote:
>> Hello @naotoj .
>> I'd like to confirm about DoubleByte-X.java.template and
>> EUC_JP.java.template.
>> I think the values are package-private.
>> Even if class is changed to `public`, the classes in`sun.nio.cs.ext` package
>> could not acc
s://bugs.openjdk.org/browse/JDK-8308051) GHA:
> Linux x86 builds failure
Ichiroh Takiguchi has updated the pull request incrementally with one
additional commit since the last revision:
8308046: Move Solaris related charsets from java.base to jdk.charsets module
-
Changes:
- all: h
On Thu, 18 May 2023 00:50:22 GMT, Naoto Sato wrote:
>>> Hello @naotoj . I'm not sure we can remove Solaris related charsets.
>>> Somebody may use them for text communication between Solaris.
>>
>> OK, maybe not now.
>>
>> I think the fix may be simplified by changing access for those
>> `Doub
On Tue, 16 May 2023 17:13:02 GMT, Naoto Sato wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8308046: Move Solaris related Japanese charsets from java.base to
>> jdk.charset
Solaris (x-eucJP-Open)
>
> These are not supported by Linux platform, so they should not be in java.base
> module.
>
> Note:
> GHA Linux x86 builds were failed.
> I think it's not related by my modified code.
> I opened [JDK-8308051](https://bugs.openjdk.org/browse/JDK-83
On Fri, 24 Feb 2023 17:19:22 GMT, Naoto Sato wrote:
>> Hello @naotoj .
>> Sorry for bothering you.
>>
>> I have following question:
>> - Why GB18030.java.template is in
>> src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory even if the
>> generated code is always stored into sun/nio/cs ?
On Thu, 23 Feb 2023 19:34:44 GMT, Naoto Sato wrote:
>> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since
>> this is not a compatible upgrade to the existing mapping, a new system
>> property `jdk.charset.GB18030` is introduced. If it is set to "2000", the
>> mapping f
On Wed, 25 Jan 2023 18:58:40 GMT, Alan Bateman wrote:
>> `Charset.defaultCharset()` now uses
>> `standardProvider.charsetForName()` charset.
>
>> `Charset.defaultCharset()` now uses
>> `standardProvider.charsetForName()` charset.
>
> I think this is the right thing to do. It can also be change
On Tue, 24 Jan 2023 12:51:31 GMT, Alan Bateman wrote:
> Do you know if there is any configuration on AIX that would derive Cp943C as
> the default charset? That is, are they running with -Dfile.encoding=Cp943C on
> the AIX systems or is it chosen by default. This goes to the question as to
> w
On Mon, 23 Jan 2023 13:46:15 GMT, Alan Bateman wrote:
> It's never been supported to run with -Dfile.encoding=Cp943C. It may have
> worked in JDK 8 but I doubt it could have worked consistently since JDK 9
> because the default charset is derived before it's possible to locate charset
> implem
On Mon, 23 Jan 2023 07:48:41 GMT, Alan Bateman wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8300819: -Dfile.encoding=Cp943C option does not work as expected since
>> jdk1
On Sun, 22 Jan 2023 23:17:10 GMT, Ichiroh Takiguchi
wrote:
>> On jdk17, following testcase works fine on Linux platform.
>>
>> Testcase
>>
>> $ cat cstest1.java
>> import java.nio.charset.*;
>>
>> public class cstest1 {
>> p
module java.base
>
>
> Fixed result is as follows:
>
> $ java -Dfile.encoding=Cp943C -showversion PrintDefaultCharset
> openjdk version "21-internal" 2023-09-19
> OpenJDK Runtime Environment (build 21-internal-adhoc.jdktest.jdk)
> OpenJDK 64-Bit Server VM (bui
On jdk17, following testcase works fine on Linux platform.
Testcase
$ cat cstest1.java
import java.nio.charset.*;
public class cstest1 {
public static void main(String[] args) throws Exception {
Charset cs = Charset.defaultCharset();
System.out.println(cs + ", " + cs.getClass() + ", "
On Wed, 21 Dec 2022 15:57:29 GMT, Ichiroh Takiguchi
wrote:
> test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java may fail at future date.
> I used following standalone testcase
>
> import java.util.Calendar;
> import java.util.Date;
> import java.util.SimpleTimeZone;
>
&g
On Wed, 21 Dec 2022 20:54:25 GMT, Naoto Sato wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8299194: CustomTzIDCheckDST.java may fail at future date
>
> Thanks for the fix. L
0 2023
>
>
> Southern Hemisphere side
>
> $ TZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3
> date
> Sun Mar 26 02:59:59 MESZ 2023
> $bTZ=GMT faketime -m '2023-03-26 00:59:59' env TZ=MEZ-1MESZ,M10.5.0,M3.5.0/3
> java CheckDST
test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java may fail at future date.
I used following standalone testcase
import java.util.Calendar;
import java.util.Date;
import java.util.SimpleTimeZone;
public class CheckDST {
private static String CUSTOM_TZ = "MEZ-1MESZ,M3.5.0,M10.5.0";
public
On Wed, 6 Jul 2022 14:05:39 GMT, Ichiroh Takiguchi
wrote:
> OpenJDK supports "Japanese EBCDIC - Katakana" and "Korean EBCDIC" SBCS and
> DBCS Only charsets.
> |Charset|Mix|SBCS|DBCS|
> | -- | -- | -- | -- |
> | Japanese EBCDIC - Katakana | Cp930 | Cp290 |
On Fri, 26 Aug 2022 09:25:55 GMT, Alan Bateman wrote:
>> OpenJDK supports "Japanese EBCDIC - Katakana" and "Korean EBCDIC" SBCS and
>> DBCS Only charsets.
>> |Charset|Mix|SBCS|DBCS|
>> | -- | -- | -- | -- |
>> | Japanese EBCDIC - Katakana | Cp930 | Cp290 | Cp300 |
>> | Korean | Cp933 | Cp833 | C
On Tue, 9 Aug 2022 20:38:25 GMT, Naoto Sato wrote:
>> To support Windows command prompt's codepage, following charsets should be
>> moved from jdk.charsets module to java.base module.
>>
>> - IBM860
>> - IBM861
>> - IBM863
>> - IBM864
>> - IBM865
>> - IBM869
>
> I looked at this issue a bit mor
On Fri, 26 Aug 2022 07:26:46 GMT, Ichiroh Takiguchi
wrote:
> After `test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java` testcase was
> integrated, it failed on the AIX platform.
>
> Error output
>
> STDERR:
> stdout: [];
> stderr: [Exception in thread "mai
On Fri, 26 Aug 2022 18:56:31 GMT, Naoto Sato wrote:
>> After `test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java` testcase was
>> integrated, it failed on the AIX platform.
>>
>> Error output
>>
>> STDERR:
>> stdout: [];
>> stderr: [Exception in thread "main" java.lang.RuntimeException: Got
After `test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java` testcase was
integrated, it failed on the AIX platform.
Error output
STDERR:
stdout: [];
stderr: [Exception in thread "main" java.lang.RuntimeException: Got unexpected
timezone information: Thu Aug 25 09:29:10 CEST 2022
at Cu
On Mon, 8 Aug 2022 09:22:32 GMT, Alan Bateman wrote:
>> Hello @AlanBateman .
>> Sorry I'm late.
>> I got some responses from ICU.
>> [ICU-22091](https://unicode-org.atlassian.net/browse/ICU-22091)
>> I'm not sure if they're interested in the new charset...
>>
>> As you know `sun.nio.cs.ArrayDec
On Fri, 5 Aug 2022 16:44:37 GMT, Naoto Sato wrote:
>> To support Windows command prompt's codepage, following charsets should be
>> moved from jdk.charsets module to java.base module.
>>
>> - IBM860
>> - IBM861
>> - IBM863
>> - IBM864
>> - IBM865
>> - IBM869
>
> Hi @takiguc,
> I am not quite su
An\: build\-dev at openjdk\.org \\;
>> core\-libs\-dev at openjdk\.org \\;
>> i18n\-dev at openjdk\.org \
>> Betreff\: Re\: RFR\: 8289834\: Add SBCS and DBCS Only EBCDIC charsets
>>
>> On Wed\, 6 Jul 2022 16\:18\:08 GMT\, Ichiroh Takiguchi \> openjdk\.org> wrot
On Wed, 27 Jul 2022 17:47:36 GMT, Naoto Sato wrote:
> Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy
> came from the mapping difference between MS and IBM.
I think you can ignore my comments.
I'm not sure if this change will solve the reporter's issue...
-
On Thu, 28 Jul 2022 16:18:51 GMT, Naoto Sato wrote:
>> Many thanks @naotoj .
>>
>> I checked the latest IBM-864 mapping table.
>> (I assume current OpenJDK's IBM864 may refer older mapping table)
>> https://raw.githubusercontent.com/unicode-org/icu/main/icu4c/source/data/mappings/ibm-864_X110-19
On Thu, 28 Jul 2022 01:46:26 GMT, Naoto Sato wrote:
>> Hello @naotoj .
>> I'm not reviewer, but I'd like to test this change.
>> Could you wait for a moment ?
>> Thanks.
>
> @takiguc Sure. Appreciate it.
Many thanks @naotoj .
I checked the latest IBM-864 mapping table.
(I assume current OpenJDK
On Wed, 27 Jul 2022 17:47:36 GMT, Naoto Sato wrote:
> Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy
> came from the mapping difference between MS and IBM.
Hello @naotoj .
I'm not reviewer, but I'd like to test this change.
Could you wait for a moment ?
Thanks.
--
On Wed, 6 Jul 2022 14:05:39 GMT, Ichiroh Takiguchi
wrote:
> OpenJDK supports "Japanese EBCDIC - Katakana" and "Korean EBCDIC" SBCS and
> DBCS Only charsets.
> |Charset|Mix|SBCS|DBCS|
> | -- | -- | -- | -- |
> | Japanese EBCDIC - Katakana | Cp930 | Cp290 |
OpenJDK supports "Japanese EBCDIC - Katakana" and "Korean EBCDIC" SBCS and DBCS
Only charsets.
|Charset|Mix|SBCS|DBCS|
| -- | -- | -- | -- |
| Japanese EBCDIC - Katakana | Cp930 | Cp290 | Cp300 |
| Korean | Cp933 | Cp833 | Cp834 |
But OpenJDK does not supports some of "Japanese EBCDIC - English"
35 matches
Mail list logo
