ing `codespell`.
> The trouble with automating this is of course all false positives. But before
> even trying to solve that issue, all true positives must be fixed. Hence this
> PR.
Magnus Ihse Bursie has updated the pull request incrementally with two
additional commits since the last revi
ing `codespell`.
> The trouble with automating this is of course all false positives. But before
> even trying to solve that issue, all true positives must be fixed. Hence this
> PR.
Magnus Ihse Bursie has updated the pull request with a new target base due to a
merge or a rebase. The pull requ
On Tue, 6 Sep 2022 12:29:23 GMT, Magnus Ihse Bursie wrote:
>> I ran `codespell` on the `src/java.desktop` directory, and accepted those
>> changes where it indeed discovered real typos.
>>
>> I ignored typos in public methods and variables. Maybe they can be fixed
On Tue, 13 Sep 2022 19:48:47 GMT, Alexey Ivanov wrote:
>> 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 46 commits:
>>
>> - Merge branch 'master' into typos-in-java.deskt
On Tue, 13 Sep 2022 20:04:17 GMT, Alexey Ivanov wrote:
> Is `src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c` a
> third-party code?
I don't think so. I find no comments in the source code, or any kind of
indication on this being so. If you say it is, I can revert the changes in
On Tue, 6 Sep 2022 12:42:05 GMT, Magnus Ihse Bursie wrote:
>> I ran `codespell` on the `src/java.desktop` directory, and accepted those
>> changes where it indeed discovered real typos.
>>
>> I ignored typos in public methods and variables. Maybe they can be fixed
ing `codespell`.
> The trouble with automating this is of course all false positives. But before
> even trying to solve that issue, all true positives must be fixed. Hence this
> PR.
Magnus Ihse Bursie has updated the pull request incrementally with two
additional commits since the last revi
ing `codespell`.
> The trouble with automating this is of course all false positives. But before
> even trying to solve that issue, all true positives must be fixed. Hence this
> PR.
Magnus Ihse Bursie has updated the pull request with a new target base due to a
merge or a rebase. The pull requ
On Tue, 13 Sep 2022 22:03:44 GMT, Phil Race wrote:
>> I see now that Phil cryptically said:
>>
>>> Regarding changes in gif + freetype
>> diff --git a/src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c
>> b/src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c \
>> \
>> d
On Tue, 13 Sep 2022 22:03:44 GMT, Phil Race wrote:
>> I see now that Phil cryptically said:
>>
>>> Regarding changes in gif + freetype
>> diff --git a/src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c
>> b/src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c \
>> \
>> d
ing `codespell`.
> The trouble with automating this is of course all false positives. But before
> even trying to solve that issue, all true positives must be fixed. Hence this
> PR.
Magnus Ihse Bursie has updated the pull request with a new target base due to a
merge or a rebase. The pull requ
On Thu, 21 Apr 2022 08:35:36 GMT, Magnus Ihse Bursie wrote:
> I ran `codespell` on the `src/java.desktop` directory, and accepted those
> changes where it indeed discovered real typos.
>
> I ignored typos in public methods and variables. Maybe they can be fixed
> later on witho
Properties files is essentially source code. It should have the same whitespace
checks as all other source code, so we don't get spurious trailing whitespace
changes.
With the new Skara jcheck, it is possible to increase the coverage of the
whitespace checks (in the old mercurial version, this
On Thu, 20 Oct 2022 18:38:43 GMT, Andy Goryachev wrote:
>> Properties files is essentially source code. It should have the same
>> whitespace checks as all other source code, so we don't get spurious
>> trailing whitespace changes.
>>
>> With the new Skara jcheck, it is possible to increase th
On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie wrote:
> Properties files is essentially source code. It should have the same
> whitespace checks as all other source code, so we don't get spurious trailing
> whitespace changes.
>
> With the new Skara jcheck, it is
s (in the old mercurial version, this was more or less
> impossible).
>
> The only manual change is to `.jcheck/conf`. All other changes were made by
> running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[
> \t]*$//'`.
Magnus Ihse Bursie has u
On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie wrote:
>> Properties files is essentially source code. It should have the same
>> whitespace checks as all other source code, so we don't get spurious
>> trailing whitespace changes.
>>
>> With the
s (in the old mercurial version, this was more or less
> impossible).
>
> The only manual change is to `.jcheck/conf`. All other changes were made by
> running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[
> \t]*$//'`.
Magnus Ihse Bursie has u
On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote:
>> Properties files is essentially source code. It should have the same
>> whitespace checks as all other source code, so we don't get spurious
>> trailing whitespace changes.
>>
>> With the
On Mon, 24 Oct 2022 19:20:24 GMT, Andy Goryachev wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove check for .properties from jcheck
>> - Restore trailing whitespace for
On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote:
>> Properties files is essentially source code. It should have the same
>> whitespace checks as all other source code, so we don't get spurious
>> trailing whitespace changes.
>>
>> With the
On Mon, 24 Oct 2022 19:39:21 GMT, Jonathan Gibbons wrote:
> I think it would be better to try and remove incidental trailing whitespace
> first, before encoding any remaining whitespace. Hiding the trailing
> whitespace as a Unicode escape seems like a bad idea, equivalent to sweeping
> the is
On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote:
>> Properties files is essentially source code. It should have the same
>> whitespace checks as all other source code, so we don't get spurious
>> trailing whitespace changes.
>>
>> With the
On Fri, 2 Dec 2022 16:40:51 GMT, Magnus Ihse Bursie wrote:
> According to [the
> specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader))
> trailing whitespaces in the values of properties files are (somewhat
>
According to [the
specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader))
trailing whitespaces in the values of properties files are (somewhat
surprisingly) actually significant.
We have multiple files in the JDK with trailing
On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote:
>> Properties files is essentially source code. It should have the same
>> whitespace checks as all other source code, so we don't get spurious
>> trailing whitespace changes.
>>
>> With the
On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie wrote:
> Properties files is essentially source code. It should have the same
> whitespace checks as all other source code, so we don't get spurious trailing
> whitespace changes.
>
> With the new Skara jcheck, it is
[JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an
attempt to remove all trailing whitespace from properties files, and enable a
jcheck verification that they did not come back, similar to other source code.
It turned out that this was not so simple, however, since trai
On Fri, 2 Dec 2022 17:12:55 GMT, Andy Goryachev wrote:
>> This turned out to be much more complicated than anticipated. I am going to
>> close this PR (and bug), and instead I have split up this work in five
>> different bugs:
>>
>> [JDK-8298047](https://bugs.openjdk.org/browse/JDK-8298047) is
ith
> significance. These changes were in turned created by running `find . -type
> f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
Magnus Ihse Bursie has updated the pull request with a new target base due to a
merge or a rebase. The pull request now conta
On Fri, 2 Dec 2022 17:06:23 GMT, Magnus Ihse Bursie wrote:
> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an
> attempt to remove all trailing whitespace from properties files, and enable a
> jcheck verification that they did not come back, similar to oth
On Mon, 16 Jan 2023 17:22:36 GMT, Roger Riggs wrote:
>> 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 two commits:
>>
>> - Merge branch 'master' into properties-eol-clean-
On Fri, 2 Dec 2022 17:06:23 GMT, Magnus Ihse Bursie wrote:
> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an
> attempt to remove all trailing whitespace from properties files, and enable a
> jcheck verification that they did not come back, similar to oth
On Tue, 17 Jan 2023 11:44:32 GMT, Vladimir Sitnikov
wrote:
>> @RogerRiggs Thanks!
>
> @magicus , have you considered adding `.editorconfig` file (see
> https://editorconfig.org/ ) so it configures developers' editors to trim the
> whitespace?
>
> Of course, `.editorconfig` does not enforce th
On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen wrote:
>> Open l10n drop. Files have been updated with translated versions. Whitespace
>> tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional
> commit since the last revisi
On Fri, 2 Dec 2022 16:40:51 GMT, Magnus Ihse Bursie wrote:
> According to [the
> specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader))
> trailing whitespaces in the values of properties files are (somewhat
>
On Mon, 6 Mar 2023 20:22:48 GMT, Pavel Rappo wrote:
>> Please review this superficial documentation cleanup that was triggered by
>> unrelated analysis of doc comments in JDK API.
>>
>> The only effect that this multi-area PR has on the JDK API Documentation
>> (i.e. the observable effect on t
On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote:
> There are a number of files in the `test` directory that have an incorrect
> copyright header, which includes the "classpath" exception text. This patch
> removes that text from all test files that I could find it in. I did this
> using a
On Tue, 17 Oct 2023 16:52:12 GMT, Naoto Sato wrote:
>> CLDR provides very few short names for time zones, such as PST/PDT. This
>> will typically end up substituting names from the COMPAT provider. Once the
>> COMPAT is removed, they will be displayed in the GMT format, i.e.,
>> GMT+XX:YY. Alt
On Wed, 18 Oct 2023 15:43:12 GMT, Naoto Sato wrote:
>> CLDR provides very few short names for time zones, such as PST/PDT. This
>> will typically end up substituting names from the COMPAT provider. Once the
>> COMPAT is removed, they will be displayed in the GMT format, i.e.,
>> GMT+XX:YY. Alt
Over the year, even though we have tried to be diligent, there have been
commits that modify files without updating the copyright year. Here is a mass
update of the copyright years in the build system (`make/**`, `.github/**`).
Feel free to verify that these files have indeed been modified in 2
On Wed, 17 Jan 2024 21:22:07 GMT, Pavel Rappo wrote:
> Please review this trivial PR to reorder the `sealed` class or interface
> modifier. For context of this change see:
> https://github.com/openjdk/jdk/pull/17242#issuecomment-1887338396.
Thanks! When this has been integrated, I can take a s
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the warni
This is an attempt to finally implement the idea brought forward in
JDK-8295729: Properties files is essentially source code. It should have the
same whitespace checks as all other source code, so we don't get spurious
trailing whitespace changes or leading tabs instead of spaces.
With Skara
On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote:
> This is an attempt to finally implement the idea brought forward in
> JDK-8295729: Properties files is essentially source code. It should have the
> same whitespace checks as all other source code, so we don'
On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote:
> This is an attempt to finally implement the idea brought forward in
> JDK-8295729: Properties files is essentially source code. It should have the
> same whitespace checks as all other source code, so we don'
On Fri, 9 Feb 2024 18:09:11 GMT, Naoto Sato wrote:
>> This is an attempt to finally implement the idea brought forward in
>> JDK-8295729: Properties files is essentially source code. It should have
>> the same whitespace checks as all other source code, so we don't get
>> spurious trailing wh
On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote:
> This is an attempt to finally implement the idea brought forward in
> JDK-8295729: Properties files is essentially source code. It should have the
> same whitespace checks as all other source code, so we don'
On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie wrote:
> Since jcheck only checks file in a commit, there is a possibility of us
> getting files in the repository that would not be accepted by jcheck. This
> can happen when extending the set of files checked by jcheck, or
Since jcheck only checks file in a commit, there is a possibility of us getting
files in the repository that would not be accepted by jcheck. This can happen
when extending the set of files checked by jcheck, or if jcheck changes how it
checks files (perhaps due to bug fixes).
I have now run jc
On Thu, 15 Feb 2024 14:01:46 GMT, Erik Joelsson wrote:
>> test/jdk/java/util/Currency/currency.properties line 18:
>>
>>> 16: SB=EUR,111,2, 2099-01-01T00:00:00
>>> 17: US=euR,978,2,2001-01-01T00:00:00
>>> 18: ZZ = ZZZ , 999 , 3
>>
>> This looks weird, but so did t
xes).
>
> I have now run jcheck over the entire code base, and fixed a handful of
> issues. With these changes, jcheck accept the entire code base.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Replace spaces with \t in
On Thu, 15 Feb 2024 17:53:41 GMT, Naoto Sato wrote:
>> `\u000b` is VT (vertical tab)
>> `\u0009` or `\t` perhaps?
>
> Right. `\t` is better to avoid such a mistake.
Ok, fixed.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1492403403
On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie wrote:
> Since jcheck only checks file in a commit, there is a possibility of us
> getting files in the repository that would not be accepted by jcheck. This
> can happen when extending the set of files checked by jcheck, or
On Mon, 26 Feb 2024 14:20:40 GMT, Erik Joelsson wrote:
>> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The
>> `COMPAT` locale data was introduced for applications' migratory purposes
>> transitioning to `CLDR`. It is becoming a technical debt and now is the time
>> t
On Mon, 26 Feb 2024 16:33:02 GMT, Magnus Ihse Bursie wrote:
>> make/modules/java.base/gensrc/GensrcLocaleData.gmk line 58:
>>
>>> 56: ifeq ($(MODULE), jdk.localedata)
>>> 57: $(shell $(RM)
>>> $(SUPPORT_OUTPUTDIR)/gensrc/jdk.loca
On Tue, 27 Feb 2024 00:24:08 GMT, Naoto Sato wrote:
>> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The
>> `COMPAT` locale data was introduced for applications' migratory purposes
>> transitioning to `CLDR`. It is becoming a technical debt and now is the time
>> to r
On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loa
On Sun, 3 Nov 2024 03:17:14 GMT, Archie Cobbs wrote:
>> Please review this patch which removes unnecessary `@SuppressWarnings`
>> annotations and `-Xlint:-foo` options.
>
> Archie Cobbs has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excl
On Sun, 3 Nov 2024 03:17:14 GMT, Archie Cobbs wrote:
>> Please review this patch which removes unnecessary `@SuppressWarnings`
>> annotations and `-Xlint:-foo` options.
>
> Archie Cobbs has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excl
On Sun, 3 Nov 2024 03:17:14 GMT, Archie Cobbs wrote:
>> Please review this patch which removes unnecessary `@SuppressWarnings`
>> annotations and `-Xlint:-foo` options.
>
> Archie Cobbs has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excl
On Thu, 24 Oct 2024 14:22:28 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and locals that trigger the
>> u
On Thu, 14 Nov 2024 15:23:35 GMT, Jonathan Gibbons wrote:
> The policy has long been to use Classpath Exception in the src and make
> directories, but not in the test directories. If you're changing the policy,
> you might want to check and update any documentation where the policy might
> be
In several (most? all?) of the build system files, the copyright header
includes the classpath exception. This makes no sense, and should be removed.
I have removed the classpath exception from makefiles, autoconf, shell scripts,
properties files, configuration files, IDE support files, build t
Some files have been modified in 2024, but the copyright year has not been
properly updated. This should be fixed.
I have located these modified files using:
git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
and then run a script to update the copyright year to 2024 on
Some files have been modified in 2024, but the copyright year has not been
properly updated. This should be fixed.
I have located these modified files using:
git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
and then run a script to update the copyright year to 2024 on
; and then run a script to update the copyright year to 2024 on these files.
>
> I have made a manual sampling of files in the list to verify that they have
> indeed been modified in 2024.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit sin
; and then run a script to update the copyright year to 2024 on these files.
>
> I have made a manual sampling of files in the list to verify that they have
> indeed been modified in 2024.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since
On Mon, 9 Dec 2024 18:13:25 GMT, Phil Race wrote:
> There's an image (JPG) file in this list ! Why ?
That is indeed a very good question. I got a few other modified binary files as
well; I can't say why. I am basically doing a sed for `Copyright (c) ...
Oracle`, and I have double-checked that
; and then run a script to update the copyright year to 2024 on these files.
>
> I have made a manual sampling of files in the list to verify that they have
> indeed been modified in 2024.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last
On Mon, 9 Dec 2024 15:26:00 GMT, Kevin Walls wrote:
> I also meant to note that there are updates to binaries,
> src/java.base/share/classes/jdk/internal/icu/impl/data/icudt76b/... which
> maybe isn't intentional, or I just don't understand?
That was certainly not intentional! I'm not sure how
; and then run a script to update the copyright year to 2024 on these files.
>
> I have made a manual sampling of files in the list to verify that they have
> indeed been modified in 2024.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the la
On Mon, 9 Dec 2024 15:16:10 GMT, Roger Riggs wrote:
> That git query isn't correct for all the files in the repo. In particular,
> the copyrights on third party files are NOT updated uniformly when new
> versions are applied. In particular, XML files are NOT updated.
I'm not sure I understand
On Mon, 9 Dec 2024 12:30:19 GMT, Magnus Ihse Bursie wrote:
> Some files have been modified in 2024, but the copyright year has not been
> properly updated. This should be fixed.
>
> I have located these modified files using:
>
> git log --since="Jan 1" --name-onl
On Tue, 10 Dec 2024 09:31:21 GMT, Prasanta Sadhukhan
wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert changes to binary files
>
> not sure why client label is added,
On Mon, 9 Dec 2024 12:16:26 GMT, Magnus Ihse Bursie wrote:
> Some files have been modified in 2024, but the copyright year has not been
> properly updated. This should be fixed.
>
> I have located these modified files using:
>
> git log --since="Jan 1" --name-onl
On Tue, 10 Dec 2024 02:50:18 GMT, Prasanta Sadhukhan
wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert mistakenly modified binary files
>
> src/jdk.accessibility/w
ption.
>
> This is a huge and autogenerated, but content-wise trivial, PR, and I know
> such are hard to review. I recommend looking at the entire diff file instead
> of checking this file-by-file in the Github web GUI. (That's bound to be a
> painful experience)
Magnus Ihse Bursie h
On Wed, 29 Jan 2025 16:03:38 GMT, Nizar Benalla wrote:
> Two groups of broken links appeared in the latest JDK docs, broken links to
> man pages and broken ietf links.
>
> - The windows tools markdown files were not being converted to HTML because
> they were placed under `windows/man` rather
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 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 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
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
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 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
>
> 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: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
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 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 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 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
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 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 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
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 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 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
1 - 100 of 151 matches
Mail list logo
