On Fri, 27 Jun 2025 16:15:57 GMT, Magnus Ihse Bursie wrote:
>> In the static JDK image, a single humongous java executable is generated,
>> and no other launcher, such as javac. This makes it impossible to run our
>> jtreg tests, which assume these are present.
>
On Mon, 30 Jun 2025 15:08:25 GMT, David Beaumont wrote:
>> Initial benchmark to capture at least some comparative measures of
>> ImageReader performance.
>>
>> Current results on my laptop:
>>
>> Benchmark Mode Cnt ScoreError
>> Units
>> NewImag
On Fri, 27 Jun 2025 20:45:14 GMT, Naoto Sato wrote:
> The ICU4J component currently stores binary data files directly in the
> repository. This change replaces them with base64-encoded text files and
> converts them to binary during the build process
I don't see any benefit of checking in base
On Fri, 27 Jun 2025 20:45:14 GMT, Naoto Sato wrote:
> The ICU4J component currently stores binary data files directly in the
> repository. This change replaces them with base64-encoded text files and
> converts them to binary during the build process
What is the point of this change? If the fi
On Fri, 27 Jun 2025 16:15:57 GMT, Magnus Ihse Bursie wrote:
>> In the static JDK image, a single humongous java executable is generated,
>> and no other launcher, such as javac. This makes it impossible to run our
>> jtreg tests, which assume these are present.
>
al
> launchers, which are thin wrappers that execute the main java binary, with
> the proper arguments. This will result in the same behavior as the normal
> dynamic launchers, only that we will need to take the detour of launching
> another process instead of calling directly into th
On Thu, 3 Apr 2025 14:09:58 GMT, Alan Bateman wrote:
> As regards the shim when I wonder if it should use CreateProcessW but maybe
> it doesn't matter for the test environments where they will run.
I must admit that I am not very well versed in Windows programming. What is the
difference? I th
On Wed, 2 Apr 2025 14:54:35 GMT, Magnus Ihse Bursie wrote:
> In the static JDK image, a single humongous java executable is generated, and
> no other launcher, such as javac. This makes it impossible to run our jtreg
> tests, which assume these are present.
>
> The solution
al
> launchers, which are thin wrappers that execute the main java binary, with
> the proper arguments. This will result in the same behavior as the normal
> dynamic launchers, only that we will need to take the detour of launching
> another process instead of calling directly into th
Hi Philippe,
There is an ongoing effort about "Panamization" (that is, adapting it to
use FFM instead of JNI) of native code in the JDK in general. This is
discussed on the core-libs-dev mailing list. I've cc:ed them. I think it
would be beneficial if you coordinate your efforts with the Panam
On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie wrote:
> After we converted the source base to be fully UTF-8, we do not need to use
> unicode sequences (like \u0123) in string literals. Sometimes, that might
> still make sense, as for control characters, non-breaking space, etc
On Mon, 9 Jun 2025 13:41:10 GMT, Magnus Ihse Bursie wrote:
>> After we converted the source base to be fully UTF-8, we do not need to use
>> unicode sequences (like \u0123) in string literals. Sometimes, that might
>> still make sense, as for control characters, non-breaki
nt text in a language that needs
> non-ASCII parts of Unicode, this is not so. Instead, having the sequences
> makes the text just harder to read and edit. We have already removed several
> such sequences before, but some remains.
Magnus Ihse Bursie has updated the pull request incrementally w
On Tue, 27 May 2025 17:01:13 GMT, Naoto Sato wrote:
>> After we converted the source base to be fully UTF-8, we do not need to use
>> unicode sequences (like \u0123) in string literals. Sometimes, that might
>> still make sense, as for control characters, non-breaking space, etc. But
>> for st
On Tue, 27 May 2025 16:31:47 GMT, Justin Lu wrote:
>> @justin-curtis-lu Are these files handled by the translation team?
>
> @magicus The ones under java.xml and jdk.jdi are updated by the translation
> team, I think it'd be best to remove those files from this change.
I have now reverted the c
nt text in a language that needs
> non-ASCII parts of Unicode, this is not so. Instead, having the sequences
> makes the text just harder to read and edit. We have already removed several
> such sequences before, but some remains.
Magnus Ihse Bursie has updated the pull request incrementally
nt text in a language that needs
> non-ASCII parts of Unicode, this is not so. Instead, having the sequences
> makes the text just harder to read and edit. We have already removed several
> such sequences before, but some remains.
Magnus Ihse Bursie has updated the pull request with a new
On Wed, 14 May 2025 14:23:31 GMT, Magnus Ihse Bursie wrote:
> I found a few other places in the code that can be cleaned up after the
> conversion to UTF-8.
This pull request has now been integrated.
Changeset: edf92721
Author:Magnus Ihse Bursie
URL:
https://git.openjdk.o
On Mon, 26 May 2025 08:20:19 GMT, Magnus Ihse Bursie wrote:
>> I found a few other places in the code that can be cleaned up after the
>> conversion to UTF-8.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two
> additional commits si
> I found a few other places in the code that can be cleaned up after the
> conversion to UTF-8.
Magnus Ihse Bursie has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase. Th
On Wed, 14 May 2025 15:11:24 GMT, Magnus Ihse Bursie wrote:
> Non-breaking space characters are problematic. They look identical to the
> normal space character, but is not. For that reason, it should never be typed
> as an UTF-8 literal, but only by using unicode sequences.
&g
On Mon, 26 May 2025 08:10:19 GMT, Magnus Ihse Bursie wrote:
>> I found a few other places in the code that can be cleaned up after the
>> conversion to UTF-8.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two
> additional commits si
> I found a few other places in the code that can be cleaned up after the
> conversion to UTF-8.
Magnus Ihse Bursie has updated the pull request incrementally with two
additional commits since the last revision:
- Restore MenuShortcut.java
- Restore LocaleDataTes
On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie wrote:
> After we converted the source base to be fully UTF-8, we do not need to use
> unicode sequences (like \u0123) in string literals. Sometimes, that might
> still make sense, as for control characters, non-breaking space, etc
On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie wrote:
> After we converted the source base to be fully UTF-8, we do not need to use
> unicode sequences (like \u0123) in string literals. Sometimes, that might
> still make sense, as for control characters, non-breaking space, etc
On Thu, 22 May 2025 21:26:08 GMT, Phil Race wrote:
>> FYI, the style guide for France
>> [recommends](https://fr.wikipedia.org/wiki/Espace_ins%C3%A9cable#En_France):
>>
>> - U+202F (Narrow No-Break Space NNBSP) preceding semicolon, question mark,
>> and exclamation mark.
>> - U+00A0 (No-Break
On Thu, 22 May 2025 21:43:20 GMT, Phil Race wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Restore MenuShortcut.java
>> - Restore LocaleDataTest.java
>
> src
On Thu, 15 May 2025 18:30:28 GMT, Naoto Sato wrote:
>> I found a few other places in the code that can be cleaned up after the
>> conversion to UTF-8.
>
> test/jdk/sun/text/resources/LocaleDataTest.java line 106:
>
>> 104: *FormatData/fr_FR/MonthNames/0=janvier
>> 105: *Format
On Thu, 15 May 2025 09:16:10 GMT, Magnus Ihse Bursie wrote:
>> Maybe, but sometimes it is intentional. CLDR has once switched normal spaces
>> to NBSP/NNBSP for certain locales
>> (https://unicode-org.atlassian.net/browse/CLDR-14032). And we cannot tell if
>> it is int
On Thu, 15 May 2025 03:18:30 GMT, Naoto Sato wrote:
>> maybe this is just a translation error and a simple space can be used
>> instead, like in all the other properties in these files?
>
> Maybe, but sometimes it is intentional. CLDR has once switched normal spaces
> to NBSP/NNBSP for certain
Non-breaking space characters are problematic. They look identical to the
normal space character, but is not. For that reason, it should never be typed
as an UTF-8 literal, but only by using unicode sequences.
I have checked:
* U+00A0 NO-BREAK SPACE (NBSP)
* U+202F NARROW NO-BREAK SPACE (NNBSP)
After we converted the source base to be fully UTF-8, we do not need to use
unicode sequences (like \u0123) in string literals. Sometimes, that might still
make sense, as for control characters, non-breaking space, etc. But for strings
that is supposed to be a coherent text in a language that ne
I found a few other places in the code that can be cleaned up after the
conversion to UTF-8.
-
Commit messages:
- Replace uncessary unicode characters with ASCII in instructions, and fix typo
- Seems like typos in the comments
- Fix unicode sequences in comments (previously missed
On Thu, 17 Apr 2025 14:42:37 GMT, Magnus Ihse Bursie wrote:
> As part of the UTF-8 cleaning up done in
> [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971), I looked at where
> and how we are using unicode sequences (`\u`). In several string
> literals, I think
On Tue, 13 May 2025 00:10:50 GMT, Sergey Bylokhov wrote:
>> A handful of html and xml files in the JDK source tree claims to have
>> encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
>>
>> While perhaps technically correct, this is misleading, and goes contrary to
>> the
On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie wrote:
> A handful of html and xml files in the JDK source tree claims to have
> encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
>
> While perhaps technically correct, this is misleading, and goes contra
commit that mistreated the encoding, but they have been
> there since the original release of the open JDK source code.
>
> There are likely many more places where direct UTF-8 encoded characters is
> preferable to unicode sequences, but this seemed like a safe and trivial
> f
A handful of html and xml files in the JDK source tree claims to have encodings
like `ISO-8859-1`, when they are in fact pure US-ASCII files.
While perhaps technically correct, this is misleading, and goes contrary to the
efforts of turning the source code into UTF-8 proper.
I chose between mar
On Tue, 6 May 2025 17:16:57 GMT, Naoto Sato wrote:
>> Magnus Ihse Bursie has updated the pull request with a new target base due
>> to a merge or a rebase. The incremental webrev excludes the unrelated
>> changes brought in by the merge/rebase. The pull request contains
On Fri, 9 May 2025 10:12:09 GMT, Magnus Ihse Bursie wrote:
>> As part of the UTF-8 cleaning up done in
>> [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971), I looked at
>> where and how we are using unicode sequences (`\u`). In several string
>> liter
commit that mistreated the encoding, but they have been
> there since the original release of the open JDK source code.
>
> There are likely many more places where direct UTF-8 encoded characters is
> preferable to unicode sequences, but this seemed like a safe and trivial
> first st
On Thu, 10 Apr 2025 14:28:02 GMT, Magnus Ihse Bursie wrote:
> Most of the JDK code base has been transitioned to UTF-8, but not all. This
> has recently become an acute problem, since our mixing of iso-8859-1 and
> utf-8 in properties files confused the version of `sed` that is shi
On Thu, 8 May 2025 10:19:31 GMT, Magnus Ihse Bursie wrote:
>> Most of the JDK code base has been transitioned to UTF-8, but not all. This
>> has recently become an acute problem, since our mixing of iso-8859-1 and
>> utf-8 in properties files confused the version of `sed` th
cordingly (basically, updating compiler flags, git
> attributes, etc).
Magnus Ihse Bursie has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 14 commits:
- Merge branch 'master' into go-full-utf8
- Merge branch 'mast
On Thu, 10 Apr 2025 10:18:08 GMT, Magnus Ihse Bursie wrote:
> As a follow-up to [JDK-8354213](https://bugs.openjdk.org/browse/JDK-8354213),
> I found some additional places where unicode characters are unnecessarily
> used instead of pure ASCII.
This pull request has now been i
On Tue, 6 May 2025 17:15:34 GMT, Naoto Sato wrote:
>> Magnus Ihse Bursie has updated the pull request with a new target base due
>> to a merge or a rebase. The incremental webrev excludes the unrelated
>> changes brought in by the merge/rebase. The pull request contains
On Fri, 2 May 2025 17:43:37 GMT, Jiangli Zhou wrote:
>> Please review this PR to problemlist jdk & langtools tier1 tests requiring
>> runtime usages of /bin/tools, for testing on static-jdk. The affected
>> tests using following tools at runtime:
>>
>> - javac
>> - javadoc
>> - jar
>> - jarsig
commit that mistreated the encoding, but they have been
> there since the original release of the open JDK source code.
>
> There are likely many more places where direct UTF-8 encoded characters is
> preferable to unicode sequences, but this seemed like a safe and trivial
> first st
On Tue, 6 May 2025 14:16:32 GMT, Magnus Ihse Bursie wrote:
>> As a follow-up to
>> [JDK-8354213](https://bugs.openjdk.org/browse/JDK-8354213), I found some
>> additional places where unicode characters are unnecessarily used instead of
>> pure ASCII.
>
> Magn
cordingly (basically, updating compiler flags, git
> attributes, etc).
Magnus Ihse Bursie has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase. The pull request contains 13 additional
On Wed, 16 Apr 2025 10:35:02 GMT, Matthias Baesken wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Also document UTF-8 requirements (solves JDK-8338973)
>> - Let confi
cordingly (basically, updating compiler flags, git
> attributes, etc).
Magnus Ihse Bursie has updated the pull request incrementally with two
additional commits since the last revision:
- Add informative message about supported locales.
- Allow C locale with warning instead of fatal error
On Thu, 17 Apr 2025 16:26:59 GMT, Naoto Sato wrote:
>>> We will probably need to make sure things are ok on Windows as well (they
>>> are the other confusing environment)
>>
>> Windows is much more painful to work with, since there is no correspondence
>> of `LC_ALL`; you must set the user's l
> As a follow-up to [JDK-8354213](https://bugs.openjdk.org/browse/JDK-8354213),
> I found some additional places where unicode characters are unnecessarily
> used instead of pure ASCII.
Magnus Ihse Bursie has updated the pull request with a new target base due to a
merge or a re
On Tue, 22 Apr 2025 07:41:43 GMT, Daishi Tabata wrote:
>> After searching the entire JDK source code, I found that WMIC is only used
>> in four files. These WMIC calls can be replaced with PowerShell for WMI.
>>
>> The primary challenge in this replacement is to make it work the same as
>> bef
On Wed, 23 Apr 2025 00:56:18 GMT, Jiangli Zhou wrote:
>> Please review this PR that changes to use `NativeLibraries.loadLibrary()`
>> for loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.
>>
>> `NativeLibraries.loadLibrary()` handles both the shared library and (static)
On Tue, 22 Apr 2025 07:41:43 GMT, Daishi Tabata wrote:
>> After searching the entire JDK source code, I found that WMIC is only used
>> in four files. These WMIC calls can be replaced with PowerShell for WMI.
>>
>> The primary challenge in this replacement is to make it work the same as
>> bef
On Mon, 28 Apr 2025 08:30:43 GMT, Maurizio Cimadamore
wrote:
>> Jiangli Zhou has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into
>> JDK-8355080
>> - Address henryjen@ c
As part of the UTF-8 cleaning up done in
[JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971), I looked at where
and how we are using unicode sequences (`\u`). In several string literals,
I think the unicode sequences still has merit, if they improve clarity or
readability of the code
On Fri, 14 Mar 2025 15:49:44 GMT, Magnus Ihse Bursie wrote:
> We should allow pre-built JVMs to be included in a build, so they are just
> copied into place, and the jvm.cfg file properly updated.
`KEEPALIVE`
-
PR Comment: https://git.openjdk.org/jdk/pull/24063#issuec
On Wed, 16 Apr 2025 16:14:39 GMT, Naoto Sato wrote:
> We will probably need to make sure things are ok on Windows as well (they are
> the other confusing environment)
Windows is much more painful to work with, since there is no correspondence of
`LC_ALL`; you must set the user's locale. There
On Wed, 16 Apr 2025 10:35:02 GMT, Matthias Baesken wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Also document UTF-8 requirements (solves JDK-8338973)
>> - Let confi
On Wed, 16 Apr 2025 04:39:22 GMT, Phil Race wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove incorrectly copied "§anchor"
>
> src/java.xml/share/legal/xhtml
On Mon, 14 Apr 2025 12:53:35 GMT, Magnus Ihse Bursie wrote:
>> Most of the JDK code base has been transitioned to UTF-8, but not all. This
>> has recently become an acute problem, since our mixing of iso-8859-1 and
>> utf-8 in properties files confused the version of `sed` th
On Wed, 16 Apr 2025 07:54:13 GMT, Martin Doerr wrote:
> We get the following problem on AIX:
>
> ```
> checking for locale to use... no UTF-8 locale found
> configure: error: No UTF-8 locale found. This is required for building
> successfully.
> configure exiting with result code 1
> ```
This
On Tue, 15 Apr 2025 23:20:45 GMT, Sergey Bylokhov wrote:
> can we also force this rule by the jcheck?
Well, yes and no. First, we can verify that we do not have invalid UTF-8. That
might be a signal that the encoding is wrong. But then this check needs to be
able to distinguish between pure bi
cordingly (basically, updating compiler flags, git
> attributes, etc).
Magnus Ihse Bursie has updated the pull request incrementally with three
additional commits since the last revision:
- Also document UTF-8 requirements (solves JDK-8338973)
- Let configure only accept utf-8 locales
-
On Sun, 13 Apr 2025 23:14:41 GMT, Magnus Ihse Bursie wrote:
>> Most of the JDK code base has been transitioned to UTF-8, but not all. This
>> has recently become an acute problem, since our mixing of iso-8859-1 and
>> utf-8 in properties files confused the version of `sed` th
cordingly (basically, updating compiler flags, git
> attributes, etc).
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Also tell javadoc that we have utf-8 now
-
Changes:
- all: https://git.openjdk.org/jd
On Thu, 10 Apr 2025 14:28:02 GMT, Magnus Ihse Bursie wrote:
> Most of the JDK code base has been transitioned to UTF-8, but not all. This
> has recently become an acute problem, since our mixing of iso-8859-1 and
> utf-8 in properties files confused the version of `sed` that is shi
This is a WIP to move the JDK source code base to fully UTF-8, and to ensure
tools knows about this.
-
Commit messages:
- Fix flags for Windows
- Mark java and native source code as utf-8
- Don't convert properties files to iso-8859-1.
- Tell tools we use utf-8
- Replace iso-885
On Fri, 11 Apr 2025 13:50:04 GMT, Alexey Semenyuk wrote:
>> Escape the dollar sign.
>
> Alexey Semenyuk has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Disable tex_math_dollars extension
Maybe wait for someone else to review the build chan
On Fri, 11 Apr 2025 13:33:09 GMT, Alexey Semenyuk wrote:
>> Escape the dollar sign.
>
> Alexey Semenyuk has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add missing backslash character
Try this patch:
diff --git a/make/autoconf/basic_tools
On Thu, 10 Apr 2025 21:50:10 GMT, Alexey Semenyuk wrote:
> Escape the dollar sign.
Oh, that's too bad. :( Weird that pandoc tries to modify stuff inside ``. I
think the better solution then is to pass `-tex_math_dollars` to pandoc to stop
it from trying to parse the dollar sign. We should not
On Fri, 11 Apr 2025 03:35:11 GMT, Sergey Bylokhov wrote:
>> I have checked the entire code base for incorrect encodings, but luckily
>> enough these were the only remaining problems I found.
>>
>> BOM (byte-order mark) is a method used for distinguishing big and little
>> endian UTF-16 encodi
On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie wrote:
> I have checked the entire code base for incorrect encodings, but luckily
> enough these were the only remaining problems I found.
>
> BOM (byte-order mark) is a method used for distinguishing big and little
>
On Thu, 10 Apr 2025 21:53:39 GMT, Alexey Semenyuk wrote:
>> I filed https://bugs.openjdk.org/browse/JDK-8354320 to fix the warning
>
> Adding backslash character (``) before the dollar character (`"${"` ->
> `"${"`) suppressed the warning, and the man page looks as expected.
>
> PR https://gith
On Thu, 10 Apr 2025 21:50:10 GMT, Alexey Semenyuk wrote:
> Escape the dollar sign.
I'm not entirely sure this is a good solution. Yes, it makes pandoc happy and
removes the warning, but this is using a pandoc extension and not standard
markdown. A standard markdown renderer will show this as t
On Thu, 10 Apr 2025 18:30:22 GMT, Eirik Bjørsnøs wrote:
>> If this is a French name, it's e acute: é.
>
>> If this is a French name, it's e acute: é.
>
> Supported by this Wikipedia page listing S.L as an LCMS developer:
>
> https://en.wikipedia.org/wiki/Little_CMS
It's not a mistake in capita
On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie wrote:
> I have checked the entire code base for incorrect encodings, but luckily
> enough these were the only remaining problems I found.
>
> BOM (byte-order mark) is a method used for distinguishing big and little
>
On Thu, 10 Apr 2025 19:06:35 GMT, Eirik Bjørsnøs wrote:
> (BTW, I enjoyed seeing separate commits for the encoding and BOM changes,
> makes it easier to verify each!)
Thanks! I do very much like myself to review PRs that has separate logical
commits, so I try to produce such myself. I'm glad t
I have checked the entire code base for incorrect encodings, but luckily enough
these were the only remaining problems I found.
BOM (byte-order mark) is a method used for distinguishing big and little endian
UTF-16 encodings. There is a special UTF-8 BOM, but it is discouraged. In the
words of
On Thu, 10 Apr 2025 11:46:45 GMT, Raffaello Giulietti
wrote:
> I guess the difference at L.1 in the various files is just the BOM?
Yes.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/24566#discussion_r2037357899
As a follow-up to [JDK-8354213](https://bugs.openjdk.org/browse/JDK-8354213), I
found some additional places where unicode characters are unnecessarily used
instead of pure ASCII.
-
Commit messages:
- 8354273: Restore even more pointless unicode characters to ASCII
Changes: https:
On Thu, 10 Apr 2025 14:42:26 GMT, Magnus Ihse Bursie wrote:
>> Alexey Semenyuk has refreshed the contents of this pull request, and
>> previous commits have been removed. The incremental views will show
>> differences compared to the previous content of the PR. The pull re
On Wed, 9 Apr 2025 20:56:03 GMT, Alexey Semenyuk wrote:
>> jpackage app laucnher will expand environment variables in .cfg files.
>>
>> Previously jpackage app launcher only replaced `$APPDIR`, `$BINDIR`, and
>> `$ROOTDIR` tokens with the corresponding path values. With this patch, any
>> envi
On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu wrote:
>> JDK .properties files still use ISO-8859-1 encoding with escape sequences.
>> It would improve readability to see the native characters instead of escape
>> sequences (especially for the L10n process). The majority of files changed
>> are l
On Thu, 10 Apr 2025 10:36:31 GMT, Magnus Ihse Bursie wrote:
>> As a follow-up to
>> [JDK-8354213](https://bugs.openjdk.org/browse/JDK-8354213), I found some
>> additional places where unicode characters are unnecessarily used instead of
>> pure ASCII.
>
> Magn
> As a follow-up to [JDK-8354213](https://bugs.openjdk.org/browse/JDK-8354213),
> I found some additional places where unicode characters are unnecessarily
> used instead of pure ASCII.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since
On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie wrote:
> I have checked the entire code base for incorrect encodings, but luckily
> enough these were the only remaining problems I found.
>
> BOM (byte-order mark) is a method used for distinguishing big and little
>
On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu wrote:
>> JDK .properties files still use ISO-8859-1 encoding with escape sequences.
>> It would improve readability to see the native characters instead of escape
>> sequences (especially for the L10n process). The majority of files changed
>> are l
On Thu, 10 Apr 2025 08:08:02 GMT, Eirik Bjørsnøs wrote:
>> If anything, I might be a bit worried that there are more incorrect
>> conversions stemming from this PR, that my automated tools and manual
>> scanning has not revealed.
>
> Some observations:
>
> 1: This PR seems to have been abondo
On Wed, 9 Apr 2025 21:26:15 GMT, Justin Lu wrote:
>> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties
>> line 22:
>>
>>> 20: # Peter Smolik
>>> 21: Cp1250 WINDOWS-1250 0x00FF
>>> 22: # Patch attributed to hava...@underdusken.no (H�vard Wigtil)
>>
>> Th
On Thu, 10 Apr 2025 07:31:37 GMT, Magnus Ihse Bursie wrote:
>> Right, that `å` looks to have been incorrectly converted during the
>> ISO-8859-1 to UTF-8 conversion. (I can't find the script used for conversion
>> as this change is from some time ago.)
>>
&g
On Wed, 9 Apr 2025 16:10:20 GMT, Severin Gehwolf wrote:
>> For JEP 493-enabled builds there are no JMODs. Certain files come from the
>> installed JDK image when a user creates a custom run-time from it. This is
>> problematic for example for files that often come from a different package
>> (
On Thu, 11 May 2023 20:21:57 GMT, Justin Lu wrote:
>> This PR converts Unicode sequences to UTF-8 native in .properties file.
>> (Excluding the Unicode space and tab sequence). The conversion was done
>> using native2ascii.
>>
>> In addition, the build logic is adjusted to support reading in t
On Wed, 9 Apr 2025 11:38:25 GMT, Severin Gehwolf wrote:
>> make/modules/jdk.jlink/Java.gmk line 28:
>>
>>> 26:
>>>
>>> 27:
>>> 28: COPY += upgrade_files_java.base
>>
>> Any chance you can give this file a differe
On Mon, 7 Apr 2025 13:35:57 GMT, Severin Gehwolf wrote:
>> For JEP 493-enabled builds there are no JMODs. Certain files come from the
>> installed JDK image when a user creates a custom run-time from it. This is
>> problematic for example for files that often come from a different package
>> (
On Tue, 8 Apr 2025 20:34:09 GMT, Chen Liang wrote:
> With all dependencies of com.sun.tools.classfile in the JDK converted to the
> ClassFile API, we can remove this legacy library for release 25 like how we
> removed ASM.
>
> Testing: built locally, running tier 1-3 tests
>
> Don't know why,
On Fri, 14 Mar 2025 11:15:26 GMT, Matthias Baesken wrote:
> On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are
> most likely not needed any more and could be removed.
> The removal (on Linux) brings the lib optimization level de facto from LOW to
> HIGH.
Marked as rev
1 - 100 of 774 matches
Mail list logo
