On Mon, 21 Mar 2022 16:29:25 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, 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 Wed, 2 Mar 2022 21:53:01 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 Wed, 2 Mar 2022 18:56:40 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
> what m
On Fri, 19 Nov 2021 18:15:46 GMT, Brent Christian wrote:
>> src/java.base/share/classes/java/lang/Object.java line 481:
>>
>>> 479: * system resources or to perform other cleanup.
>>> 480: *
>>> 481: * When running in a Java virtual machine in which finalization
>>> has been
>>
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 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 Wed, 9 Jun 2021 10:25:35 GMT, Patrick Concannon
wrote:
>> Hi,
>>
>> Could someone please review my code for updating the code in the `java.lang`
>> packages to make use of the switch expressions?
>>
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request incrementall
On Thu, 3 Jun 2021 11:01:02 GMT, Patrick Concannon
wrote:
>> Hi,
>>
>> Could someone please review my code for updating the code in the `java.lang`
>> packages to make use of the switch expressions?
>>
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request incrementall
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 Tue, 8 Dec 2020 18:16:15 GMT, Mandy Chung wrote:
>> @wangweij Moving build tools is a related, but separate, question, which is
>> addressed by https://bugs.openjdk.java.net/browse/JDK-8241463.
>>
>> I send out a review earlier this year (see
>> https://m
On Tue, 8 Dec 2020 16:19:05 GMT, Magnus Ihse Bursie wrote:
>> Is there a plan to move make/jdk/src/classes/build/tools/intpoly into
>> java.base as well?
>>
>> Update: I see all subdirs in tools are still there.
>
> @wangweij Moving build tools is a related, but separate, question, which is
>
On Mon, 7 Dec 2020 19:31:59 GMT, Jonathan Gibbons 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
>
> I have reviewed all lines in the patch file with or near
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 mchung (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/814
On Mon, 21 Sep 2020 22:24:15 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
>
> Yumin Qi has updated the pull request incrementally with one additional
> comm
On Mon, 21 Sep 2020 18:17:55 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
>
> Yumin Qi has updated the pull request incrementally with one additional
> comm
+1
Mandy
On 10/12/18 2:38 PM, naoto.s...@oracle.com wrote:
Hi,
Please review this simple doc fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8211961
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8211961/webrev.01/
Although @link is preferred i
On 8/16/18 2:16 AM, Adam Farley8 wrote:
Hi Mandy,
I request that you review this for 8u.
--
@@ -1398,10 +1398,18 @@
bundle = baseBundle;
}
+ keepAlive(loader);
return bundle;
}
/**
+ * Keeps the argument Class
){
//Do nothing.
}
--
Best Regards
Adam Farley
Hans Boehm wrote on 15/08/2018 06:44:08:
From: Hans Boehm
To: Mandy Chung
Cc: adam.far...@uk.ibm.com, core-libs-dev , i18n-dev@openjdk.java.net
Date: 15/08/2018 06:44
Subject: Re: RFR 8209184: JDK8 ResourceBundle
the
condition code. There is no guarantee the reference will still be around
when you expect it.
I haven't come up with a great compiler-independent replacement for
reachabilityFence.
On Tue, Aug 14, 2018 at 8:25 AM mandy chung <mailto:mandy.ch...@oracle.com>> wrote:
Hi Adam,
Have you tried Peter's suggestion if an empty static method taking an
Object parameter? Does it work for you?
Your proposed approach seems fine and I would suggest to put the
check in a static keepAlive method that will make it explicitly.
Mandy
On 8/10/18 8:42 AM, Adam Farley8 wrote
-8202537
Linked mentioned issues with this one.
Thanks,
Rachna
On 6/22/18 9:57 PM, mandy chung wrote:
On 6/22/18 6:54 AM, Rachna Goel wrote:
Hi,
Kindly review fix to update legal files for Unicode, CLDR and ICU.
Issue: https://bugs.openjdk.java.net/browse/JDK-8205158
Patch :http
On 6/22/18 6:54 AM, Rachna Goel wrote:
Hi,
Kindly review fix to update legal files for Unicode, CLDR and ICU.
Issue: https://bugs.openjdk.java.net/browse/JDK-8205158
Patch :http://cr.openjdk.java.net/~rgoel/JDK-8205158/webrev.02/
Looks okay.
What are the issues that upgrades these librar
g transversal is not possible with modules which
should be fixed IMHO.
Just for my knowledge: why adding a flag is not an option?
Le 13 janv. 2018 18:05, "mandy chung" <mailto:mandy.ch...@oracle.com>> a écrit :
team1 has a dependency com.company.resources.spi.Team1Provide
broken if modules use module-info only to define a
SPI for instance.
Le 13 janv. 2018 00:21, "mandy chung" <mailto:mandy.ch...@oracle.com>> a écrit :
Let me try to see if I understand your situation correctly.
On 1/12/18 12:59 PM, Romain Manni-Bucau wr
Let me try to see if I understand your situation correctly.
On 1/12/18 12:59 PM, Romain Manni-Bucau wrote:
All are com.company.*
Assuming service packages use a resource bundle.
team1, team2, team3 all uses a resource bundle. Let's say
com.company.team1.service calls
ResourceBundle.get
On 1/12/18 11:41 AM, Romain Manni-Bucau wrote:
Hello
Comments inline
Le 12 janv. 2018 20:07, "mandy chung" <mailto:mandy.ch...@oracle.com>> a écrit :
Hi Romain,
I expect no impact to the translation process. Can you give an
example of one resource bund
Hi Romain,
I expect no impact to the translation process. Can you give an example
of one resource bundle and its packaged artifact and where the localized
bundles are packaged?
As Naoto suggests, it would be helpful to migrate one resource bundle to
ResourceBundleProvider as an exercise that
http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8193767/
The above includes the webrev, specdiff and javadoc for this update to
ResourceBundle, ResourceBundleProvider, and
AbstractResourceBundleProvider to improve the documentation of
ResourceBundles working with modules.
thanks
Mandy
On 10/24/17 8:00 AM, Naoto Sato wrote:
Hi Mandy,
Sorry, I seem to have generated/uploaded an incorrect webrev for
8189291. Here is the correct one:
http://cr.openjdk.java.net/~naoto/8189291/webrev.02/
+1
Mandy
enclosing class as suggested.
Other than that, the change looks good.
Mandy
Naoto
On 10/20/17 2:45 PM, mandy chung wrote:
On 10/20/17 2:20 PM, Naoto Sato wrote:
Hello,
Please review the changes for the following two issues:
8189272: CLDR and JRE LocaleProviderAdapters silently swallow
On 10/20/17 2:20 PM, Naoto Sato wrote:
Hello,
Please review the changes for the following two issues:
8189272: CLDR and JRE LocaleProviderAdapters silently swallow
exceptions [1]
8189291: Test policy should extend the default system policy [2]
The proposed fixes for the above issues are lo
> On Jul 31, 2017, at 9:20 PM, Naoto Sato wrote:
>
>
>
> On 7/31/17 7:38 PM, Mandy Chung wrote:
>> Can you explain how this fixes it when the default locale is Japanese?
>
> The bundle lookup searches for bundles in the order of en_US -> en -> ja_JP
> -
> On Jul 31, 2017, at 3:51 PM, Naoto Sato wrote:
>
> Hi Mandy,
>
> Would you please review the fix to the following issue?
>
> https://bugs.openjdk.java.net/browse/JDK-8185251
>
> The proposed fix is located at:
>
> http://cr.openjdk.java.net/~naoto/8185251/webrev.00/
>
> The test assumed t
> On May 17, 2017, at 3:06 PM, Naoto Sato wrote:
>
> Revised the fix according to your suggestions:
>
> http://cr.openjdk.java.net/~naoto/8180375/webrev.01/
> http://cr.openjdk.java.net/~naoto/8180375/webrev.01-00/ (change since ver.00)
Looks okay to me.
Thanks
Mandy
Naoto,
The javadoc of getBundle(String, Module) and getBundle(String,Locale,Module)
methods also mention the service type “baseName”Provider that needs update as
well.
Mandy
> On May 16, 2017, at 2:52 PM, Mandy Chung wrote:
>
>
>> On May 16, 2017, at 11:14 AM, Na
> On May 16, 2017, at 11:14 AM, Naoto Sato wrote:
>
> Hello,
>
> Please review the changes to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8180375
>
> The proposed fix is located at:
>
> http://cr.openjdk.java.net/~naoto/8180375/webrev.00/
>
> This is to change the pack
trolProvider} implementations. Refer to the
>> + * description of modifying the
>> default
>> + * behavior.
>> *
>> * @param baseName the base name of the resource bundle,
>> * a fully qualified class name
>>
>&g
> On Jan 23, 2017, at 9:14 AM, Naoto Sato wrote:
>
> http://cr.openjdk.java.net/~naoto/8172365/webrev.05/
>
>>
>> The fix is to reinstate the code that has been removed with 8171189,
>> with modification to load implementations with ServiceLoader.load()
>> method. That way, SPI implementations
Looks fine.
To our knowledge, this ResourceBundleControlProvider SPI is rarely used, if
any. The extension mechanism was removed in jdk-9+41 and there isn’t any issue
filed related to this SPI. I agree to deprecate ResourceBundleControlProvider
for removal.
Mandy
> On Dec 19, 2016, at 9:08 A
Naoto,
Can you review this ResourceBundle caching fix? The caller module
may be different than the specified module to
ResourceBundle.getBundle(String, Module) method and it should also
part of the cache key.
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8170772/webrev.00/
The new test shows
Hi Peter,
Sorry for the delay in reply. Still catching up on mails from vacation.
> On Aug 4, 2016, at 3:26 AM, Peter Levart wrote:
>
>
> On 08/04/2016 11:21 AM, Peter Levart wrote:
>> If the providing module declares the service type, then the consuming module
>> will have an explicit depen
> On Jun 21, 2016, at 9:53 PM, Naoto Sato wrote:
>
> Modified line 243-246 to avoid generating a new List instance with
> Collectors.toList():
>
> http://cr.openjdk.java.net/~naoto/8159781/webrev.03/
+1
Mandy
> On Jun 20, 2016, at 11:34 PM, 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
> I will modify the "regex:" prepending as you suggested.
>>
>> Naoto
>>
>> On 6/17/16 3:50 PM, Mandy Chung wrote:
>>>
>>>> On Jun 17, 2016, at 3:29 PM, Naoto Sato wrote:
>>>>
>>>> Decided to fix thi
> On Jun 17, 2016, at 3:29 PM, Naoto Sato wrote:
>
> Decided to fix this separately from the other include locales issues. Here is
> the bug and the proposed fix:
>
> https://bugs.openjdk.java.net/browse/JDK-8159781
> http://cr.openjdk.java.net/~naoto/8159781/webrev.00/
The change looks okay.
> On Jun 12, 2016, at 11:10 PM, Masayoshi Okutsu
> wrote:
>
> On 6/11/2016 5:53 AM, Mandy Chung wrote:
>>> On Jun 10, 2016, at 12:08 AM, Masayoshi Okutsu
>>> wrote:
>>>
>>> (re-sending to include jigsaw-dev)
>>>
>>> Hi,
> On Jun 10, 2016, at 12:08 AM, Masayoshi Okutsu
> wrote:
>
> (re-sending to include jigsaw-dev)
>
> Hi,
>
> Please review fixes for 8158272 and 8158468. The test had several problems.
>
> :
> Webrev:
> http://cr.openjdk.java.net/~okutsu/9/8158272.8158468/webrev.00
It’s good that you replac
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 of AbstractResourceBundleProvider.
http://
> On Mar 31, 2016, at 2:29 AM, 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
>
> On Mar 30, 2016, at 8:54 AM, Alan Bateman wrote:
>
> 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
> 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 issue because it's a
> On Feb 23, 2016, at 10:20 AM, Naoto Sato wrote:
>
> Hello,
>
> Please review this small fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8150434
>
> The fix is located at:
>
> http://cr.openjdk.java.net/~naoto/8150434/webrev.00/
+1
Dropping the _jdk_localedata suf
This patch removes native2ascii command-line tool from JDK 9 as proposed
in March [1].
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074431/webrev.00/
Jon - A langtools test is updated to use a new Native2Ascii.java helper
class instead.
Existing code that calls sun.tools.nativ
On 4/28/2015 2:59 PM, 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/~nao
There are several existing ways to do native to ascii conversion. For
example, IDEs like NetBeans and IntelliJ support the transparent
native-to-ascii conversion. There is also maven native 2 ascii plugin.
JEP 226 proposes to support UTF Properties file that will address the
original motivati
On 10/20/2014 5:25 PM, Naoto Sato wrote:
My motive for the question is the naming because the changes mean we
have jdk.localedata and jdk.localedata.cldr, an arrangement that
suggests that the CLDR locale data augments the jdk.localedata module.
It may be that we need to choose more suitable
even some portion of CLDR locale data in
java.base would make it not possible for them to jrecreate the image
without CLDR.
Naoto
On 9/16/14, 2:09 PM, Mandy Chung wrote:
On 9/16/14 9:57 AM, Naoto Sato wrote:
Yes, the current plan is to make the CLDR's data the default one, only
when
Mandy
Naoto
On 9/16/14, 9:50 AM, Mandy Chung wrote:
At one point you mention that CLDR will become the default in JDK 9.
Would you need to move them back to java.base when it becomes the
default?
Mandy
On 9/16/14 9:30 AM, Naoto Sato wrote:
CLDR's data is accessible only when cldrdata.jar is
urces. There is no need to put their "en"
resources in java.base.
Naoto
On 9/15/14, 6:11 PM, Mandy Chung wrote:
On 9/15/2014 4:30 PM, Naoto Sato wrote:
Hello,
Please review the fix for the following issue:
https://bugs.openjdk.java.net/browse/JDK-8058509
The we
On 9/15/2014 4:30 PM, Naoto Sato wrote:
Hello,
Please review the fix for the following issue:
https://bugs.openjdk.java.net/browse/JDK-8058509
The webrev is located at:
http://cr.openjdk.java.net/~naoto/8058509/webrev.0/
The fix is intended to move the LocaleDataMetaInfo of CLDR from
java.
On 8/29/14 2:07 PM, 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 listing
Naoto,
This looks better. Thanks for the update.
The getSupportedLocaleString method in both EnLocaleDataMetaInfo and
NonEnLocaleDataMetaInfo has the javadoc that missing the description.
sun.util.locale.provider is a package in java.base and
NonEnLocaleDataMetaInfo has to be in a different
On 8/22/14 3:37 PM, Naoto Sato wrote:
I wonder ifavailableLanguageTags andgetSupportedLocaleString
should return a list or an array of String (see comment below).
There are two provider implementations for
sun.util.locale.provider.LocaleDataMetaInfo and two service config
files as yo
On 8/22/14 11:46 AM, Naoto Sato wrote:
http://cr.openjdk.java.net/~naoto/8038436/webrev.3/
I skimmed on the patch and have a few initial comment/questions.
JREENLocaleDataMetaInfo
JRENonENLocaleDataMetaInfo
- are the lists of locale names generated previously?
The long lines need to be
On 4/30/2013 2:01 PM, Xueming Shen wrote:
http://cr.openjdk.java.net/~sherman/8013254/webrev/
Looks good.
Mandy
-Sherman
On 04/30/2013 10:01 AM, Xueming Shen wrote:
Hi,
It appears we dropped the ball on u+200c and u+200d when we updated
the "simple word boundaries" back to jdk7 [1]. You
Erik,
I approve what you have - please go through and fix the formatting
nits. I inlined my comment below and you can follow up them later if
needed.
On 5/22/2012 12:40 PM, Erik Gahlin wrote:
Thanks for reviewing,
I got a lot of unused import warnings from the IDE when I changed the
Resour
Erik,
I like your idea of trying to define the string constants
for the keys to benefit from the compiler checking and
catch any issue due to typos at compile time. My review
comments below.
Your webrev includes other cleanup. While it's good to
do the simple minor cleanup with this fix, I'd l
Naoto,
Can you review this test fix:
Fixed 6961506: TEST_BUG: ResourceBundle/Bug4168625Test.java and
TestBug4179766.java fails in samevm mode
Webrev at:
http://cr.openjdk.java.net/~mchung/6961506/webrev.00/
This fixes the tests to set the parent class loader of Loader and
SimpleLoader to
70 matches
Mail list logo
