Hi,
Please review the changes for JDK-8165804 which is a follow-up of
JDK-8076757. Some notes on the changes.
- Removed INCLUDES := $(TEXT_PKG_LD) from
make/gendata/GendataBreakIterator.gmk in order to avoid compiling
non-BreakIterator*.java for the build tool with boot JDK.
- Added sun.ut
undleName(),
! bundle.getLocale(),
! bundle.format,
loadSession.getLoader(),
bundle,
bundle.loadTime);
In my opinion, the change of the semantics of
ResourceBundle.clearCache(ClassLoader) could be tolerated if the
invocation of that method was not a requirement for application
cont
eing GCed immediately.
I can prototype such caching if you like.
Regards, Peter
On 07/22/2016 06:07 AM, Masayoshi Okutsu wrote:
Hi Peter,
Thank you for your suggestion. Actually CacheKey is used for storing
information required to load resource bundles during a
ResourceBundle.getBundle call.
t
future modification of code could unintentionally produce a class
loader leak. To prevent that, I would somehow mark the clone so that
any attempt to invoke getProviders() on the clone would throw
IllegalStateException.
Regards, Peter
On 07/21/2016 06:14 AM, Masayoshi Okutsu wrote:
Hi,
Plea
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/~okutsu/9/8161203/webrev.01
Thanks,
Masayoshi
6/20/16 7:53 PM, Masayoshi Okutsu wrote:
If the long pattern string is avoided, it'll be unnecessary to use "%%"
and replaceAll? I'm also concerned to keep concatenating strings to
produce a long string (rather than using a StringBuilder). Would
that be
the reason to put -verbose:
If the long pattern string is avoided, it'll be unnecessary to use "%%"
and replaceAll? I'm also concerned to keep concatenating strings to
produce a long string (rather than using a StringBuilder). Would that be
the reason to put -verbose:gc in the test program? Use of List
will simplify the p
I've been waiting for JDK-8159206 to be fixed. But this test still fails
after the JDK-8159206 fix. I've filed JDK-8159781 for the failure and
pushed this test fix with the following ProblemList.txt change:
diff --git a/test/ProblemList.txt b/test/ProblemList.txt
--- a/test/ProblemList.txt
+++
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,
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
(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 ignored. The exit code needs to be
checked by the t
+1
Masayoshi
On 4/2/2016 8:40 AM, Mandy Chung wrote:
On Apr 1, 2016, at 2:20 PM, Naoto Sato wrote:
Hello,
Please review the fix for the following issue:
https://bugs.openjdk.java.net/browse/JDK-8152742
The fix is located at:
http://cr.openjdk.java.net/~naoto/8152742/webrev.00/
Looks okay
On 1/6/2016 6:48 PM, Alan Bateman wrote:
On 06/01/2016 06:40, Masayoshi Okutsu wrote:
On 1/5/2016 10:38 PM, Alan Bateman wrote:
One other question on this is whether there are concurrency issues
with the candidate list? I ask because candidateMap is a CHM but the
map value (the candidate
On 1/5/2016 10:38 PM, Alan Bateman wrote:
One other question on this is whether there are concurrency issues
with the candidate list? I ask because candidateMap is a CHM but the
map value (the candidate list) seems to be queried (via the size
method) and updated in getCandidateLocale without
Hi,
Please review the fix for JDK-8145351. This issue is specific to Jake
and the fix is to restore the irregular resource bundle look-up path for
TimeZoneNames derived from CLDR.
Issue: https://bugs.openjdk.java.net/browse/JDK-8145351
Webrev: http://cr.openjdk.java.net/~okutsu/9/8145351/webr
Hello,
Please review the change for JDK-8139067. A consumer module
(ResourceBundle.getBundle caller) will no longer load resource bundles
from the class-path if the consumer module is a named module. Test
programs, basic and modlocal, have been changed to confirm .properties
bundles are not l
+1
On 10/23/2014 4:52 AM, 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
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 today as the
JRE might be confusing.
Actually Naoto and I discu
17 matches
Mail list logo
