the
votes will be tallied and reported to this list and also to discuss at
openjdk.java.net.
Only Members of the Internationalization/Localization Group are
eligible to vote on this decision. The current Members are:
Michael Fang
Yong Huang
Yuka Kamiya
Steven Loomis
Masayoshi
Hi Martin,
I vaguely remember that we (jsr204) followed the convention of the
Character class to mention Unicode values in the API doc. It's also
convenient to have Unicode values because you don't need to look up the
Unicode standards. I don't see much value to rewrite the existing
On 8/11/2009 6:10 AM, Martin Buchholz wrote:
I should really be doing something else, but
I reworked my surrogate readability patch
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/isSurrogate2/
to take into account Joe's suggestions.
Masayoshi, hope that's OK with you.
The new javadoc makes
Looks good to me, although I prefer the original names :-)
Thanks,
Masayoshi
On 11/27/2009 3:13 AM, Kelly O'Hair wrote:
Please review
http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-6903197/webrev/
This is to make all the java template filenames consistent and
allow for easy filtering of
Thank you for providing the test case. The webrev looks good to me.
Is it ok to push this to OpenJDK6 (swing forest as used for i18n)?
Do you mean OpenJDK7? If so, yes, we use the swing forest for i18n.
Thanks,
Masayoshi
On 1/8/2010 2:13 AM, Andrew John Hughes wrote:
Bug 6584033
Are you talking about unpaired surrogates or something else?
Thanks,
Masayoshi
On 1/24/2011 5:22 AM, Tom Christiansen wrote:
I am somewhat uncertain, but I believe that Java
*almost* meets this requirement.
1.7 Code Points
A fundamental requirement is that Unicode text be
On 5/12/2011 5:07 AM, Omair Majid wrote:
Hi,
Andrew John Hughesgnu_andrew@... writes:
When distros update their timezone data, the data used by OpenJDK also
needs to be updated. At present, this is difficult as OpenJDK uses a
hardcoded path (${java.home}/jre/lib/zi} for timezone data with no
On 5/13/2011 2:17 AM, Omair Majid wrote:
On 05/12/2011 03:39 AM, Masayoshi Okutsu wrote:
On 5/12/2011 5:07 AM, Omair Majid wrote:
Hi,
Andrew John Hughesgnu_andrew@... writes:
When distros update their timezone data, the data used by OpenJDK also
needs to be updated. At present
First of all, is this really a Java SE bug? The usage of
OutputSteamWriter in JavaMail seems to be wrong to me. The writeTo
method in the bug report doesn't seem to be able to deal with any
stateful encodings.
Masayoshi
On 2/9/2012 3:26 PM, Xueming Shen wrote:
Hi
This is a long standing
fd needs to be closed when fstat or malloc failed?
Thanks,
Masayoshi
On 3/13/2012 12:22 AM, Alan Bateman wrote:
On 12/03/2012 15:11, Seán Coffey wrote:
Yes - good catch. I hadn't tested the sym link being a relative path.
We should always open whatever is pointed to from
As I stated before, your proposed fix is good because Windows XP doesn't
use the Dynamic DST data.
Thanks,
Masayoshi
On 5/24/2012 2:53 PM, Deven You wrote:
Hi masayoshi,
Could you review Yoshito and my replies and see if it is good to you?
Thanks a lot!
On 05/17/2012 11:04 AM, Deven You
Hi Deven,
Sorry. I didn't review the test case...
You can use applet to write a manual test. You will find some manual
tests under test/java/awt such as:
test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.{html,java}
Thanks,
Masayoshi
On 5/25/2012 4:41 PM, Deven You wrote:
Hi
On 5/25/2012 6:37 PM, Alan Bateman wrote:
On 25/05/2012 10:32, Masayoshi Okutsu wrote:
Hi Deven,
Sorry. I didn't review the test case...
You can use applet to write a manual test. You will find some manual
tests under test/java/awt such as:
test/java/awt/TextField/ScrollSelectionTest
Hi,
This is a review request for 6380549. This change enables SPI support
for ResourceBundle.Control. API changes were approved by CCC.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6380549
http://cr.openjdk.java.net/~okutsu/6380549/webrev.00/
Thanks,
Masayoshi
Hi Steven,
Thanks for your comments. Finally we are getting comments on the i18n
part. :-)
On 8/14/2012 1:58 PM, Steven R. Loomis wrote:
Hello,
Some questions,
- Is there a reason that a new parser was written, rather than leverage
the existing CLDR tools (which are themselves written
On 8/14/2012 2:25 PM, Steven R. Loomis wrote:
Naoto,
okay, thought I was done for the night, but just two more things..
- again on the talk to us category.. Sun already wrote one LDML
converter, and contributed to another. They're part of the CLDR toolset and
work with OOo and Solaris data.
Looks good to me.
Masayoshi
On 9/28/2012 12:14 PM, Yuka Kamiya wrote:
Updated based on internal comments.
http://cr.openjdk.java.net/~peytoia/7069824/webrev.01/
Thanks,
--
Yuka
(12/09/28 7:19), Yuka Kamiya wrote:
Hi,
Please review the change for BCP 47 locale matching.
and
CalendarDataProviderImpl.java (this is irrelevant to the bug, but
fixed it anyway for precaution).
http://cr.openjdk.java.net/~naoto/7196799/webrev.03/
Naoto
On 10/2/12 10:02 PM, Masayoshi Okutsu wrote:
Hi Naoto,
Here are my comments.
LocaleProviderAdapter.java:
- After parsing the java.locale.providers
Looks good.
Masayoshi
On 10/5/2012 6:40 AM, Naoto Sato wrote:
Hello,
Please review the fix for the following bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7200119
Proposed changes are located at:
http://cr.openjdk.java.net/~naoto/7200119/webrev.00/
This is just to add en-US to
The fix will have a problem when called by multiple threads. Strictly
speaking, DateFormatSymbols isn't thread-safe, but the usage of
cachedHashCode will have a problem even with no set* calls.
I'd suggest the following.
int hashCode =cachedHashCode;
if (hashCode == 0) {
...
Looks good.
Masayoshi
On 10/6/2012 3:13 AM, Naoto Sato wrote:
Thanks. I modified the fix according to your comments. The new webrev
is located at:
http://cr.openjdk.java.net/~naoto/7200341/webrev.01/
Please review.
Naoto
On 10/4/12 10:36 PM, Masayoshi Okutsu wrote:
The fix will have
/~naoto/8000245.8000273.8000615/webrev.01/
Naoto
On 10/14/12 12:14 PM, Masayoshi Okutsu wrote:
Here are my comments.
LocaleNameProvider/CurrencyNameProvider/TimeZoneNameProvider:
- pool is no longer used and should be removed.
- Should contains(key) be retained? It should be faster than try-catch
Here are my comments.
SPILocaleProviderAdapter.java:
- Should . be used for composing a class name of a Delegate instead of
$?
- Is it necessary to iterate locale candidate in getImpl? (Iteration is
performed outside of adapters when getting an adapter or a provider of
pools.)
-
Looks good.
Masayoshi
On 10/24/2012 9:20 AM, Naoto Sato wrote:
Thank you for your review. My comments are embedded below:
On 10/23/12 2:53 PM, Masayoshi Okutsu wrote:
Here are my comments.
SPILocaleProviderAdapter.java:
- Should . be used for composing a class name of a Delegate instead
wrote:
Will fix 8001562 too, with a separate changeset.
Naoto
On 11/2/12 1:08 AM, Masayoshi Okutsu wrote:
Do you plan to fix this one with 8001562? (If you fix only this one, it
may be seen as a regression.)
Masayoshi
On 10/31/2012 11:55 AM, Naoto Sato wrote:
With this fix, no. But another bug
Looks good to me.
Masayoshi
On 11/16/2012 4:49 AM, Naoto Sato wrote:
Hello,
Please review this simple fix for the subject issue.
http://cr.openjdk.java.net/~naoto/7199750/webrev.00/
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7199750
Before the fix, if there are two SPI
. No other changes.
Updated webrev:
http://cr.openjdk.java.net/~okutsu/8/8000983.8003267/webrev.01/
Thanks,
Masayoshi
Naoto
On 12/5/12 9:06 PM, Masayoshi Okutsu wrote:
Resending in order to include build-...@openjdk.java.net and
build-in...@openjdk.dev.java.net.
Hi,
This is a review
Hi,
This is a code review request for:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005471
Webrev:
http://cr.openjdk.java.net/~okutsu/8/8005471/webrev.00/
Thanks,
Masayoshi
Hi,
This is a code review request for:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005561
(This CR isn't viewable on bugs.sun.com yet.)
Webrev:
http://cr.openjdk.java.net/~okutsu/8/8005561/webrev.00/
Thanks,
Masayoshi
Hello.
This is a review request for
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4745761
Webrev:
http://cr.openjdk.java.net/~okutsu/8/4745761/webrev.00/
Thanks,
Masayoshi
Hi,
This is a code review request for two RFEs.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004489
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006509
Webrev:
http://cr.openjdk.java.net/~okutsu/8/8004489.8006509/webrev.00/
I didn't add the resources starting with cldr. to
Here are my review comments.
- The Calendar.createCalendar comment says, but it's not possible since
JapaneseImperialCalendar is package private. If Calendar.Builder
doesn't work, should the reason be different? Otherwise, the host locale
adapters won't be able to create a
Looks good to me.
Thanks,
Masayoshi
On 3/13/2013 7:26 AM, Naoto Sato wrote:
Webrev is updated according to your suggestions:
http://cr.openjdk.java.net/~naoto/8008576/webrev.02/
Please see each comment embedded below:
On 3/12/13 1:44 AM, Masayoshi Okutsu wrote:
Here are my comments
Additional comments (to the CFStringRef to jchar[] conversion).
- There might be exceptional cases on zero digit handling in CLDR. One
is that digits aren't sequential in hanidec which can't be supported
with the current java.text classes. Another one is that digits are in a
reversed order in
Looks good to me.
Masayoshi
On 3/30/2013 6:44 AM, Naoto Sato wrote:
Revised the macosx portion of the changeset again. Reverted the code
that obtains CFLocaleRef back to using CFLocaleCopyCurrent(),
otherwise the user's cusomization would not be reflected. Here is the
revised webrev:
Hi,
I've made changes for splitting locale resources into FormatData
required by the legacy i18n classes and JavaTimeSupplementary required
by the java.time classes. The reason of this split is to make locale
resources maintenance easier. Changes are mostly in the locale data
adapter side.
9:09 AM, Masayoshi Okutsu wrote:
Hi,
I've made changes for splitting locale resources into FormatData
required by the legacy i18n classes and JavaTimeSupplementary required
by the java.time classes. The reason of this split is to make locale
resources maintenance easier. Changes are mostly
Looks good to me.
Masayoshi
On 4/19/2013 5:36 AM, Naoto Sato wrote:
Hello,
Please review the changes for the following CR:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010666
Here is the webrev for the changes:
http://cr.openjdk.java.net/~naoto/8010666/webrev.00/
Windows APIs for
/webrev.01/
Naoto
On 4/26/13 1:46 AM, Masayoshi Okutsu wrote:
I'd suggest that the for loop and the following if-statement be combined
and optimized.
Masayoshi
On 4/26/2013 6:21 AM, Naoto Sato wrote:
Hello,
Please review the fix for the following bug:
http://bugs.sun.com/bugdatabase/view_bug.do
Looks OK. There's still some room for optimization, though.
Masayoshi
On 5/2/2013 11:46 AM, Naoto Sato wrote:
Webrev has been updated with your suggestion:
http://cr.openjdk.java.net/~naoto/8013086/webrev.02/
Naoto
On 5/1/13 1:19 AM, Masayoshi Okutsu wrote:
What I meant is something like
Not sure how the test can detect bugs in the provider of the host
adapter. BTW, some lines are very long requiring a wide screen monitor.
Masayoshi
On 5/7/2013 3:50 AM, Naoto Sato wrote:
Hello,
Please review the following changeset:
http://cr.openjdk.java.net/~naoto/8013233/webrev.00/
for
Do we still need to keep the old javazic code in JDK8? It's a
maintenance burden to maintain both, isn't it?
I'm concerned about the 24:00 fix. Is there any way to produce the
correct rules without hard coding time zone IDs?
Masayoshi
On 5/10/2013 8:24 AM, Xueming Shen wrote:
Hi Sean,
On 5/10/2013 3:30 PM, Xueming Shen wrote:
On 5/9/13 9:57 PM, Masayoshi Okutsu wrote:
Do we still need to keep the old javazic code in JDK8? It's a
maintenance burden to maintain both, isn't it?
While it's a burden, but somehow it serves as a test case pretty well.
The transitions are
being
I think Objects.equals(Object, Object) should be used when comparing
result and expected. Otherwise, the fix looks OK to me.
Masayoshi
On 5/8/2013 7:10 AM, Naoto Sato wrote:
On 5/6/13 9:30 PM, Masayoshi Okutsu wrote:
Not sure how the test can detect bugs in the provider of the host
adapter
on that machine, result=mk and
expected=(null) where fallback kicks in. Maybe the variable name
expected be replaced with something like resultFromHOST, but the
test itself cannot just use Objects.equals().
Naoto
On 5/12/13 10:21 PM, Masayoshi Okutsu wrote:
I think Objects.equals(Object, Object) should
, the
result value still is non null, which assures that FALLBACK provider
has kicked in. So I think checking result != null is still needed.
Naoto
On 5/13/13 5:15 PM, Masayoshi Okutsu wrote:
I see. The test case should get the expected value first, then. If
expected == null, skip the test case
://cr.openjdk.java.net/~naoto/8013233/webrev.02/
Naoto
On 5/14/13 9:22 PM, Masayoshi Okutsu wrote:
Do you mean this?
if (result == null ||
expected != null
!result.equals(expected)) {
throw new RuntimeException(...);
}
Masayoshi
On 5/15/2013 1:06 AM
Looks good to me.
Masayoshi
On 5/23/2013 3:45 AM, Naoto Sato wrote:
Hello,
Please review the changes for the following two simple document fixes:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7056126
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7083668
The proposed webrev is
Looks good to me.
Masayoshi
On 5/29/2013 5:50 PM, Yuka Kamiya wrote:
Masayoshi,
Could you please review my fix for the following bugs?
http://bugs.sun.com/view_bug.do?bug_id=8014469
8014469 : (tz) Support tzdata2013c
http://bugs.sun.com/view_bug.do?bug_id=8015570 (may not be browseable
I'd suggest use of Collections.singleton(T o) for
FallbackLocaleProviderAdapter.rootTagSet. Otherwise, the changes look
good to me.
Thanks,
Masayoshi
On 6/1/2013 8:58 AM, Naoto Sato wrote:
Hello,
I updated the fix according to an internal comment, which added a
paragraph in
Looks good to me.
Masayoshi
On 6/4/2013 6:28 AM, Naoto Sato wrote:
Thanks. I should have known. Here is the revised webrev:
http://cr.openjdk.java.net/~naoto/8013903/webrev.02/
Naoto
On 6/3/13 1:56 AM, Masayoshi Okutsu wrote:
I'd suggest use of Collections.singleton(T o
Looks good to me.
Masayoshi
On 6/4/2013 3:06 PM, Yong Huang wrote:
Hello,
This is the review request for
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7040556
Webrev: http://cr.openjdk.java.net/~yhuang/7040556/webrev.00/
thanks,
Yong
When I noticed the warning, actually I tried the exactly same fix (both
equals and hashCode). It was supposed to generate the same data after
the fix, but the fixed one didn't generate identical data. I haven't had
time to look into it further.
Yesterday Yuka looked into the fixed tool and
Hello,
This is a review request for the fix of 7177315: SimpleDateFormat parses
wrong 2-digit year if input contains spaces
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177315
Webrev:
http://cr.openjdk.java.net/~okutsu/8/7177315/webrev.00/
Thanks,
Masayoshi
Hello,
This is a review request for the fix of:
7064270: java/text/Format/DateFormat/WeekDateTest.java fails on OEL5.6
hi_IN.UTF-8
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064270
Webrev:
http://cr.openjdk.java.net/~okutsu/8/7064270/webrev.00/
Thanks,
Masayoshi
I prefer to avoid use of deprecated 3-letter IDs of JDK 1.1. PST
should be America/Los_Angeles.
Masayoshi
On 6/12/2013 2:55 AM, Naoto Sato wrote:
Hello,
Please review an one-liner fix for the following bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015960
The fix is simply to set
This appears to be a leftover of the cache cleanup activity. The fix
looks good to me.
Masayoshi
On 6/23/2013 12:34 AM, Alan Bateman wrote:
While snooping around in java.util.TimeZone I came across DisplayNames
which doesn't appear to be be used anymore as the display cache is
moved to
Looks good.
Masayoshi
On 6/25/2013 7:18 AM, Naoto Sato wrote:
Another very simple review request:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017468
http://cr.openjdk.java.net/~naoto/8017468/webrev.00/
It's just fixing a typo in the ResourceBundle's class documentation.
Naoto
Looks good to me. But I'd like Sherman to take a look at the fix.
Masayoshi
On 6/27/2013 8:58 AM, Naoto Sato wrote:
Hello,
Please review the following fix:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6609431
http://cr.openjdk.java.net/~naoto/6609431/webrev.00/
The failure was caused
java/text/DateFormat.java:
/**
* Get a default date/time formatter that uses the SHORT style for both the
* date and the time.
+ *
+ * @return a date formatter
*/
public final static DateFormat getInstance() {
This method returns a DateFormat for both date and
Hi,
Please review the following fix:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015986
This fix is a workaround until JDK incorporates the chronology name and
its translations from CLDR. The English and Arabic names for the JRE
resources are preferred names given by Oracle
Hi Yong,
I think it's OK to use EUR without specifying the transition date-time
for JDK 8.
Thanks,
Masayoshi
On 8/6/2013 11:44 AM, Yong Huang wrote:
Hi Naoto,
To place the transition logic, do you mean I need to add comments in
source file or do I just need to explain it in this email
(adding core-libs-dev)
Hi Christian,
RFC 4647 defines The Language Priority List [1]. The use of
java.util.List would be a natural fit, which is the reason why List is
used. But use of Iterable does work (as API design). The parameter name
`priorityIterable' sounds a bit odd, though.
Does
give more flexibility, but I'm not sure how much it
would add value to the API use. You can implement your own Iterable, but
would many developers implement an Iterable to give a language priority
list?
Masayoshi
On 2013/08/29 5:42, Alan Bateman wrote:
On 28/08/2013 14:25, Masayoshi Okutsu
Looks good to me.
Masayoshi
On 9/5/2013 1:26 AM, Naoto Sato wrote:
Hello,
Please review this very simple doc fix:
http://cr.openjdk.java.net/~naoto/8023943/webrev.00/
for the following bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8023943
This is just a document correctness fix
Hi,
Please review the following fix:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024141
The fix is to cache time zone name arrays in different sizes separately.
The cache support and/or time zone name resources structure may need to
be revisited for more efficient management. Maybe
Hi,
Please review the doc fix for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8022666
Webev:
http://cr.openjdk.java.net/~okutsu/8/8022666/webrev.00/
Thanks,
Masayoshi
Hi amarshi,
The current tzdata version of openjdk-7 seems to be 2013d which should
be the latest for Israel. What version of openjdk-7 are you using?
Thanks,
Masayoshi
On 10/8/2013 6:07 PM, amarshi wrote:
Hi,
I am currently using openJDK-7 , but there is a problem with the Daylight
Savings
Hi Aleksej,
Here are my review comments.
- The copyright header of the data files shouldn't be removed.
- TimeZoneNames.java:
- Middle Europe Time, MET}},
+ MET, MET}},
I don't think the long name should be changed.
I didn't
On 13年10月10日 09:54 下午, Masayoshi Okutsu wrote:
Hi Aleksej,
Here are my review comments.
- The copyright header of the data files shouldn't be removed.
- TimeZoneNames.java:
- Middle Europe Time, MET}},
+ MET, MET}},
I don't think the long name should be changed.
I didn't review the localized
Looks good to me.
Masayoshi
On 10/17/2013 10:39 AM, Yuka Kamiya wrote:
Hi,
Please review this fix for JDK 8. This is to update data for locale matching.
http://bugs.sun.com/view_bug.do?bug_id=8025703
http://cr.openjdk.java.net/~peytoia/8025703/webrev.00/
Thanks,
--
Yuka
://bugs.openjdk.java.net/browse/JDK-8025051).
For now, webrev [2] looks fine to take care of the short term
regression failure.
thanks,
-michael
On 13?10?22? 09:29 ??, Masayoshi Okutsu wrote:
Hi Michael,
27 *@summary Test case for tzdata2005m support for 9 locales
What's the purpose of this test
Looks good to me.
Masayoshi
On 10/29/2013 2:05 PM, Michael Fang wrote:
Hello,
Please help to review the changes (3 line fix) for the following CR:
https://bugs.openjdk.java.net/browse/JDK-8026108
The webrev is available here:
http://cr.openjdk.java.net/~mfang/8026108/
Looks good to me.
Masayoshi
On 10/29/2013 2:02 PM, Michael Fang wrote:
Hello,
Please help to review the changes (1 line fix) for the following CR:
https://bugs.openjdk.java.net/browse/JDK-8008437
https://bugs.openjdk.java.net/browse/JDK-8008437
The webrev is available here:
On 11/21/2013 2:08 AM, Alan Bateman wrote:
We have a number of test failures in agentvm mode that appear to be
caused by tests changing the default TimeZone and not restoring it.
These failures become very intermittently when running with
concurrency as it is unpredictable as to the sequence
://cr.openjdk.java.net/~mfang/7090826/webrev.01/
JPRT build also completed successfully and passed the core testset.
thanks,
-michael
On 13年12月11日 08:14 下午, Masayoshi Okutsu wrote:
src/share/classes/sun/util/resources/pt/LocaleNames_pt.properties:
Looks like CS (transitionally reserved) has been removed
On 12/18/2013 6:43 PM, Aleksej Efimov wrote:
Hi,
Please help to review a fix [1] for 8025051 bug [2]. The following fix
includes:
Common to all modified files:
- All year ranges in the copyright header should be modified accordingly.
- The translation of time zone generic names were added
translations
in translation files. I suggest two approaches to resolve it: 1. Log
different bug with all problems in translation files. 2. Wait for the
next resource file translation update to address these problems.
-Aleksej
On 12/19/2013 12:04 PM, Masayoshi Okutsu wrote:
On 12/18/2013 6:43
Looks like all spaces between English words and Japanese characters have
been removed. Why is that?
I checked (OS native) man pages in Japanese on Solaris and Linux. They
have spaces. I do prefer to have spaces.
Thanks,
Masayoshi
On 12/23/2013 5:54 PM, Michael Fang wrote:
Hi,
Please help
Hi Aleksej,
I think this one is the first tzdata change for JDK9. So I'd suggest
that all the TimeZoneNames*.properties files, which were temporarily
created for the translation work, be removed.
Thanks,
Masayoshi
On 1/21/2014 10:17 PM, Aleksej Efimov wrote:
Hi,
Can I have a review for
Looks good to me.
Masayoshi
On 1/31/2014 9:28 AM, Naoto Sato wrote:
Hello,
Please review the following fix:
https://bugs.openjdk.java.net/browse/JDK-8030696
http://cr.openjdk.java.net/~naoto/8030696/webrev.00/
It basically adds nb_NO and nn_NO in the returned array from
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.
Masayoshi
On 2/5/2014 11:54 AM, Naoto Sato wrote:
Hello,
Please review this fix:
preferred adapter. However, on the JRE's adapter side, it still needs
to declare that Hans/Hant locales in the supported locales list. This
fix is to address this latter part.
Naoto
On 2/10/14, 12:23 AM, Masayoshi Okutsu wrote:
I wonder if we can utilize the locale matching mechanism rather than
not used anywhere.
Thanks,
Aleksej
On 04/03/2014 06:21 PM, Masayoshi Okutsu wrote:
Hi Aleksej,
Sorry, but I forgot about the generic names. Coordinated Universal
Time and UTCshouldn't be the generic names. You will need to
invent the names, something like Troll Time.
Thanks,
Masayoshi
On 4/2
Looks good.
Masayoshi
On 4/17/2014 12:44 PM, Yuka Kamiya wrote:
Hello,
Please review a simple doc fix to add a missing line.
http://cr.openjdk.java.net/~peytoia/8035726/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8035726
Thanks,
--
Yuka
Looks good.
Masayoshi
On 5/7/2014 5:09 PM, Yuka Kamiya wrote:
Hello,
Please review a simple fix for JDK 9:
Bug description: https://bugs.openjdk.java.net/browse/JDK-8042360
Webrev: http://cr.openjdk.java.net/~peytoia/8042360/webrev.00/
Thanks,
--
Yuka
Looks good to me.
Masayoshi
On 5/15/2014 7:59 AM, Aleksej Efimov wrote:
Hello,
Can I have a review for the tzdata2014c integration to JDK9. This is a
standard release of tzdata (except the hurry with Egypt rules - the
main part in this release).
The following set of tests was executed with
Looks good to me.
Thanks,
Masayoshi
On 5/15/2014 4:37 PM, Alan Bateman wrote:
Forwarding to i18n-dev as that it usually the list where changes to
the locale and resources are maintained.
-Alan
On 15/05/2014 04:45, Sandipan Razzaque wrote:
Hi all,
Please find below the webrev for bug
Hello,
Could you please review the fix for 8032650? The bug report isn't
visible outside Oracle. The problem is that the second call to
JNU_GetStringPlatformChars() in
Java_java_util_TimeZone_getSystemTimeZoneID() in
src/share/native/java/util/TimeZone.c ignores possible exceptions. I
we remove those dead code?
Naoto
On 5/19/26 H, 1:10 AM, Masayoshi Okutsu wrote:
Hello,
Could you please review the fix for 8032650? The bug report isn't
visible outside Oracle. The problem is that the second call to
JNU_GetStringPlatformChars() in
Java_java_util_TimeZone_getSystemTimeZoneID
Sorry, I forgot about LocaleDataTest. The fix looks good to me.
Masayoshi
On 5/22/2014 9:13 AM, Michael Fang wrote:
Hi all,
I created a test build and ran regression tests. LocaleDataTest
failed. I have updated the test data related to this bug fix. Please
review the changes related to
Hello,
Could you please review the fix for JDK-8033627? This is lib/tzmappings
update due to the Windows KB2794119 update.
JBS:
https://bugs.openjdk.java.net/browse/JDK-8033627
Webrev:
http://cr.openjdk.java.net/~okutsu/9/8033627/webrev.00/
Thanks,
Masayoshi
Does JavaAWTFontAccessImpl need to use reflection for the TextAttribute
constants?
Masayoshi
On 7/2/2014 9:42 AM, Naoto Sato wrote:
I further modified the fix:
- Made sure the SharedSecret is lazily evaluated.
- Added the missing JavaAWTFontAccessImpl file
- Added a test case
are based on human lifetimes, that seems an
invalid assumption.
Stephen
On 22 July 2014 08:06, Masayoshi Okutsu masayoshi.oku...@oracle.com wrote:
Hello,
Please review the change for JDK-8048123. This change removes all the era
definitions in ${java.home}/lib/calendars.properties. (The property file
On 7/22/2014 9:49 PM, Alan Bateman wrote:
There are a couple of @SuppressWarnings values that I don't recognize,
are these warnings that javac emits?
These are what netbeans complained and suggested. So I assume that these
warnings are all from javac.
Other minor comments in passing. The
update. It seems to me that one additional
era is quite a risk to be baking into the JDK.
Stephen
On 22 July 2014 09:05, Masayoshi Okutsu masayoshi.oku...@oracle.com wrote:
The assumption here is that it's enough to support one additional era until
the era is added to the built-in eras in update
, as the spec reads If the given era is
invalid, such as the since value before the beginning of the last
predefined era, the given era will be ignored?
Naoto
On 7/22/14, 12:06 AM, Masayoshi Okutsu wrote:
Hello,
Please review the change for JDK-8048123. This change removes all the
era
.
http://cr.openjdk.java.net/~okutsu/9/8048123/webrev.02/
Thanks,
Masayoshi
On 7/31/2014 11:16 PM, Masayoshi Okutsu wrote:
I've decided to follow the current spec -- ignoring any invalid
property values. This way applications can still run without removing
the property even after installing a fixed
Hello,
Please review the fix for the broken optimization code for resource
bundle loading.
bug:
https://bugs.openjdk.java.net/browse/JDK-8055088
wevrev:
http://cr.openjdk.java.net/~okutsu/9/8055088/webrev.00/
Note that BreakIteratorInfo and BreakIteratorRules, which are not used
for any
Here are my comments.
- Looks like this change removed the 8055088 fix for BreakIteratorInfo
optimization.
- The langtags field in each *Impl class should be volatile.
- DateFormatProviderImpl has static langtags to be shared by some other
*Impl. But JRE and CLDR have different sets of
1 - 100 of 212 matches
Mail list logo
