On Fri, 13 May 2022 16:53:00 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
for Windows, and at the of the
> day, testing file unreadability is not an important regression test for
> [JDK-4354216](https://bugs.openjdk.org/browse/JDK-4354216).
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
From
On Tue, 7 Jun 2022 12:19:29 GMT, Magnus Ihse Bursie wrote:
> The test
> `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java`
> verifies different failure modes of resource bundles. One of the failures is
> that the runner class, `MissingResourceCause
On Wed, 8 Jun 2022 17:43:49 GMT, Naoto Sato wrote:
>> The test
>> `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java`
>> verifies different failure modes of resource bundles. One of the failures is
>> that the runner class, `MissingResourceCauseTestRun.java`, creates a f
On Tue, 7 Jun 2022 10:14:47 GMT, Magnus Ihse Bursie wrote:
> The test `test/jdk/java/util/Currency/PropertiesTest.sh` fails on msys2,
> since it does not properly detect this environment.
This pull request has now been integrated.
Changeset: f1dd559e
Author:Magnus Ihse Bursi
The test `test/jdk/java/util/Currency/PropertiesTest.sh` fails on msys2, since
it does not properly detect this environment.
-
Commit messages:
- 8287896: PropertiesTest.sh fail on msys2
Changes: https://git.openjdk.java.net/jdk/pull/9057/files
Webrev: https://webrevs.openjdk.java
On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov wrote:
> Replaces usages of articles that follow each other in all combinations:
> a/the, an?/an?, the/the…
>
> It's the last issue in the series, and it still touches different areas of
> the code.
Build changes look good. Thanks for the cleanu
On Thu, 28 Apr 2022 21:25:02 GMT, Alexey Ivanov wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with 17
>> additional commits since the last revision:
>>
>> - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>>
On Thu, 28 Apr 2022 20:37:22 GMT, Alexey Ivanov wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with 17
>> additional commits since the last revision:
>>
>> - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>>
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 17
additional commits since the last revision
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 four
additional commits since the last revisi
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 revisi
On Thu, 28 Apr 2022 16:48:04 GMT, Alexey Ivanov wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with four
>> additional commits since the last revision:
>>
>> - Update src/java.desktop/share/classes/javax/swing/JLayeredPane.java
>>
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 four
additional commits since the last revisi
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 14
additional commits since the last revisio
On Thu, 21 Apr 2022 11:34:14 GMT, Magnus Ihse Bursie wrote:
> `codespell` could just find a single typo in the files covered by the i18n
> alias. Just fixing the typo did not make the comment more readable, so I
> rewrote it slightly.
This pull request has now been integrated.
On Thu, 21 Apr 2022 11:47:30 GMT, Alan Bateman wrote:
>> `codespell` could just find a single typo in the files covered by the i18n
>> alias. Just fixing the typo did not make the comment more readable, so I
>> rewrote it slightly.
>
> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM942C.java.
`codespell` could just find a single typo in the files covered by the i18n
alias. Just fixing the typo did not make the comment more readable, so I
rewrote it slightly.
-
Commit messages:
- Fix typo in charsets
Changes: https://git.openjdk.java.net/jdk/pull/8335/files
Webrev: htt
On Mon, 18 Apr 2022 23:16:18 GMT, Naoto Sato wrote:
> Fixing performance regression caused by the fix to
> https://bugs.openjdk.java.net/browse/JDK-8176706. The fix introduced extra
> looping through the resource map multiple times which was not necessary. The
> execution time of the tool now
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 without much fanfare, if they are in internal classes. Typos in exposed APIs
are likely here
On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie wrote:
> I ran `codespell` on the `src/java.base` directory, and accepted those
> changes where it indeed discovered real typos.
>
> (Due to false positives this can unfortunately not be run automatically)
>
> The majori
> local variable name, and a couple in parameter declarations.
>
> Annoyingly, there are several instances of "childs" (instead of "children")
> in the source code, but they were not local and I dared not change them.
> Someone braver than me might take a stab
On Tue, 19 Apr 2022 16:24:43 GMT, Magnus Ihse Bursie wrote:
>> I ran `codespell` on the `src/java.base` directory, and accepted those
>> changes where it indeed discovered real typos.
>>
>> (Due to false positives this can unfortunately not be run automatically)
>
> local variable name, and a couple in parameter declarations.
>
> Annoyingly, there are several instances of "childs" (instead of "children")
> in the source code, but they were not local and I dared not change them.
> Someone braver than me might take a stab
> local variable name, and a couple in parameter declarations.
>
> Annoyingly, there are several instances of "childs" (instead of "children")
> in the source code, but they were not local and I dared not change them.
> Someone braver than me might take a stab
On Thu, 14 Apr 2022 16:05:48 GMT, Magnus Ihse Bursie wrote:
> I ran `codespell` on the `make` directory, and accepted those changes where
> it indeed discovered real typos.
>
> (Due to false positives this can unfortunately not be run automatically)
>
> Most of the fixes
I ran `codespell` on the `src/java.base` directory, and accepted those changes
where it indeed discovered real typos.
(Due to false positives this can unfortunately not be run automatically)
The majority of fixes are in comments. A handful is in strings, one in a local
variable name, and a cou
I ran `codespell` on the `make` directory, and accepted those changes where it
indeed discovered real typos.
(Due to false positives this can unfortunately not be run automatically)
Most of the fixes are in comments. A few are in messages aimed at the user.
-
Commit messages:
- 8
On Thu, 14 Apr 2022 09:28:17 GMT, Andrey Turbanov wrote:
>> Found various typos of expected: `exepected`, `exept`, `epectedly`,
>> `expeced`, `Unexpeted`, etc.
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8284853: Fi
On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato wrote:
> This is to upgrade the CLDR data from version 39 to version 41 which was
> released yesterday. The vast majority of the changes are basically replacing
> the CLDR data, along with tools/testcase alignments. Here is the link to CLDR
> v41's r
On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato wrote:
> This is to upgrade the CLDR data from version 39 to version 41 which was
> released yesterday. The vast majority of the changes are basically replacing
> the CLDR data, along with tools/testcase alignments. Here is the link to CLDR
> v41's r
On Thu, 3 Dec 2020 23:44:20 GMT, Magnus Ihse Bursie wrote:
> A lot (but not all) of the data in make/data is tied to a specific module.
> For instance, the publicsuffixlist is used by java.base, and fontconfig by
> java.desktop. (A few directories, like mainmanifest, is *actually
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [x] java.desktop
&
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [x] java.desktop
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [x] java.desktop
&
On Fri, 18 Mar 2022 21:24:43 GMT, Phil Race wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix typos
>
> This doesn't seem right to me to put x11wrappergen into share.
&
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [x] java.desktop
&
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [x] java.desktop
> 18 mars 2022 kl. 11:04 skrev Alan Bateman :
>
> I can't tell if you are planning to integrate this or wait until there is
> discussion on the locations proposed in the Informational JEP that you've
> just submitted. Maybe you plan to just integrate and then adjust/move again
> if needed?
I
On Wed, 16 Dec 2020 18:34:37 GMT, Naoto Sato wrote:
>>> @AlanBateman The process of modularization was not fully completed with
>>> Project Jigsaw, and a few ugly warts remained. I was under the impression
>>> that these should be addressed in follow-up fixes, but this was
>>> unfortunately ne
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [x] java.desktop
&
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [x] java.desktop
&
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [x] java.desktop
&
On Wed, 16 Mar 2022 21:31:08 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 pull request now contains 12 commits:
>>
>> - Merge branch 'master' into shuffle-data-reborn
>&
On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module.
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by
>> java.desktop. (A few directories, like mainmanifest, is
at sound okay to you?
/Magnus
-Alan
On 15/03/2022 23:59, Magnus Ihse Bursie wrote:
On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie
wrote:
A lot (but not all) of the data in make/data is tied to a specific
module. For instance, the publicsuffixlist is used by java.base,
and fontconfig
On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module.
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by
>> java.desktop. (A few directories, like mainmanifest, is
On Mon, 18 Jan 2021 13:47:20 GMT, Magnus Ihse Bursie wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module.
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by
>> java.desktop. (A few directories, like mainmanifest, is
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [x] java.desktop
On Thu, 3 Mar 2022 16:55:46 GMT, Tim Prinzing wrote:
>> The caller class returned by Reflection::getCallerClass was used to gain
>> access to it's module in most cases and class loader in one case. I added a
>> method to translate the caller class to caller module so that the decision
>> of wh
On Mon, 7 Mar 2022 16:40:15 GMT, Lance Andersen wrote:
>> Hi
>>
>> I have reviewed the code for removing double semicolons at the end of lines
>>
>> all the best
>> matteo
>
> What problem are you having editing the PR header? You should be able to do
> so as the author of the PR
@LanceAnde
On Fri, 4 Mar 2022 17:17:12 GMT, Roger Riggs wrote:
>> Hi
>>
>> I have reviewed the code for removing double semicolons at the end of lines
>>
>> all the best
>> matteo
>
> We usually request that these be be broken up by area to attract the
> appropriate reviewers and avoid eye-strain. The c
On Tue, 16 Mar 2021 21:02:28 GMT, Claes Redestad wrote:
>> This patch changes the otherLowercase / otherUppercase bits to be set if
>> either the codepoint is of type LOWERCASE_LETTER and UPPERCASE_LETTER, or
>> the Unicode Other_Lowercase / Other_Uppercase property is set. This
>> simplifies
On Tue, 26 Jan 2021 10:35:03 GMT, Magnus Ihse Bursie wrote:
> For java.base gensrc we do the following:
>
> # Copy two Java files that need no preprocessing.
> $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/%.java:
> $(CHARACTERDATA_TEMPLATES)/%.java.template
> $(call LogInf
For java.base gensrc we do the following:
# Copy two Java files that need no preprocessing.
$(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/%.java:
$(CHARACTERDATA_TEMPLATES)/%.java.template
$(call LogInfo, Generating $(@F))
$(call install-file)
GENSRC_CHARACTERDATA +=
$(SUPPORT_OUTPUTDIR)/gens
On Sat, 23 Jan 2021 07:55:09 GMT, Alan Bateman wrote:
> We should create a separate issue to rename them and get rid of the copying
> in the make file.
I opened https://bugs.openjdk.java.net/browse/JDK-8260406.
-
PR: https://git.openjdk.java.net/jdk/pull/1611
On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman wrote:
>> This PR is not stale; it's just still waiting for input from @AlanBateman.
>
> @magicus Can the CharacterDataXXX.template files move to
> src/java.base/share/classes/java/lang?
@AlanBateman When I moved the charset templates, I found this
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [x] java.desktop
&
On 2021-01-15 19:27, mark.reinh...@oracle.com wrote:
Feature JEPs are living documents until such time as they are delivered.
In this case it would not be appropriate to update JEP 201, which is as
much about the transition from the old source-code layout as it is about
the new layout as of 2014.
On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman wrote:
>> This PR is not stale; it's just still waiting for input from @AlanBateman.
>
> @magicus Can the CharacterDataXXX.template files move to
> src/java.base/share/classes/java/lang?
@AlanBateman That sounds like an excellent idea. I'll update
On Mon, 4 Jan 2021 21:20:53 GMT, Phil Race 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 ei
On Wed, 16 Dec 2020 10:12:54 GMT, Alan Bateman wrote:
>> I think this is almost ready to be pushed, but I'd like to have someone from
>> the client team review the changes for java.desktop as well. @prrace Any
>> change you can have a look at this?
>
> I think it will be annoying to have the ch
On Thu, 10 Dec 2020 23:07:52 GMT, Naoto Sato wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move to share/data, and move jdwp.spec to java.se
>
> Reviewed changes to `character
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [ ] java.desktop
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [ ] java.base
> - [ ] java.desktop
&
On Tue, 15 Dec 2020 01:41:07 GMT, Joe Wang wrote:
>> I agree that there is room for improvement here. How about:
>> "...an allow-list too restrictively, or a reject-list too broadly, may..."
>> ?
>
> Your call, I'm not a native English speaker :-) It felt to me it's
> 'restrictive' than 'restr
On Tue, 8 Dec 2020 17:33:16 GMT, Alan Bateman wrote:
>> The mapping and nr tables, and the *-X.java.template files in
>> make/data/charsetmapping are used to generate source code for the java.base
>> and jdk.charsets modules. The stdcs-$OS files configure the package and
>> module that each ch
On Tue, 8 Dec 2020 15:25:47 GMT, Weijun Wang wrote:
>> The mapping and nr tables, and the *-X.java.template files in
>> make/data/charsetmapping are used to generate source code for the java.base
>> and jdk.charsets modules. The stdcs-$OS files configure the package and
>> module that each cha
On Tue, 8 Dec 2020 12:15:38 GMT, Alan Bateman wrote:
>> Also, to clarify, for me there is a fundamental difference between
>> `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files
>> that are part of the module, owned by the content team, and the `$MODULE`
>> part is essent
On Tue, 8 Dec 2020 08:27:16 GMT, Magnus Ihse Bursie wrote:
>> Hi Magnus,
>>
>> I see the motivation of moving these build files for better identification
>> of ownership. Placing them under
>> `src/$MODULE/{share,$OS}/data` is one option. Given that skara wi
On Tue, 8 Dec 2020 02:40:43 GMT, Mandy Chung wrote:
>> I have reviewed all lines in the patch file with or near instances of
>> `jdk.compiler`
>
> Hi Magnus,
>
> I see the motivation of moving these build files for better identification of
> ownership. Placing them under
> `src/$MODULE/{shar
On Mon, 7 Dec 2020 14:20:07 GMT, Magnus Ihse Bursie wrote:
>> @erikj79 Good point, that makes much more sense.
>
> I'm not sure about the formal process for suggesting changes to a delivered
> JEP, but this is the text I suggest should replace the current definition
On Fri, 4 Dec 2020 15:17:06 GMT, Magnus Ihse Bursie wrote:
>> Regarding the chosen layout. Did you consider following the existing pattern
>> of src//{share,}/data?
>
> @erikj79 Good point, that makes much more sense.
I'm not sure about the formal process for suggesting
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
Magnus Ihse Bursie has updated the pull request incrementally with one
additio
On Fri, 4 Dec 2020 14:05:54 GMT, Erik Joelsson wrote:
>> My understanding of JEPs is that they should be viewed as living documents.
>> In this case, I think it's perfectly valid to update JEP 201 with additional
>> source code layout. Both for this and for the other missing dirs.
>
> Regarding
On Fri, 4 Dec 2020 11:37:41 GMT, Magnus Ihse Bursie wrote:
>> Are you proposing any text or guidelines to be added to JEP 201 as part of
>> this?
>>
>> I think the location of jdwp.spec and its location in the build tree may
>> need to be looked at again. It wa
On Fri, 4 Dec 2020 11:14:49 GMT, Alan Bateman wrote:
>> To facilitate review, here is a list on how the different directories under
>> make/data has moved.
>>
>> **To java.base:**
>> * blacklistedcertsconverter
>> * cacerts
>> * characterdata
>> * charsetmapping
>> * cldr
>> * currency
>> * lsr
On Thu, 3 Dec 2020 23:44:20 GMT, Magnus Ihse Bursie wrote:
> A lot (but not all) of the data in make/data is tied to a specific module.
> For instance, the publicsuffixlist is used by java.base, and fontconfig by
> java.desktop. (A few directories, like mainmanifest, is *actually
A lot (but not all) of the data in make/data is tied to a specific module. For
instance, the publicsuffixlist is used by java.base, and fontconfig by
java.desktop. (A few directories, like mainmanifest, is *actually* used by make
for the whole build.)
These data files should move to the module
On 2018-09-18 19:41, Naoto Sato wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8209880
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8209880/webrev.00/
Looks good. Thank you for fixing this!
/Magnus
The fix
dency, yes that's a separate
issue. Since it's obvious, I included the fix with this changeset (it
was actually described as a comment in the jira issue).
Naoto
On 9/12/18 9:08 AM, Erik Joelsson wrote:
On 2018-09-12 03:19, Magnus Ihse Bursie wrote:
On 2018-09-10 23:34, Naoto Sato wr
On 2018-09-12 12:19, Magnus Ihse Bursie wrote:
On 2018-09-10 23:34, Naoto Sato wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8209167
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8209167/webrev.01/
Oh
On 2018-09-10 23:34, Naoto Sato wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8209167
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8209167/webrev.01/
Some comments:
In make/copy/Copy-java.base.gmk:
+ifneq (
On 2014-10-23 22:05, Naoto Sato wrote:
I revised the fix according to the suggestions I got. The main change
is to rename the name of the locale data modules. Now we have two as
follows:
- jdk.localedata.classic: Legacy locale data
- jdk.localedata.cldr: CLDR locale data
Revised webrev is loc
On 2014-09-17 11:36, Erik Joelsson wrote:
On 2014-09-16 23:03, Naoto Sato wrote:
I revised the fix based on suggestions from Erik/Magnus. I just ended
up creating Gensrc-jdk.localedata.gmk, instead of renaming
GensrcCLDR.gmk because GensrcLocaleData.gmk (formerly
GensrcLocaleDataMetaInfo.gmk)
On 2014-09-16 09:41, Erik Joelsson wrote:
Hello Naoto,
From what I can see, this means that GensrcCLDR.gmk now only generates
source for the jdk.localedata module. This means that
Gensrc-java.base.gmk should no longer include GensrcCLDR.gmk and
GensrcCLDR.gmk should be renamed to Gensrc-jdk.l
On 2014-02-10 09:23, Masayoshi Okutsu wrote:
I wonder if we can utilize the locale matching mechanism rather than
tweaking the makefile. zh-CN and zh-Hans-CN can be treated as
equivalents for looking up the JRE locales.
I think that would be good. Do you think it is possible? We are already
do
87 matches
Mail list logo
