On Fri, 13 May 2022 04:41:03 GMT, ExE Boss wrote:
>> Roger Riggs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Updated copyrights
>> Fixed cast style to add a space after cast, (where consistent with file
>> style)
>> Improved cod
On Wed, 11 May 2022 16:30:41 GMT, Roger Riggs wrote:
>> PR#8599 8244681: proposes to add compiler warnings for possible lossy
>> conversions
>> From the CSR:
>>
>> "If the type of the right-hand operand of a compound assignment is not
>> assignment compatible with the type of the variable, a c
On Tue, 10 May 2022 23:01:33 GMT, Roger Riggs wrote:
>> PR#8599 8244681: proposes to add compiler warnings for possible lossy
>> conversions
>> From the CSR:
>>
>> "If the type of the right-hand operand of a compound assignment is not
>> assignment compatible with the type of the variable, a c
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.
Marked as reviewed by alanb (Reviewer).
src/jdk.charsets/s
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 majority of fixes are in c
On Thu, 17 Mar 2022 00:12:38 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* used by
On Thu, 17 Mar 2022 00:12:38 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* used by
On 16/03/2022 08:44, Magnus Ihse Bursie wrote:
:
If you have such strong opinions on the data files shared between
java.base and jdk.charsets/jdk.localedata, I propose we leave them in
make/data for the time being, clean up the associated mess, and then
work out where they actually should be.
Magnus,
This proposal does not address the previous concerns. As before, you are
proposing to put the data files used to generate the classes for
jdk.localedata and jdk.charsets into src/java.base and I don't think we
should do that. I really think this PR needs to be withdraw n or closed
unt
On Thu, 10 Mar 2022 18:40:13 GMT, Zhengyu Gu wrote:
> Please review this small patch that fixes early `CHECK_NULL_RETURN` results
> not releasing native `jchar` array returned by `GetStringChars()`.
Marked as reviewed by alanb (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pul
On Fri, 21 Jan 2022 19:28:21 GMT, Daniel Jeliński wrote:
> Reported by clang-tidy. Verified manually by running
>
> Calendar c = Calendar.getInstance();
> System.out.println (c.getDisplayNames(Calendar.MONTH,
> Calendar.SHORT_STANDALONE, Locale.getDefault()));
>
> with `-Djava.
On Wed, 24 Nov 2021 04:08:43 GMT, Ichiroh Takiguchi
wrote:
>> ncoding name COMPAT was defined for operating system encoding by JEP-400.
>> https://openjdk.java.net/jeps/400
>> But java does not accept "-encoding COMPAT".
>
> Ichiroh Takiguchi has updated the pull request incrementally with one
On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote:
> Here are the code changes for the "Deprecate finalizers in the standard Java
> API" portion of JEP 421 ("Deprecate Finalization for Removal") for code
> review.
>
> This change makes the indicated deprecations, and updates the API spec
On Fri, 19 Nov 2021 07:00:44 GMT, Ichiroh Takiguchi
wrote:
> ncoding name COMPAT was defined for operating system encoding by JEP-400.
> https://openjdk.java.net/jeps/400
> But java does not accept "-encoding COMPAT".
src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java
On 16/11/2021 19:02, Pushkar N Kulkarni wrote:
Hi Alan,
Thanks. I appreciate your response.
Yes, I think GB13080 must continue to be GB13080-2000 for now. I was initially hoping to
add a new character set with the name GB13080-2005. But I guess your suggestion of
internally mapping one of the
On 15/11/2021 17:53, Pushkar N Kulkarni wrote:
Hi there,
OpenJDK currently supports version 2000 of the GB18030
(https://en.wikipedia.org/wiki/GB_18030) character set viz. GB18030-2000. The
character mappings corresponding to Unicode codepoints '\u1E3F' and '\uE7C7'
were swapped in a new ver
On Wed, 10 Nov 2021 19:41:29 GMT, Jonathan Gibbons wrote:
> 1. `PrintStream(OutputStream)` and `PrintStream(OutputStream, boolean)`
> should be redefined so that they internally check if the stream arg is a
> PrintStream, in which case they use the encoding from the `PrinStream`
> instead of
On Wed, 10 Nov 2021 19:16:58 GMT, Jonathan Gibbons wrote:
> Generally, the issue is related to the fact that we wrap a PrintStream in a
> PrintWriter ... and, if I understand correctly, the writer ends up with the
> wrong character encoding. Is it possible to change PrintWriter and/or
> PrintS
On Tue, 2 Nov 2021 17:13:47 GMT, Roger Riggs wrote:
> In comments, I think the 'synchronized static 'reads better, the conventional
> order is for the code.
I think Roger is right and maybe the change to the javadoc could be dropped
from this patch.
-
PR: https://git.openjdk.java
On Mon, 25 Oct 2021 10:16:23 GMT, Claes Redestad wrote:
> Enhance ASCII-compatible `DoubleByte` encodings to make use of the
> `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such
> `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte
> encoders - and al
On Wed, 6 Oct 2021 05:04:28 GMT, Ichiroh Takiguchi
wrote:
>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled
>> on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
On Wed, 18 Aug 2021 10:07:35 GMT, Claes Redestad wrote:
> C-style array declarations generate noisy warnings in IDEs, et.c. This patch
> cleans up all java.* packages.
>
> (Copyrights intentionally not updated due the triviality of most changes)
Marked as reviewed by alanb (Reviewer).
---
On Fri, 25 Jun 2021 23:40:27 GMT, Weijun Wang wrote:
>> More refactoring to limit the scope of `@SuppressWarnings` annotations.
>>
>> Sometimes I introduce new methods. Please feel free to suggest method names
>> you like to use.
>
> Weijun Wang has updated the pull request incrementally with o
On Tue, 1 Jun 2021 15:21:33 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>> https://github.com/openjdk/jdk/commit/576161d15423f58281e384
On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>> https://github.com/openjdk/jdk/commit/576161d15423f58281e38
On Fri, 21 May 2021 18:00:13 GMT, Phil Race wrote:
> Are you suggesting that the patch doesn't need testing as it is ? It should
> be the same either way.
> It is very straight forward to run the automated tests across all platforms
> these days.
> I get the impression that no one is guaranteei
On Fri, 21 May 2021 14:52:21 GMT, Thiago Henrique Hüpner
wrote:
> IcedTea-Web seems to be using this method reflectively:
> https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/common/src/main/java/net/adoptopenjdk/icedteaweb/jdk89access/JarIndexAccess.java#L80
I assume this doesn't work wit
On Fri, 21 May 2021 13:13:04 GMT, Сергей Цыпанов
wrote:
> Hi guys, any more comments here? Please ping me if I've missed something
I suspect this will require renaming some fields and changing comments, e.g.
requestList is no longer a good name for the field in AbstractPoller, its
comments ne
On Thu, 20 May 2021 04:22:32 GMT, Phil Race wrote:
>> That is unfortunate, but nonetheless I think required to be done.
>> We have acknowledeged this can't reasonably be called an RFE, so the JEP is
>> introducing bugs/technical debt/call it what you will. This should generally
>> be part of a
On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote:
> Please review this implementation of [JEP
> 411](https://openjdk.java.net/jeps/411).
>
> The code change is divided into 3 commits. Please review them one by one.
>
> 1.
> https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28
On Tue, 18 May 2021 12:42:08 GMT, Sean Mullan wrote:
>> src/java.base/share/classes/java/lang/SecurityManager.java line 315:
>>
>>> 313: *
>>> 314: * @since 1.0
>>> 315: * @deprecated The Security Manager is deprecated and subject to
>>> removal in a
>>
>> Javadoc will prefix, in bold, "D
On Tue, 18 May 2021 10:37:21 GMT, Patrick Concannon
wrote:
> Hi,
>
> Could someone please review my code for updating the code in the `java.util`
> package to make use of the `instanceof` pattern variable?
>
> Kind regards,
> Patrick
You may need to coordinate with @DougLea on the changes to
On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote:
> Please review this implementation of [JEP
> 411](https://openjdk.java.net/jeps/411).
>
> The code change is divided into 3 commits. Please review them one by one.
>
> 1.
> https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28
On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang wrote:
> Please review the test changes for [JEP
> 411](https://openjdk.java.net/jeps/411).
>
> With JEP 411 and the default value of `-Djava.security.manager` becoming
> `disallow`, tests calling `System.setSecurityManager()` need
> `-Djava.secu
On Fri, 7 May 2021 22:46:08 GMT, Naoto Sato wrote:
> Please review this small fix to Windows system property init code. This is
> leftover from the support for `Console.charset()` method, where it lacked to
> initialize `sun.stdout/err.encoding` to `UTF-8` for the code page `cp65001`.
> The f
On Wed, 28 Apr 2021 15:41:31 GMT, Chris Hegarty wrote:
>> 8266155: Convert java.base to use Stream.toList()
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 6788:
>
>> 6786: }
>> 6787:
>> 6788: /**
>
> I think the import of Collectors can be dropped in this file
On Thu, 1 Apr 2021 03:24:04 GMT, Naoto Sato wrote:
> Please review the fix to the subject issue. Thanks to the contribution by
> Chris Johnson.
Marked as reviewed by alanb (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/3300
On Sun, 28 Mar 2021 13:56:00 GMT, Alex Blewitt
wrote:
> 8264332: Use the blessed modifier order in jdk.charsets
Marked as reviewed by alanb (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/3236
On Wed, 17 Mar 2021 16:44:19 GMT, Andy Herrick wrote:
> I cannot find any instances where the scope can be narrowed
Are you about AquaInternalFrameUI.mouseRelased, BasicPopupMenuUI. stateChanged,
and other non-trivial methods?
-
PR: https://git.openjdk.java.net/jdk/pull/2920
On Sun, 14 Mar 2021 17:26:07 GMT, Alan Bateman wrote:
>> Looks like it's never specified in JavaDoc which particular implementation
>> of List is used in fields of affected classes, so it's quite odd to me that
>> someone would rely on that when using refl
On Sun, 14 Mar 2021 17:18:11 GMT, Сергей Цыпанов
wrote:
>> If that's the only use case, I recommend changing the return type to a
>> deque, and replace the linked list with an array deque instead (as done
>> elsewhere in this pr)
>
> Looks like it's never specified in JavaDoc which particular
On Sat, 13 Mar 2021 00:43:33 GMT, Alexander Matveev
wrote:
>> implementation of
>> JDK-8256145: JEP 398: Deprecate the Applet API for Removal
>
> Marked as reviewed by almatvee (Committer).
Have you looked at narrowing the use of the SuppressWarnings to local variable
declarations to avoid add
On Fri, 26 Feb 2021 17:50:19 GMT, Christoph Göttschkes wrote:
> Please review this small patch which fixes the coding style of
> CharacterDataPrivateUse.java
Looks fine. This source file was a .template until a few weeks ago, probably
should have fixed the indentation issues when moving it to
On Fri, 12 Feb 2021 04:06:55 GMT, Naoto Sato wrote:
>> Please review this doc fix to j.l.Character, which now includes the table of
>> the history of supported Unicode versions. A corresponding CSR will be filed
>> accordingly.
>
> Naoto Sato has updated the pull request incrementally with one
On Sun, 7 Feb 2021 19:08:18 GMT, Claes Redestad wrote:
> This patch refactor JDK internal charsets to initialize charset mapping data
> lazily when needed via holder classes. This means both a startup improvement
> in some cases, and possible throughput improvements for all DoubleByte-based
>
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 LogInfo, Generating $(@F)
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 cha
On Mon, 11 Jan 2021 09:20:07 GMT, Magnus Ihse Bursie wrote:
>> Marked as reviewed by prr (Reviewer).
>
> 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?
-
PR:
On Tue, 12 Jan 2021 16:26:27 GMT, Evan Whelan wrote:
> Hi,
>
> Please review this small change which enables the GB18030 charset to be built
> into java.base
>
> Thanks
Including GB18030 in java.base rather than jdk.charsets on Windows is fine. It
does increase the size of java.base but tha
On Tue, 15 Dec 2020 22:52:30 GMT, Magnus Ihse Bursie wrote:
>> Reviewed changes to `characterdata`, `charsetmapping`, `cldr`, `currency`,
>> `lsrdata`, `tzdata`, and `unicodedata` with minor comment. Looks good
>> overall.
>
> I think this is almost ready to be pushed, but I'd like to have some
On Tue, 15 Dec 2020 23:14:14 GMT, Brent Christian wrote:
>> This is part of an effort in the JDK to replace archaic/non-inclusive words
>> with more neutral terms (see JDK-8253315 for details).
>>
>> Here are the changes covering core libraries code and tests. Terms were
>> changed as follows
On Tue, 15 Dec 2020 01:46:08 GMT, Brent Christian wrote:
>> This is part of an effort in the JDK to replace archaic/non-inclusive words
>> with more neutral terms (see JDK-8253315 for details).
>>
>> Here are the changes covering core libraries code and tests. Terms were
>> changed as follows
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 `$M
On Tue, 8 Dec 2020 08:32:28 GMT, Magnus Ihse Bursie wrote:
>> @mlchung If you don't have any strong preference, I implore you to accept
>> this change. I **vastly** prefer to move the data out of `make`!
>>
>> This is not just about Skara tooling. When working with make files, autoconf
>> and
On Fri, 4 Dec 2020 11:38:51 GMT, Magnus Ihse Bursie wrote:
> And I can certainly move jdwp.spec to java.base instead.
If jdwp.spec has to move to the src tree then src/java.se is probably the most
suitable home because Java SE specifies JDWP as an optional interface. So
nothing to do with jav
On Fri, 4 Dec 2020 10:29:48 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* used by
>
On Thu, 12 Nov 2020 20:48:13 GMT, Andy Herrick wrote:
>> JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> Andy Herrick 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.
On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote:
> The change is (just) to remove legacy usages of a JDK-private custom tag.
Marked as reviewed by alanb (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/814
On Fri, 18 Sep 2020 23:47:56 GMT, Yumin Qi wrote:
> With more CDS related code added to VM, it is time to move CDS code to a
> separate class. CDS is the new class which is
> specific to CDS.
> Tests: tier1-4
src/java.base/share/classes/jdk/internal/misc/CDS.java line 42:
> 40: public stat
On Thu, 10 Sep 2020 13:53:10 GMT, David Holmes wrote:
>> @dholmes-ora raises a good point. Hopefully there is a balance point between
>> a dozen different bugs / pull requests
>> each targeting one area and one bug / PR targeting a dozen separate areas. I
>> don't have a good general rule to su
On Thu, 10 Sep 2020 08:47:35 GMT, Dmitriy Dumanskiy
wrote:
>> Before this Enhancement can be formally reviewed, you will need a JBS bug
>> ID. If you are already working with a
>> Committer or Reviewer in the `jdk` project who has agreed to sponsor your
>> change, they can file the Enhancement
On Wed, 9 Sep 2020 09:49:44 GMT, Philippe Marschall
wrote:
>> Hello, newbie here
>>
>> I picked JDK-8138732 to work on because it has a "starter" label and I
>> believe I understand what to do.
>>
>> - I tried to update the copyright year to 2020 in every file.
>> - I decided to change `@sinc
On Mon, 7 Sep 2020 09:44:09 GMT, Philippe Marschall
wrote:
> Hello, newbie here
>
> I picked JDK-8138732 to work on because it has a "starter" label and I
> believe I understand what to do.
>
> - I tried to update the copyright year to 2020 in every file.
> - I decided to change `@since` from
On 06/02/2020 16:50, naoto.s...@oracle.com wrote:
Hello,
Please review this extra small fix for this issue:
https://bugs.openjdk.java.net/browse/JDK-8238605
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8238605/webrev.00/
It is simply updating the version number in
On 14/10/2019 16:53, Ichiroh Takiguchi wrote:
Hello.
Could you review the fix ?
Bug: https://bugs.openjdk.java.net/browse/JDK-8232161
Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.00/
I have a concern about 1-way trip conversion entries (4 entries) on
MS950 charset.
The d
Looks good.
On 11/03/2019 10:06, Rachna Goel wrote:
Hi,
Kindly review fix to JDK-8220414, which updates copyright header.
Bug: https://bugs.openjdk.java.net/browse/JDK-8220414
diff -r 645ba889ee5f
src/java.base/share/classes/sun/text/normalizer/Norm2AllModes.java
---
a/src/java.base/share/c
On 04/01/2019 17:18, Chris Hegarty wrote:
Will compilations with `--release N-1` wind back the set of allowable
identifiers? It possibly should, if so how does one do similar when/if
the set of currency characters is expanded in an update release?
I don't think `javac --release` takes the Unico
This is the font code so I think you'll need to discuss it on 2d-dev at
least.
-Alan
On 09/04/2018 04:57, Toshio 5 Nakamura wrote:
Hello
IBM would like to propose Unicode Variation Selector[1] capability to AWT
and Swing components.
This proposal is changing the following files:
src/java.de
On 21/02/2018 21:13, naoto.s...@oracle.com wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8198385
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8198385/webrev.00/
The property was introduced in JDK7 for the backw
On 09/06/2017 07:59, Nishit Jain wrote:
Hi,
Please review the fix for JDK-8176583
Bug: https://bugs.openjdk.java.net/browse/JDK-8176583
Webrev: http://cr.openjdk.java.net/~nishjain/8176583/webrev.01/
Fix: Relocated currency.data from java.base module
(/java.base/java/util/currency.data) to
On 06/03/2017 03:06, Amy Lu wrote:
java/util/TimeZone/UTCAliasTest.java
This is not a compile-only test, but due to the missed @run tag, test
is not run.
Please review the patch to add @run tag to the test.
Looks okay, alternatively then I assume dropping the @compile tag will
work too.
-
On 06/01/2017 09:13, Yoshito Umaoka wrote:
Yes. See
https://github.com/IBM-Bluemix/gp-java-client#using-resourcebundlecontrolprovider-spi-java-8-or-later
The jar file contains java.util.spi.ResourceBundleControlProvider
[https://github.com/IBM-Bluemix/gp-java-client/blob/master/src/main/res
On 05/01/2017 22:44, Yoshito Umaoka wrote:
Wow.. We utilize ResourceBundleControlProvider SPI and our software
heavily depends on it [https://github.com/IBM-Bluemix/gp-java-client].
This is only the way to inject custom resource loading logic without
affecting existing code.
Does this pr
On 14/11/2016 07:12, Rachna Goel wrote:
Hi,
Kindly review fix for JDK-8168906.
https://bugs.openjdk.java.net/browse/JDK-8168906
Patch :http://cr.openjdk.java.net/~rgoel/JDK-8168906/webrev/
fix: As jdk.localedata module does read any system properties,
tightened permissions for same.
If you
On 22/07/2016 14:13, Peter Levart wrote:
:
The changes are very straightforward. They preserve the general
structure of the logic. I renamed the CacheKey nested class to
LoadSession as it now only functions as a mutable object passed around
the methods while executing the getBundle() process
On 21/07/2016 05:14, Masayoshi Okutsu wrote:
Hi,
Please review the fix for JDK-8161203. The fix is to lazily load
ResourceBundleProviders. It's not necessary to load providers before
cache look-up.
Issue:
https://bugs.openjdk.java.net/browse/JDK-8161203
Webrev:
http://cr.openjdk.java.net/~
On 21/06/2016 07:34, Masayoshi Okutsu wrote:
Hi,
Please review the fix for JDK-8159766. The logging code has been
removed after all. No additional regression test. The message should
no longer be logged to the .jtr file with
java/util/ResourceBundle/UTF8Properties/CodePointTest.java.
Issue
On 13/06/2016 16:02, Mandy Chung wrote:
I see. I’m fine with what you have. We should enhance the jlink testlibrary
to run java from a run-time image created for a test to run.
I'm okay with it too.
-Alan
On 10/06/2016 08:08, Masayoshi Okutsu wrote:
(re-sending to include jigsaw-dev)
Hi,
Please review fixes for 8158272 and 8158468. The test had several
problems.
- A child process doesn't inherit IO. Any outputs from the child
process are not logged.
- The exit code of a child process is ig
On 03/06/2016 05:09, Mandy Chung wrote:
Masayoshi,
test/java/util/ResourceBundle/modules/appbasic is not run because appbasic.sh
was missed. I notice it while looking at the existing tests. I took the
opportunity to improve the javadoc and update appbasic test to serve as a
simple example
On 26/05/2016 11:12, Masayoshi Okutsu wrote:
On 5/26/2016 7:07 PM, Alan Bateman wrote:
On 26/05/2016 10:41, Masayoshi Okutsu wrote:
Naoto pointed out that test/java/text/Format/common/*Format.props
should have the copyright header. Unfortunately,
test/java/text/Format/common/PParser.java
On 26/05/2016 10:41, Masayoshi Okutsu wrote:
Naoto pointed out that test/java/text/Format/common/*Format.props
should have the copyright header. Unfortunately,
test/java/text/Format/common/PParser.java, which parses the .props
files, doesn't support any comment lines. So, PParser has been chang
On 23/05/2016 10:12, Masayoshi Okutsu wrote:
On 5/23/2016 5:10 PM, Alan Bateman wrote:
Is there anything that we can do with the binary files? In the case
of the .ser file then could it be a byte[] in the test with an
execution mode that re-generates it? There is also at least one .data
On 23/05/2016 07:11, Masayoshi Okutsu wrote:
Hi,
Please review changes for JDK-8031145 that is to open closed i18n
tests. There are many old tests which should be cleaned up. I did
some, but there are still many.
Issue:
https://bugs.openjdk.java.net/browse/JDK-8031145
Webrev:
http://cr.open
This looks okay to me.
On 11/04/2016 08:36, Masayoshi Okutsu wrote:
Hi all,
Please review the fix for JDK-8153836.
Issue:
https://bugs.openjdk.java.net/browse/JDK-8153836
Webrev:
http://cr.openjdk.java.net/~okutsu/9/8153836/webrev.00/
Thanks,
Masayoshi
On 31/03/2016 10:29, Masayoshi Okutsu wrote:
Webrev has been updated. I realized that some code which was for
loading resource bundles in both java.base and jdk.localedata
remained. The providers are no longer used for loading resource
bundles in java.base. The code was removed.
http://cr.o
On 30/03/2016 16:48, Mandy Chung wrote:
On Mar 30, 2016, at 8:40 AM, Masayoshi Okutsu
wrote:
Hello,
Please review the fix for JDK-8152817. The fix is to load locale data from its
own module without calling ResourceBundleProviderSupport.loadResourceBundle.
I changed the synopsis of the JBS i
On 19/02/2016 05:34, Masayoshi Okutsu wrote:
This one is much easier to take a look than the previous webrevs. This
time I've looked at all diffs while I did a sampling for our internal
review.
Looks OK to me. I still prefer the per-language (not
per-language.country) grouping, though.
Ma
Naoto - I don't know if this is hg version or webrev related but the
moves aren't showing up correctly in the webrev so it's hard to see the
actual changes. Can you try a new recent webrev to see if that fixes it?
-Alan
On 17/02/2016 21:28, Naoto Sato wrote:
Hello,
Please review the fix t
On 18/05/2015 23:45, Mandy Chung wrote:
This patch removes native2ascii command-line tool from JDK 9 as
proposed in March [1].
Looks good.
-Alan
On 28/04/2015 22:59, Naoto Sato wrote:
Hi,
Please review the changes for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8075545
The fix is to check the RuntimePermission target
"localeServiceProvider" on instance creation. The fix is located at:
http://cr.openjdk.java.net/~naot
On 16/12/2014 17:59, Naoto Sato wrote:
Hi Alan,
Thanks for the review. Modified the fix as you suggested:
http://cr.openjdk.java.net/~naoto/8062588/webrev.01/
This looks okay to me now.
-Alan
On 15/12/2014 22:15, Naoto Sato wrote:
Hello,
Please review the proposed changes for the following issue:
https://bugs.openjdk.java.net/browse/JDK-8062588
The proposed fix is located at:
http://cr.openjdk.java.net/~naoto/8062588/webrev.00/
The change is to load SPI implementations from appli
On 23/10/2014 09:17, Masayoshi Okutsu wrote:
On 10/23/2014 4:58 PM, Alan Bateman wrote:
jdk.localedata.XXX looks right. I wonder if we can find something
better than "jre" for the suffix of the first one. I ask because
linking that into a runtime that isn't the what we know to
On 22/10/2014 20:52, Naoto Sato wrote:
Hi Mandy,
As I wrote in a separate email, my preference is the following module
names:
jdk.localedata.jre
jdk.localedata.cldr
This way, they both come under "localedata" (btw, they don't provide
Locale, but the data for locale sensitive services such a
On 21/10/2014 01:25, Naoto Sato wrote:
I think we can rename the original jdk.localedata to
jdk.localedata.jre solely for the legacy JRE locale data, and create
the new jdk.localedata.cldr. Or re-purpose jdk.localedata to represent
the legacy JRE locale data, and newly create jdk.cldrlocaleda
On 17/10/2014 23:31, Naoto Sato wrote:
Hello,
Please review the proposed changes to the following bug:
https://bugs.openjdk.java.net/browse/JDK-8061382
The webrev is available at:
http://cr.openjdk.java.net/~naoto/8061382/webrev.00/
This is mainly build changes to separate CLDR locale data i
On 09/09/2014 18:14, Naoto Sato wrote:
It's an inherent issue where some init code issues locale sensitive
services, such as in this case, *Formatter. So this could happen not
only in Security class, but could be anywhere. So I think we still
need the change proposed here in order for avoidin
On 09/09/2014 00:04, Naoto Sato wrote:
Hello,
Please review the fix for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8057646
The proposed changes are located at:
http://cr.openjdk.java.net/~naoto/8057646/webrev.0/
It's not clear to me that this is the right place to address th
On 29/08/2014 22:07, Naoto Sato wrote:
I incorporated the suggestions from Mandy and Alan. Also one change
since the last webrev was to revert the hard-coding of the supported
locales list back to the one which dynamically generates the lists at
the build time. I initially thought static listin
1 - 100 of 184 matches
Mail list logo
