if the current implementation is robust enough to be
able to reject all broken data files. It does check magic numbers,
though. You may need extra tests with random directory paths. Or
you could add more checking to see if the directory is right, such
as existence of the ZoneInfoMapp
updated the RFE. I'm going to await further feedback.]
Keith Seitz wrote:
Masayoshi Okutsu wrote:
Sorry for taking time to respond.
Likewise!
I've filed an RFE for this request to make sure Sun's JRE supports
the same mechanism. Sun's Change Request ID (aka bug ID) is 6593486.
ault value. I've been having some difficulty to think
of default locations for other platforms, especially Windows. So I
wondered if it's OK to make the property value undefined by default.
Would that be acceptable for you?
Thanks,
Masayoshi
On 12/21/2007 11:59 AM, Masayoshi Okutsu wrote:
tion.
Thank you for listening! So... what should be the best way to maintain
tzdata for Java SE installations?
Thanks,
Masayoshi
On 1/26/2008 12:46 AM, Dalibor Topic wrote:
Masayoshi Okutsu <[EMAIL PROTECTED]> writes:
Sorry again for taking time. Finally, I talked to some sustaining te
AM, Martin Buchholz wrote:
Dalibor Topic wrote:
Masayoshi Okutsu wrote:
From the POV of operating system distributors that already need to
support tzdata for other applications, and therefore need to keep it
current anyway for their customers, I think it's preferable to rely on
system f
with a newly
defined timezone. (But that's rare)
If the JDK and the OS agree on the current timezone definition,
all is wonderful. If they differ, perhaps it is worth figuring
out which is newer, even if that is difficult. Perhaps it's worth
snooping around in /usr/share/lib/zoneinfo.
tested the
runtime with some broken tzdata files. There's one problem that the
lookup code doesn't detect infinite recursions, which problem I need to
fix later.
Could you please review the attached diffs? If those changes are OK, I
will proceed with some paper work to get interface ch
Hi Umaoka-san,
Thank you for your proposal. Yes, the TimeZone class has some built-in
assumptions which cause many problems. I had been planning to introduce
some methods, one of which is very similar to your proposal, mainly for
fixing the disambiguation problem during the standard-daylight t
I agree that the revised one is reasonable.
Thanks,
Masayoshi
On 8/14/2008 4:14 AM, Yoshito Umaoka wrote:
Oops.. stupid mistake in the previous note..
> public void getOffset(long date, int[] offsets) {
> if (offsets == null || offsets.length < 2) {
> offsets = new int[2];
> }
on has been made 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
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
descripti
>= 0x1234 && c <= 0xabcd"
when the actual code uses the more readable
"return c >= MIN_FOO && c <= MAX_FOO"
to be kind to readers of the javadoc!
-Joe
Martin
On Tue, Aug 4, 2009 at 22:34, Masayoshi Okutsu
wrote:
Hi Martin,
I vaguely rememb
On 8/10/2009 11:46 AM, Yoshito Umaoka wrote:
Sorry for slow response. I was taking a vacation.
No problem.
Let me ask another question. If you do:
Locale locale = new
Locale.Builder().setLanguage("es").setRegion("ES").setVariant("Traditional_WIN").create();
System.out.println(locale.g
Hi Martin,
Ah, that part needs to handle recursions special. Thank you for catching
this!
Masayoshi
On 8/28/2009 9:06 AM, Martin Buchholz wrote:
Hello i18n gods,
Sorry for being such a stranger to this mailing list.
Anyways, here's a bug report:
If you test java/util/ResourceBundle/Test43
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 t
What is the time zone ID you are using?
Thanks,
Masayoshi
On 12/1/2009 1:55 AM, Bill Tims (RSI) wrote:
From what I can find, this appears to be the right place to post this,
if I'm wrong I would appreciate a pointer to the proper location.
The database our app has to talk to has January 1,190
working file...so far.
Bill Tims
Renaissance Systems, Inc.
5426 Guadalupe, Suite 100
Austin, TX 78751
512-275-0344
-Original Message-
From: gnu.andrew.ro...@gmail.com [mailto:gnu.andrew.ro...@gmail.com] On Behalf
Of Andrew John Hughes
Sent: Wednesday, December 02, 2009 2:10 PM
To: B
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 actually
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 interprete
I believe each code unit of UTF-16 gets converted to its code point. So,
an unpaired surrogate gets converted to a surrogate code point. So, it's
still processed based on code points?
Masayoshi
On 1/24/2011 2:22 PM, Tom Christiansen wrote:
Are you talking about unpaired surrogates or somethin
Alan,
The fix looks good to me.
Thanks,
Masayoshi
On 3/28/2011 11:46 PM, Alan Bateman wrote:
Masayoshi - do you mind reviewing this change to
sun.text.bidi.BidiBase? This one is modularity related and only arises
if Bidi is used when the client/desktop module is not present (not an
issue f
The fix looks good to me.
Masayoshi
On 4/7/2011 5:42 AM, Xueming Shen wrote:
Thanks! webrev has been updated accordingly.
-Sherman
On 04/06/2011 01:29 PM, Alan Bateman wrote:
Xueming Shen wrote:
It appears the aliases mapping for Character.UnicodeScript is not
updated accordingly when
we
On 5/12/2011 5:07 AM, Omair Majid wrote:
Hi,
Andrew John Hughes 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
option to over
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 Hughes writes:
When distros update their timezone data, the data used by OpenJDK also
needs to be updated. At present, this is difficult as
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 "re
uot; that the original
iso-2022-jp c2b converter
actually restores the state back to ASCII mode at the end of its
"convert" method, this makes
the analysis a little complicated, but should not change the issue we
are discussing)
On 02/09/2012 12:26 AM, Masayoshi Okutsu wrote:
F
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
DEFAULT_ZONEINFO_FILE
Looks good to me.
Masayoshi
On 3/13/2012 6:38 PM, Seán Coffey wrote:
Update made. Hopefully the last iteration ;)
http://cr.openjdk.java.net/~coffeys/webrev.7149608.jdk8.4/
regards,
Sean.
On 13/03/2012 05:59, Masayoshi Okutsu wrote:
fd needs to be closed when fstat or malloc failed
Hi Deven,
Here are my comments on the proposed changes.
- zoneIndexCache should be an instance field because WeakHashMap isn't
thread-safe and the order of IDs in zoneStrings differs in each
DateFormatSymbols.
- equals shouldn't be replaced with equalsIgnoreCase because time zone
IDs are (s
ance) is sufficient, instead of keeping
multiple results in a hash map.
I guess majority of use cases repeatedly refer the index of the
zone used by SimpleDateFormat.
-Yoshito
On 4/9/2012 10:46 AM, Masayoshi Okutsu wrote:
Hi Deven,
Here are my comments on the proposed changes.
- zoneIndexCac
04/23/2012 01:19 PM, Masayoshi Okutsu wrote:
Hi Deven,
As Yoshito noted, lastZoneIndex needs to be transient because
DateFormatSymbols is serializable. Otherwise, the change looks good
to me.
Thanks,
Masayoshi
On 4/20/2012 11:56 AM, Deven You wrote:
Yoshito,
It is good to me for your sugg
Hi Charles,
Yes, it's jdk8-tl.
Thanks,
Masayoshi
On 4/23/2012 6:01 PM, Charles Lee wrote:
Hi Masayoshi,
I'd like to sponsor this patch. But I did not figure out which repos
the patch should go to. Is it jdk8-tl repository?
On 04/23/2012 04:54 PM, Masayoshi Okutsu wrote:
Looks good.
Masayoshi
On 5/10/2012 6:58 PM, Seán Coffey wrote:
review request for issue that arose after 7092679 fix.
Without a TZ variable set on solaris, there's possibility for SEGV.
Simple fix.
webrev : http://cr.openjdk.java.net/~coffeys/webrev.7167359.jdk8/
bug : http://bugs.sun.com/bug
Hi Deven,
Sorry for taking time to respond.
This is a known restriction of time zone detection on Windows
currently. There used to be a note on this issue with a workaround
in Java SE release notes, but it seems to be gone some time ago. Is
there any reason
"
This fix use the conjunction of key "DisableAutoDaylightTimeSet"
and tzi.DaylightDate.wMonth to determine if a time zone dose
support DST.
If there is any unclear things please let me know!
Thanks a lot!
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 wrot
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/ScrollSelectio
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 Jonathan,
You seem to have an assumption that the same number of chars (code
units) means the same rendered text width. But that assumption is often
not valid. I'd rather suggest use of locale-neutral formats, such as ISO
8601 date-time formats.
Thanks,
Masayoshi
On 6/20/2012 3:36 PM, Jo
Hi Deven,
Thanks for providing this fix. I've asked our globalization team to
review the fix.
Thanks,
Masayoshi
On 8/7/2012 4:35 PM, Deven You wrote:
Hi All,
I have searched from both wikipedia and windows config, the Venezuela
currency symbol is already updated from "BsF. to " "Bs.F.".
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 in
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.
On 8/15/2012 1:38 AM, Steven R. Loomis wrote:
On Tue, Aug 14, 2012 at 2:03 AM, Masayoshi Okutsu
mailto:masayoshi.oku...@oracle.com>> wrote:
Hi Steven,
Thanks for your comments. Finally we are getting comments on the
i18n part. :-)
You're welcome!
On 8/14/2
On 8/15/2012 1:52 AM, Steven R. Loomis wrote:
On Tue, Aug 14, 2012 at 2:37 AM, Masayoshi Okutsu
mailto:masayoshi.oku...@oracle.com>> wrote:
On 8/14/2012 2:25 PM, Steven R. Loomis wrote:
Naoto,
okay, thought I was done for the night, but just two more
Hi Sean,
LocaleData is a sun private class. It was changed to support different
locale data sources, such as the platform locale data and CLDR. Please
use the public APIs, such as DecimalFormatSymbols, to get
locale-dependent resources. We may change the LocaleData and its related
classes fur
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
Hi Naoto,
Here are my comments.
LocaleProviderAdapter.java:
- After parsing the java.locale.providers value, if typeList is empty,
the default list (JRE,SPI) should be used.
- I don't think the following lines are necessary in getAdapter().
Otherwise, the fix looks good to me.
Thanks,
Masa
r.java 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
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/5/2012 6:51 AM, Naoto Sato wrote:
Hello,
Please review the fix for the following bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198834
Proposed changes are located at:
http://cr.openjdk.java.net/~naoto/7198834/webrev.00/
The fix is just to not leave on
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 a
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.
Otherwise, the fix looks good to me.
Thanks,
Masayoshi
On 10/12/2012 6:45 AM, Naoto Sato
ttp://cr.openjdk.java.net/~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
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.)
- addIm
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 Delega
Question. Does the full set of available locales of JRE still become
available with this fix? For example, when java.locale.providers=SPI,
all JRE locales are included in the getAvailableLocales (API)? The
fallback adapter is an interesting idea, but it's a bit confusing...
Thanks,
Masayoshi
Looks good to me.
Masayoshi
On 10/31/2012 6:55 AM, Naoto Sato wrote:
Here is another simple fix review request. The bug description can be
found at:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001440
The reason of the issue was that the "DefaultNumberingSystem" value
was not retriev
eturn
value (8001562). I will fix it to keep the returned locale array
compatible with JDK7.
Naoto
On 10/30/12 7:43 PM, Masayoshi Okutsu wrote:
Question. Does the full set of available locales of JRE still become
available with this fix? For example, when java.locale.providers=SPI,
all JRE locale
Naoto
On 11/2/12 12:02 PM, Naoto Sato 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 w
Looks good to me.
Masayoshi
On 11/8/2012 4:23 AM, Naoto Sato wrote:
Thanks. I incorporated your comments and generated a new webrev:
http://cr.openjdk.java.net/~naoto/8001205.8001562/webrev.01/
Naoto
On 11/7/12 1:24 AM, Masayoshi Okutsu wrote:
Hi,
Here are my comments
Hello,
Please review the changes for:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000986
In addition to the split, I've improved CalendarDataUtility which now
gets the week parameters through the Pool mechanism.
This one should fix the following concrete problem:
http://bugs.sun.com
est result,
test/java/util/PluggableLocale/GenericTest.java should include the
available locales from CalendarNameProviderImpl for consistency.
Naoto
On 11/9/12 7:59 AM, Masayoshi Okutsu wrote:
Hello,
Please review the changes for:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000986
I
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 implementatio
I was wondering if you plan to address the review comment by David. If
that part gets addressed, I think the test case change is no longer
required. Otherwise, your change to the test program is fine with me.
Thanks,
Masayoshi
On 2012/11/28 21:59, Staffan Larsen wrote:
Did we conclude that my
Hi,
This is a review request for two RFEs.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000983
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003267
http://cr.openjdk.java.net/~okutsu/8/8000983.8003267/webrev.00/
I haven't added generic time zone names to the JRE resources except f
Resending in order to include build-...@openjdk.java.net and
build-in...@openjdk.dev.java.net.
Hi,
This is a review request for two RFEs.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000983
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003267
http://cr.openjdk.java.net/~okutsu/8/
nericTimeZoneNamesTest.sh and NarrowNamesTest.sh were
fixed to detect failures correctly. 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-...@
affect the new build, so it's
ok with the build group.
/Erik
On 2012-12-06 06:06, Masayoshi Okutsu wrote:
Resending in order to include build-...@openjdk.java.net and
build-in...@openjdk.dev.java.net.
Hi,
This is a review request for two RFEs.
http://bugs.sun.com/bugdatabase/vie
make time zone
name translation that can be handled by WPTG translation team? They
currently cannot translate the file in existing format (they can
translate properties files or basic java resource bundles).
thanks,
-michael
On 12年12月05日 09:06 下午, Masayoshi Okutsu wrote:
Resending in order
Looks good to me.
Thanks,
Masayoshi
On 12/27/2012 6:01 PM, Yuka Kamiya wrote:
> Hello,
>
> This is a review request for:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005277
>
> http://cr.openjdk.java.net/~peytoia/8005277/webrev.00/
>
> Thanks,
> --
> Yuka
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
Looks good to me.
Thanks,
Masayoshi
On 1/4/2013 4:59 AM, Seán Coffey wrote:
Masayoshi,
I'm looking to backport this fix which was been soaking in jdk8 for a
few months now.
Fix is identical with the exception of some comment re-ordering and
redeclaring of the javaAWTAccess variable to kee
Looks good to me.
Masayoshi
On 1/12/2013 6:18 AM, Naoto Sato wrote:
Hello,
(To build-dev folks, I am sending this to you as the change includes
one modification in make directory. It is just simply adding a new
Java file, so I think it won't affect the new build-infra structure)
Please rev
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 Loca
tool.
- Removed redundant variable initialization in
CalendarDataUtility.normalizeCalendarType(String).
Revised webrev:
http://cr.openjdk.java.net/~okutsu/8/8004489.8006509/webrev.01/
Thanks,
Masayoshi
On 1/21/2013 1:28 AM, Masayoshi Okutsu wrote:
Hi,
This is a code review request for two RFEs.
It's not correct to use locale's calendar for the fix. The calendar type
needs to be from the Chrono(logy) set to the formatter. The 310 code
needs to be fixed.
Thanks,
Masayoshi
On 1/31/2013 7:02 AM, Naoto Sato wrote:
Hello,
Please review the following changes for 8007038:
http://cr.openjd
a problem in 310 side, but the bug I am
trying to fix is the one in LocaleResources, which is independent of
how 310 code is calling into this getCalendarNames() method.
LocaleResources.getCalendarNames() should return the calendar names
for the specified calendar.
Naoto
On 1/30/13 6:01 PM, Masa
y the fix accordingly.
Naoto
On 1/30/13 11:19 PM, Masayoshi Okutsu wrote:
The caller of CalendarNameProvider is responsible for specifying the
calendar type to use. The locale gives what language to use for names.
Otherwise, a call like provider.getDisplayName("gregory", ERA, 1,
SHORT,
Loca
Looks good to me.
Masayoshi
On 2/7/2013 4:42 AM, Naoto Sato wrote:
OK, revised the fix. Much simpler now. I kept the regression test the
same as webrev.01, for the verification purpose.
http://cr.openjdk.java.net/~naoto/8007038/webrev.02/
Naoto
On 2/5/13 5:10 PM, Masayoshi Okutsu wrote:
I
Looks good to me.
Masayoshi
On 2/19/2013 3:58 AM, Naoto Sato wrote:
Hello,
Please review the proposed changes for the subject CR:
http://bugs.sun.com/view_bug.do?bug_id=7092447
The changes just clarify the current behavior in each locale sensitive
service. It involves no actual code changes
For 8004240, I think adapterPreference should be changed to an
unmodifiable List because getAdapterPreference() is called often.
For 8008577, I think it's a spec change to 6336885, and that CCC
approval is required. And should the CLDR adapter be initialized and be
removed from the list if the
27;.
http://cr.openjdk.java.net/~naoto/8004240/webrev.00/
Naoto
On 2/25/13 11:13 AM, Naoto Sato wrote:
Thank you for the review. Please see my comments embedded below.
On 2/24/13 6:16 PM, Masayoshi Okutsu wrote:
For 8004240, I think adapterPreference should be changed to an
unmodifiable List
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 JapaneseImperialCa
documentation, but the method name
can be changed. How about convertMacOSLocaleToJavaLocale(String macos)
or something else which doesn't contain PosixLocale?
Thanks,
Masayoshi
On 3/12/2013 8:04 AM, Naoto Sato wrote:
Thank you for the review. Please find my comments below:
On 3/11/13 12:
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 on the
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 i
Looks good to me.
Masayoshi
On 3/29/2013 11:25 AM, Seán Coffey wrote:
Masayoshi,
this is a JDK 8 review request for an issue we touched on a good while
back. As suggested by you, fix is to clear ZONE_OFFSET field of the
calendar being built before attempting to set a DST_OFFSET value. I
pla
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:
http:/
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.
LBACK adapter?
Naoto
On 4/3/13 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 maint
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 re
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?bug_id=8013086
The fix is to complement the missing displ
013086/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/
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
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 t
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,
Than
1 - 100 of 354 matches
Mail list logo
