From masayoshi.okutsu at oracle.com  Fri Nov  2 01:08:57 2012
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 02 Nov 2012 17:08:57 +0900
Subject: <i18n dev> [8]Request for review: 8001205)
 Calendar.getDisplayName(...): Returns null when provider is SPI but there
 is no SPI implementation
In-Reply-To: <50909324.1090803@oracle.com>
References: <50904A38.5060505@oracle.com> <5090904D.9080801@oracle.com>
	<50909324.1090803@oracle.com>
Message-ID: <50937F99.3060501@oracle.com>

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 was filed regarding the locale 
> sensitive service APIs' (e.g., Collator) getAvailableLocales() return 
> 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 locales are included in the getAvailableLocales (API)? The
>> fallback adapter is an interesting idea, but it's a bit confusing...
>>
>> Thanks,
>> Masayoshi
>>
>> On 10/31/2012 6:44 AM, Naoto Sato wrote:
>>> Hello,
>>>
>>> Please review the fix for the following bug:
>>>
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001205
>>>
>>> The fix is simply to supply the fallback locale provider adapter for
>>> the root locale, when there is no explicit "JRE" adapter is specified
>>> in the locale provider preference list.
>>>
>>> The proposed fix is located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/8001205/webrev.00/
>>>
>>> Naoto
>>
>


From anthony.petrov at oracle.com  Fri Nov  2 05:43:24 2012
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 02 Nov 2012 16:43:24 +0400
Subject: <i18n dev> <AWT Dev> [8] Review request for 6789984:
 JPasswordField can not receive keyboard input
In-Reply-To: <5092A60A.5020007@oracle.com>
References: <5092A60A.5020007@oracle.com>
Message-ID: <5093BFEC.2050003@oracle.com>

Hi Anton,

I'm not an expert in IM code, but generally the changes look good to me. 
I'm also CC'ing i18n-dev@ to take a look at this fix.

My only concern is that you're changing shared code here. Did you run 
any IM tests on other platforms to make sure no regressions are introduced?

Also, could you please add a comment to the bug report explaining the 
root cause of the issue and how the proposed solution helps resolve it?

--
best regards,
Anthony

On 11/1/2012 8:40 PM, Anton Litvinov wrote:
> Hello,
> 
> Please review the following fix for a bug.
> 
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6789984
> Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.00
> 
> This bug consists in inability of JPasswordField to react on any 
> keyboard events under certain conditions on Linux OS. The webrev does 
> not contain any new "jtreg" test, because a particular Linux OS 
> distribution with additionally installed packages are required for 
> reproduction of the bug.
> 
> Requirements to the environment:
> 1. Oracle Enterprise Linux (OEL) 5.6 x86 64/Oracle Enterprise Linux 
> (OEL) 5.5 x86 64
> 2. Package "scim-anthy-1.2.0-6.el5.x86_64" and its all dependent 
> packages installed on the OS.
> 3. JDK 8.
> 4. A simple Java Swing application, where a dialog with both JTextField 
> and JPasswordField is displayed.
> 
> Thank you,
> Anton

From anton.litvinov at oracle.com  Fri Nov  2 09:24:37 2012
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Fri, 02 Nov 2012 20:24:37 +0400
Subject: <i18n dev> <AWT Dev> [8] Review request for 6789984:
 JPasswordField can not receive keyboard input
In-Reply-To: <5093BFEC.2050003@oracle.com>
References: <5092A60A.5020007@oracle.com> <5093BFEC.2050003@oracle.com>
Message-ID: <5093F3C5.9070609@oracle.com>

Hello Anthony,

Thank you for the review of this fix. I ran only automatic tests, which 
are located in the specified below directories, but on my local Linux 
machine:

    jdk/test/java/awt/im
    jdk/test/java/awt/keyboard
    jdk/test/java/awt/KeyboardFocusmanager
    jdk/test/java/awt/Focus

No, unfortunately, by the current moment I have not run the tests on 
other operating systems yet, but of course I am able to do this at least 
on Windows and Solaris OS and also to try to include manual tests in a 
selection list.

The comment explaining the root cause of the issue with the proposed 
solution was added to the bug's page, but it is not updated yet, 
therefore it is provided below. Also it was found out that this bug can 
be reproduced also on Ubuntu 12.04 amd64 OS. The only requirement to a 
proper environment is presence of the package "scim-anthy" with its all 
dependent packages in the system.

The comment:

    Information Concerning a Cause of the Bug:
    A cause of this bug is the fact that a native Input Method (IM)
    Engine, in current case SCIM, continues consumption or filtering of
    keyboard events during a call to:
         XlibWrapper.XFilterEvent(ev.getPData(), w)
    in ?public void run(boolean loop)? method of ?sun.awt.X11.XToolkit?,
    after it is disabled by a call to:
         ((sun.awt.im.InputContext)inputContext).disableNativeIM();
    in ?void dispatchEventImpl(AWTEvent e)? method of
    ?java.awt.Component?. By filtering the keyboard events SCIM prevents
    them from being dispatched further to AWT event handlers, what
    finally leads to not reception of any keyboard events by a Component
    with disabled IMs like JPasswordField.

    I suppose that a root cause of inability to completely disable IM
    with help of
         public abstract void disableInputMethod()
    method of ?sun.awt.im.InputMethodAdapter? is lack of calls to
    XUnsetICFocus() native function for active and passive input
    contexts in a low level processing inside the procedure
    ?setXICFocusNative? of
    ?jdk/src/solaris/native/sun/awt/awt_InputMethod.c?, which is
    expected to perform the disabling function. When current input
    context is disabled, there are still not disabled active and passive
    input contexts on a low level of native code.

    Found Solution:
    As a solution for this bug I consider inclusion of code disabling
    active and passive input contexts by means of call to
         protected native String resetXIC()
    method of ?sun.awt.X11InputMethod? into the earlier mentioned
    ?disableInputMethod? method of ?sun.awt.im.InputMethodAdapter?
    implementation.


Thank you,
Anton

On 11/2/2012 4:43 PM, Anthony Petrov wrote:
> Hi Anton,
>
> I'm not an expert in IM code, but generally the changes look good to 
> me. I'm also CC'ing i18n-dev@ to take a look at this fix.
>
> My only concern is that you're changing shared code here. Did you run 
> any IM tests on other platforms to make sure no regressions are 
> introduced?
>
> Also, could you please add a comment to the bug report explaining the 
> root cause of the issue and how the proposed solution helps resolve it?
>
> -- 
> best regards,
> Anthony
>
> On 11/1/2012 8:40 PM, Anton Litvinov wrote:
>> Hello,
>>
>> Please review the following fix for a bug.
>>
>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6789984
>> Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.00
>>
>> This bug consists in inability of JPasswordField to react on any 
>> keyboard events under certain conditions on Linux OS. The webrev does 
>> not contain any new "jtreg" test, because a particular Linux OS 
>> distribution with additionally installed packages are required for 
>> reproduction of the bug.
>>
>> Requirements to the environment:
>> 1. Oracle Enterprise Linux (OEL) 5.6 x86 64/Oracle Enterprise Linux 
>> (OEL) 5.5 x86 64
>> 2. Package "scim-anthy-1.2.0-6.el5.x86_64" and its all dependent 
>> packages installed on the OS.
>> 3. JDK 8.
>> 4. A simple Java Swing application, where a dialog with both 
>> JTextField and JPasswordField is displayed.
>>
>> Thank you,
>> Anton

From naoto.sato at oracle.com  Fri Nov  2 10:08:32 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 02 Nov 2012 10:08:32 -0700
Subject: <i18n dev> <AWT Dev> [8] Review request for 6789984:
 JPasswordField can not receive keyboard input
In-Reply-To: <5093BFEC.2050003@oracle.com>
References: <5092A60A.5020007@oracle.com> <5093BFEC.2050003@oracle.com>
Message-ID: <5093FE10.8000805@oracle.com>

Hi Anton,

What's the reason for adding endComposition() in the shared code? 
endComposition() is supposed to end the unfinished composed string that 
is currently in composition, and the bug does not mention anything 
regarding the composition. Also, it looks like the bug is localized only 
to SCIM on Unix platforms, and calling resetXIC() looks just enough in 
XIM handling code to me.

Naoto

On 11/2/12 5:43 AM, Anthony Petrov wrote:
> Hi Anton,
>
> I'm not an expert in IM code, but generally the changes look good to me.
> I'm also CC'ing i18n-dev@ to take a look at this fix.
>
> My only concern is that you're changing shared code here. Did you run
> any IM tests on other platforms to make sure no regressions are introduced?
>
> Also, could you please add a comment to the bug report explaining the
> root cause of the issue and how the proposed solution helps resolve it?
>
> --
> best regards,
> Anthony
>
> On 11/1/2012 8:40 PM, Anton Litvinov wrote:
>> Hello,
>>
>> Please review the following fix for a bug.
>>
>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6789984
>> Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.00
>>
>> This bug consists in inability of JPasswordField to react on any
>> keyboard events under certain conditions on Linux OS. The webrev does
>> not contain any new "jtreg" test, because a particular Linux OS
>> distribution with additionally installed packages are required for
>> reproduction of the bug.
>>
>> Requirements to the environment:
>> 1. Oracle Enterprise Linux (OEL) 5.6 x86 64/Oracle Enterprise Linux
>> (OEL) 5.5 x86 64
>> 2. Package "scim-anthy-1.2.0-6.el5.x86_64" and its all dependent
>> packages installed on the OS.
>> 3. JDK 8.
>> 4. A simple Java Swing application, where a dialog with both
>> JTextField and JPasswordField is displayed.
>>
>> Thank you,
>> Anton


From naoto.sato at oracle.com  Fri Nov  2 12:02:01 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 02 Nov 2012 12:02:01 -0700
Subject: <i18n dev> [8]Request for review: 8001205)
 Calendar.getDisplayName(...): Returns null when provider is SPI but there
 is no SPI implementation
In-Reply-To: <50937F99.3060501@oracle.com>
References: <50904A38.5060505@oracle.com> <5090904D.9080801@oracle.com>
	<50909324.1090803@oracle.com> <50937F99.3060501@oracle.com>
Message-ID: <509418A9.9070207@oracle.com>

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 was filed regarding the locale
>> sensitive service APIs' (e.g., Collator) getAvailableLocales() return
>> 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 locales are included in the getAvailableLocales (API)? The
>>> fallback adapter is an interesting idea, but it's a bit confusing...
>>>
>>> Thanks,
>>> Masayoshi
>>>
>>> On 10/31/2012 6:44 AM, Naoto Sato wrote:
>>>> Hello,
>>>>
>>>> Please review the fix for the following bug:
>>>>
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001205
>>>>
>>>> The fix is simply to supply the fallback locale provider adapter for
>>>> the root locale, when there is no explicit "JRE" adapter is specified
>>>> in the locale provider preference list.
>>>>
>>>> The proposed fix is located at:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8001205/webrev.00/
>>>>
>>>> Naoto
>>>
>>
>


From anton.litvinov at oracle.com  Mon Nov  5 03:14:07 2012
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Mon, 05 Nov 2012 15:14:07 +0400
Subject: <i18n dev> <AWT Dev> [8] Review request for 6789984:
 JPasswordField can not receive keyboard input
In-Reply-To: <5093FE10.8000805@oracle.com>
References: <5092A60A.5020007@oracle.com> <5093BFEC.2050003@oracle.com>
	<5093FE10.8000805@oracle.com>
Message-ID: <50979F7F.7050108@oracle.com>

Hello Naoto,

Thank you for the review. A call to "endComposition()" was added to the 
shared code for resolution of another problem which was additionally 
observed. The problem consists in the fact that some not completely 
composed string inside JTextField can stay in composition state after 
the focus is moved from JTextField to JPasswordField. This not completed 
string marked with underscore disappears from JTextField at the moment 
when JTextField receives focus again. So I decided to make this string 
disappear when a component with disabled input methods, in current case 
JPasswordField, receives focus by a call to "endComposition()" method. 
Perhaps, it would be better to remove this call from the fix at all, 
because absence of end of text composition during switch of focus 
between component with enabled and disabled input methods can be another 
separate issue, would not it? But, on the other hand, since this fix 
brings the case with not composed string to a view, it should contain 
some solution which is specific to Unix platforms.

Also a new comment concerning a root cause of the bug from my view point 
and a proposed solution was added to a page of the bug. Since it is not 
visible on "http://bugs.sun.com" yet, it can be seen on Oracle's 
internal bug tracking resource.

Thank you,
Anton

On 11/2/2012 9:08 PM, Naoto Sato wrote:
> Hi Anton,
>
> What's the reason for adding endComposition() in the shared code? 
> endComposition() is supposed to end the unfinished composed string 
> that is currently in composition, and the bug does not mention 
> anything regarding the composition. Also, it looks like the bug is 
> localized only to SCIM on Unix platforms, and calling resetXIC() looks 
> just enough in XIM handling code to me.
>
> Naoto
>
> On 11/2/12 5:43 AM, Anthony Petrov wrote:
>> Hi Anton,
>>
>> I'm not an expert in IM code, but generally the changes look good to me.
>> I'm also CC'ing i18n-dev@ to take a look at this fix.
>>
>> My only concern is that you're changing shared code here. Did you run
>> any IM tests on other platforms to make sure no regressions are 
>> introduced?
>>
>> Also, could you please add a comment to the bug report explaining the
>> root cause of the issue and how the proposed solution helps resolve it?
>>
>> -- 
>> best regards,
>> Anthony
>>
>> On 11/1/2012 8:40 PM, Anton Litvinov wrote:
>>> Hello,
>>>
>>> Please review the following fix for a bug.
>>>
>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6789984
>>> Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.00
>>>
>>> This bug consists in inability of JPasswordField to react on any
>>> keyboard events under certain conditions on Linux OS. The webrev does
>>> not contain any new "jtreg" test, because a particular Linux OS
>>> distribution with additionally installed packages are required for
>>> reproduction of the bug.
>>>
>>> Requirements to the environment:
>>> 1. Oracle Enterprise Linux (OEL) 5.6 x86 64/Oracle Enterprise Linux
>>> (OEL) 5.5 x86 64
>>> 2. Package "scim-anthy-1.2.0-6.el5.x86_64" and its all dependent
>>> packages installed on the OS.
>>> 3. JDK 8.
>>> 4. A simple Java Swing application, where a dialog with both
>>> JTextField and JPasswordField is displayed.
>>>
>>> Thank you,
>>> Anton
>

From naoto.sato at oracle.com  Tue Nov  6 11:21:04 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 06 Nov 2012 11:21:04 -0800
Subject: <i18n dev> <AWT Dev> [8] Review request for 6789984:
 JPasswordField can not receive keyboard input
In-Reply-To: <50979F7F.7050108@oracle.com>
References: <5092A60A.5020007@oracle.com> <5093BFEC.2050003@oracle.com>
	<5093FE10.8000805@oracle.com> <50979F7F.7050108@oracle.com>
Message-ID: <50996320.2040504@oracle.com>

Hi Anton,

In order for native input methods to not grab the native events, I would 
guess that calling InputMethodAdapter.stopListening() would be the right 
solution to me. Have you tried considering calling this?

Naoto

On 11/5/12 3:14 AM, Anton Litvinov wrote:
> Hello Naoto,
>
> Thank you for the review. A call to "endComposition()" was added to the
> shared code for resolution of another problem which was additionally
> observed. The problem consists in the fact that some not completely
> composed string inside JTextField can stay in composition state after
> the focus is moved from JTextField to JPasswordField. This not completed
> string marked with underscore disappears from JTextField at the moment
> when JTextField receives focus again. So I decided to make this string
> disappear when a component with disabled input methods, in current case
> JPasswordField, receives focus by a call to "endComposition()" method.
> Perhaps, it would be better to remove this call from the fix at all,
> because absence of end of text composition during switch of focus
> between component with enabled and disabled input methods can be another
> separate issue, would not it? But, on the other hand, since this fix
> brings the case with not composed string to a view, it should contain
> some solution which is specific to Unix platforms.
>
> Also a new comment concerning a root cause of the bug from my view point
> and a proposed solution was added to a page of the bug. Since it is not
> visible on "http://bugs.sun.com" yet, it can be seen on Oracle's
> internal bug tracking resource.
>
> Thank you,
> Anton
>
> On 11/2/2012 9:08 PM, Naoto Sato wrote:
>> Hi Anton,
>>
>> What's the reason for adding endComposition() in the shared code?
>> endComposition() is supposed to end the unfinished composed string
>> that is currently in composition, and the bug does not mention
>> anything regarding the composition. Also, it looks like the bug is
>> localized only to SCIM on Unix platforms, and calling resetXIC() looks
>> just enough in XIM handling code to me.
>>
>> Naoto
>>
>> On 11/2/12 5:43 AM, Anthony Petrov wrote:
>>> Hi Anton,
>>>
>>> I'm not an expert in IM code, but generally the changes look good to me.
>>> I'm also CC'ing i18n-dev@ to take a look at this fix.
>>>
>>> My only concern is that you're changing shared code here. Did you run
>>> any IM tests on other platforms to make sure no regressions are
>>> introduced?
>>>
>>> Also, could you please add a comment to the bug report explaining the
>>> root cause of the issue and how the proposed solution helps resolve it?
>>>
>>> --
>>> best regards,
>>> Anthony
>>>
>>> On 11/1/2012 8:40 PM, Anton Litvinov wrote:
>>>> Hello,
>>>>
>>>> Please review the following fix for a bug.
>>>>
>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6789984
>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.00
>>>>
>>>> This bug consists in inability of JPasswordField to react on any
>>>> keyboard events under certain conditions on Linux OS. The webrev does
>>>> not contain any new "jtreg" test, because a particular Linux OS
>>>> distribution with additionally installed packages are required for
>>>> reproduction of the bug.
>>>>
>>>> Requirements to the environment:
>>>> 1. Oracle Enterprise Linux (OEL) 5.6 x86 64/Oracle Enterprise Linux
>>>> (OEL) 5.5 x86 64
>>>> 2. Package "scim-anthy-1.2.0-6.el5.x86_64" and its all dependent
>>>> packages installed on the OS.
>>>> 3. JDK 8.
>>>> 4. A simple Java Swing application, where a dialog with both
>>>> JTextField and JPasswordField is displayed.
>>>>
>>>> Thank you,
>>>> Anton
>>


From naoto.sato at oracle.com  Tue Nov  6 14:17:41 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 06 Nov 2012 14:17:41 -0800
Subject: <i18n dev> [8]Request for review: 8001205)
 Calendar.getDisplayName(...): Returns null when provider is SPI but there
 is no SPI implementation
In-Reply-To: <509418A9.9070207@oracle.com>
References: <50904A38.5060505@oracle.com> <5090904D.9080801@oracle.com>
	<50909324.1090803@oracle.com> <50937F99.3060501@oracle.com>
	<509418A9.9070207@oracle.com>
Message-ID: <50998C85.4050608@oracle.com>

Eventually, I merged the fix for 8001562 with 8001205, and here is the 
combined webrev:

http://cr.openjdk.java.net/~naoto/8001205.8001562/webrev.00/

This version includes the following:

- Previous fix for 8001205
- Fix for 8001562, where available locales for JRE's FormatData locales 
are now included for getAvailableLocales() return values for all locale 
sensitive services (e.g. DateFormat)
- Removed the code for getting rid of Locale.ROOT from the available 
locales. Returning it will not affect the compatibility with JDK7 (it's 
a superset).
- Method name change (getAvailableLocaleList() -> getAvailableLocaleSet()).

Please review.

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 wrote:
>>> With this fix, no. But another bug was filed regarding the locale
>>> sensitive service APIs' (e.g., Collator) getAvailableLocales() return
>>> 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 locales are included in the getAvailableLocales (API)? The
>>>> fallback adapter is an interesting idea, but it's a bit confusing...
>>>>
>>>> Thanks,
>>>> Masayoshi
>>>>
>>>> On 10/31/2012 6:44 AM, Naoto Sato wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the fix for the following bug:
>>>>>
>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001205
>>>>>
>>>>> The fix is simply to supply the fallback locale provider adapter for
>>>>> the root locale, when there is no explicit "JRE" adapter is specified
>>>>> in the locale provider preference list.
>>>>>
>>>>> The proposed fix is located at:
>>>>>
>>>>> http://cr.openjdk.java.net/~naoto/8001205/webrev.00/
>>>>>
>>>>> Naoto
>>>>
>>>
>>
>


From sean.coffey at oracle.com  Tue Nov  6 15:18:04 2012
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Tue, 06 Nov 2012 23:18:04 +0000
Subject: <i18n dev> RFR : 8002227 : (tz) Support tzdata2012i
Message-ID: <50999AAC.5040408@oracle.com>

Looking to bump up the tzdata version in jdk8 and 7u to tzdata2012i 
which was released recently.

This request is for jdk8.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8002227

webrev : http://cr.openjdk.java.net/~coffeys/webrev.tzdata2012i/ 
<http://cr.openjdk.java.net/%7Ecoffeys/webrev.tzdata2012i/>

regards,
Sean.

From yuka.kamiya at oracle.com  Tue Nov  6 17:47:17 2012
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Wed, 07 Nov 2012 10:47:17 +0900
Subject: <i18n dev> RFR : 8002227 : (tz) Support tzdata2012i
In-Reply-To: <50999AAC.5040408@oracle.com>
References: <50999AAC.5040408@oracle.com>
Message-ID: <5099BDA5.7020906@oracle.com>

Hi Se?n,

The fix looks good to me.

Thanks,
--
Yuka

(12/11/07 8:18), Se?n Coffey wrote:
> Looking to bump up the tzdata version in jdk8 and 7u to tzdata2012i which was released recently.
>
> This request is for jdk8.
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8002227
>
> webrev : http://cr.openjdk.java.net/~coffeys/webrev.tzdata2012i/ <http://cr.openjdk.java.net/%7Ecoffeys/webrev.tzdata2012i/>
>
> regards,
> Sean.


From masayoshi.okutsu at oracle.com  Wed Nov  7 01:24:35 2012
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 07 Nov 2012 18:24:35 +0900
Subject: <i18n dev> [8]Request for review: 8001205)
 Calendar.getDisplayName(...): Returns null when provider is SPI but there
 is no SPI implementation
In-Reply-To: <50998C85.4050608@oracle.com>
References: <50904A38.5060505@oracle.com> <5090904D.9080801@oracle.com>
	<50909324.1090803@oracle.com> <50937F99.3060501@oracle.com>
	<509418A9.9070207@oracle.com> <50998C85.4050608@oracle.com>
Message-ID: <509A28D3.8000706@oracle.com>

Hi,

Here are my comments.

- LocaleServiceProviderPool.java:

-     * provider, including the JRE.
+     * provider, including the JRE's FormatData locales.
       *
       * @return an array of the available locales
       */
      public Locale[] getAvailableLocales() {
-        Set<Locale> locList = getAvailableLocaleList();
+        Set<Locale> locList = new HashSet<>();
+        locList.addAll(getAvailableLocaleSet());
+        // Make sure it all contains JRE's FormatData locales for compatibility.

It's not accurate to say FormatData locales. The FormatData locales list is no longer a superset.
  
- <> should be used where it's applicable.

- test/java/util/Locale/Bug8001562.java: line 37 is too long...


Otherwise, the fixes look good to me.

Masayoshi


On 11/7/2012 7:17 AM, Naoto Sato wrote:
> Eventually, I merged the fix for 8001562 with 8001205, and here is the 
> combined webrev:
>
> http://cr.openjdk.java.net/~naoto/8001205.8001562/webrev.00/
>
> This version includes the following:
>
> - Previous fix for 8001205
> - Fix for 8001562, where available locales for JRE's FormatData 
> locales are now included for getAvailableLocales() return values for 
> all locale sensitive services (e.g. DateFormat)
> - Removed the code for getting rid of Locale.ROOT from the available 
> locales. Returning it will not affect the compatibility with JDK7 
> (it's a superset).
> - Method name change (getAvailableLocaleList() -> 
> getAvailableLocaleSet()).
>
> Please review.
>
> 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 wrote:
>>>> With this fix, no. But another bug was filed regarding the locale
>>>> sensitive service APIs' (e.g., Collator) getAvailableLocales() return
>>>> 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 locales are included in the getAvailableLocales (API)? The
>>>>> fallback adapter is an interesting idea, but it's a bit confusing...
>>>>>
>>>>> Thanks,
>>>>> Masayoshi
>>>>>
>>>>> On 10/31/2012 6:44 AM, Naoto Sato wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review the fix for the following bug:
>>>>>>
>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001205
>>>>>>
>>>>>> The fix is simply to supply the fallback locale provider adapter for
>>>>>> the root locale, when there is no explicit "JRE" adapter is 
>>>>>> specified
>>>>>> in the locale provider preference list.
>>>>>>
>>>>>> The proposed fix is located at:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~naoto/8001205/webrev.00/
>>>>>>
>>>>>> Naoto
>>>>>
>>>>
>>>
>>
>


From anton.litvinov at oracle.com  Wed Nov  7 08:11:09 2012
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Wed, 07 Nov 2012 20:11:09 +0400
Subject: <i18n dev> <AWT Dev> [8] Review request for 6789984:
 JPasswordField can not receive keyboard input
In-Reply-To: <50996320.2040504@oracle.com>
References: <5092A60A.5020007@oracle.com> <5093BFEC.2050003@oracle.com>
	<5093FE10.8000805@oracle.com> <50979F7F.7050108@oracle.com>
	<50996320.2040504@oracle.com>
Message-ID: <509A881D.7090303@oracle.com>

Hello Naoto,

Yes, sure, I tried calling "stopListening()" method. But it does not 
lead to complete disabling of the input methods and appearance of the 
opportunity of entering a text into JPasswordField, when some 
composition started in JTextField before switch of focus from the last 
one to JPasswordField. Such situation happens, because "resetXIC()" is 
not called after "disableInputMethod()" inside "stopListening()" of 
"sun.awt.X11InputMethod" for the reason of unset flag "needResetXIC" 
after a call to "endComposition()". I think that I need to substitute a 
part of the fix calling to "endComposition()" and "disableInputMethod()" 
inside "disableNativeIM()" of "sun.awt.im.InputContext" for one call to 
"stopListening()". But before providing a next version of the fix for a 
review I will have to run regression tests connected with IM on 
platforms other than Linux and it will require some time.

Thank you,
Anton

On 11/6/2012 11:21 PM, Naoto Sato wrote:
> Hi Anton,
>
> In order for native input methods to not grab the native events, I 
> would guess that calling InputMethodAdapter.stopListening() would be 
> the right solution to me. Have you tried considering calling this?
>
> Naoto
>
> On 11/5/12 3:14 AM, Anton Litvinov wrote:
>> Hello Naoto,
>>
>> Thank you for the review. A call to "endComposition()" was added to the
>> shared code for resolution of another problem which was additionally
>> observed. The problem consists in the fact that some not completely
>> composed string inside JTextField can stay in composition state after
>> the focus is moved from JTextField to JPasswordField. This not completed
>> string marked with underscore disappears from JTextField at the moment
>> when JTextField receives focus again. So I decided to make this string
>> disappear when a component with disabled input methods, in current case
>> JPasswordField, receives focus by a call to "endComposition()" method.
>> Perhaps, it would be better to remove this call from the fix at all,
>> because absence of end of text composition during switch of focus
>> between component with enabled and disabled input methods can be another
>> separate issue, would not it? But, on the other hand, since this fix
>> brings the case with not composed string to a view, it should contain
>> some solution which is specific to Unix platforms.
>>
>> Also a new comment concerning a root cause of the bug from my view point
>> and a proposed solution was added to a page of the bug. Since it is not
>> visible on "http://bugs.sun.com" yet, it can be seen on Oracle's
>> internal bug tracking resource.
>>
>> Thank you,
>> Anton
>>
>> On 11/2/2012 9:08 PM, Naoto Sato wrote:
>>> Hi Anton,
>>>
>>> What's the reason for adding endComposition() in the shared code?
>>> endComposition() is supposed to end the unfinished composed string
>>> that is currently in composition, and the bug does not mention
>>> anything regarding the composition. Also, it looks like the bug is
>>> localized only to SCIM on Unix platforms, and calling resetXIC() looks
>>> just enough in XIM handling code to me.
>>>
>>> Naoto
>>>
>>> On 11/2/12 5:43 AM, Anthony Petrov wrote:
>>>> Hi Anton,
>>>>
>>>> I'm not an expert in IM code, but generally the changes look good 
>>>> to me.
>>>> I'm also CC'ing i18n-dev@ to take a look at this fix.
>>>>
>>>> My only concern is that you're changing shared code here. Did you run
>>>> any IM tests on other platforms to make sure no regressions are
>>>> introduced?
>>>>
>>>> Also, could you please add a comment to the bug report explaining the
>>>> root cause of the issue and how the proposed solution helps resolve 
>>>> it?
>>>>
>>>> -- 
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 11/1/2012 8:40 PM, Anton Litvinov wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the following fix for a bug.
>>>>>
>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6789984
>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.00
>>>>>
>>>>> This bug consists in inability of JPasswordField to react on any
>>>>> keyboard events under certain conditions on Linux OS. The webrev does
>>>>> not contain any new "jtreg" test, because a particular Linux OS
>>>>> distribution with additionally installed packages are required for
>>>>> reproduction of the bug.
>>>>>
>>>>> Requirements to the environment:
>>>>> 1. Oracle Enterprise Linux (OEL) 5.6 x86 64/Oracle Enterprise Linux
>>>>> (OEL) 5.5 x86 64
>>>>> 2. Package "scim-anthy-1.2.0-6.el5.x86_64" and its all dependent
>>>>> packages installed on the OS.
>>>>> 3. JDK 8.
>>>>> 4. A simple Java Swing application, where a dialog with both
>>>>> JTextField and JPasswordField is displayed.
>>>>>
>>>>> Thank you,
>>>>> Anton
>>>
>

From naoto.sato at oracle.com  Wed Nov  7 10:03:25 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 07 Nov 2012 10:03:25 -0800
Subject: <i18n dev> <AWT Dev> [8] Review request for 6789984:
 JPasswordField can not receive keyboard input
In-Reply-To: <509A881D.7090303@oracle.com>
References: <5092A60A.5020007@oracle.com> <5093BFEC.2050003@oracle.com>
	<5093FE10.8000805@oracle.com> <50979F7F.7050108@oracle.com>
	<50996320.2040504@oracle.com> <509A881D.7090303@oracle.com>
Message-ID: <509AA26D.9030708@oracle.com>

Thank you for trying stopListening() out. Later I figured out that this 
method is only used when the input method instance switches the 
underlying input method engine from native OS's InputMethodAdapter 
instance to pure Java input method, so in this problem case it may not 
seem to apply. Let me know your further findings.

Naoto

On 11/7/12 8:11 AM, Anton Litvinov wrote:
> Hello Naoto,
>
> Yes, sure, I tried calling "stopListening()" method. But it does not
> lead to complete disabling of the input methods and appearance of the
> opportunity of entering a text into JPasswordField, when some
> composition started in JTextField before switch of focus from the last
> one to JPasswordField. Such situation happens, because "resetXIC()" is
> not called after "disableInputMethod()" inside "stopListening()" of
> "sun.awt.X11InputMethod" for the reason of unset flag "needResetXIC"
> after a call to "endComposition()". I think that I need to substitute a
> part of the fix calling to "endComposition()" and "disableInputMethod()"
> inside "disableNativeIM()" of "sun.awt.im.InputContext" for one call to
> "stopListening()". But before providing a next version of the fix for a
> review I will have to run regression tests connected with IM on
> platforms other than Linux and it will require some time.
>
> Thank you,
> Anton
>
> On 11/6/2012 11:21 PM, Naoto Sato wrote:
>> Hi Anton,
>>
>> In order for native input methods to not grab the native events, I
>> would guess that calling InputMethodAdapter.stopListening() would be
>> the right solution to me. Have you tried considering calling this?
>>
>> Naoto
>>
>> On 11/5/12 3:14 AM, Anton Litvinov wrote:
>>> Hello Naoto,
>>>
>>> Thank you for the review. A call to "endComposition()" was added to the
>>> shared code for resolution of another problem which was additionally
>>> observed. The problem consists in the fact that some not completely
>>> composed string inside JTextField can stay in composition state after
>>> the focus is moved from JTextField to JPasswordField. This not completed
>>> string marked with underscore disappears from JTextField at the moment
>>> when JTextField receives focus again. So I decided to make this string
>>> disappear when a component with disabled input methods, in current case
>>> JPasswordField, receives focus by a call to "endComposition()" method.
>>> Perhaps, it would be better to remove this call from the fix at all,
>>> because absence of end of text composition during switch of focus
>>> between component with enabled and disabled input methods can be another
>>> separate issue, would not it? But, on the other hand, since this fix
>>> brings the case with not composed string to a view, it should contain
>>> some solution which is specific to Unix platforms.
>>>
>>> Also a new comment concerning a root cause of the bug from my view point
>>> and a proposed solution was added to a page of the bug. Since it is not
>>> visible on "http://bugs.sun.com" yet, it can be seen on Oracle's
>>> internal bug tracking resource.
>>>
>>> Thank you,
>>> Anton
>>>
>>> On 11/2/2012 9:08 PM, Naoto Sato wrote:
>>>> Hi Anton,
>>>>
>>>> What's the reason for adding endComposition() in the shared code?
>>>> endComposition() is supposed to end the unfinished composed string
>>>> that is currently in composition, and the bug does not mention
>>>> anything regarding the composition. Also, it looks like the bug is
>>>> localized only to SCIM on Unix platforms, and calling resetXIC() looks
>>>> just enough in XIM handling code to me.
>>>>
>>>> Naoto
>>>>
>>>> On 11/2/12 5:43 AM, Anthony Petrov wrote:
>>>>> Hi Anton,
>>>>>
>>>>> I'm not an expert in IM code, but generally the changes look good
>>>>> to me.
>>>>> I'm also CC'ing i18n-dev@ to take a look at this fix.
>>>>>
>>>>> My only concern is that you're changing shared code here. Did you run
>>>>> any IM tests on other platforms to make sure no regressions are
>>>>> introduced?
>>>>>
>>>>> Also, could you please add a comment to the bug report explaining the
>>>>> root cause of the issue and how the proposed solution helps resolve
>>>>> it?
>>>>>
>>>>> --
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 11/1/2012 8:40 PM, Anton Litvinov wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review the following fix for a bug.
>>>>>>
>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6789984
>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.00
>>>>>>
>>>>>> This bug consists in inability of JPasswordField to react on any
>>>>>> keyboard events under certain conditions on Linux OS. The webrev does
>>>>>> not contain any new "jtreg" test, because a particular Linux OS
>>>>>> distribution with additionally installed packages are required for
>>>>>> reproduction of the bug.
>>>>>>
>>>>>> Requirements to the environment:
>>>>>> 1. Oracle Enterprise Linux (OEL) 5.6 x86 64/Oracle Enterprise Linux
>>>>>> (OEL) 5.5 x86 64
>>>>>> 2. Package "scim-anthy-1.2.0-6.el5.x86_64" and its all dependent
>>>>>> packages installed on the OS.
>>>>>> 3. JDK 8.
>>>>>> 4. A simple Java Swing application, where a dialog with both
>>>>>> JTextField and JPasswordField is displayed.
>>>>>>
>>>>>> Thank you,
>>>>>> Anton
>>>>
>>


From naoto.sato at oracle.com  Wed Nov  7 11:23:35 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 07 Nov 2012 11:23:35 -0800
Subject: <i18n dev> [8]Request for review: 8001205)
 Calendar.getDisplayName(...): Returns null when provider is SPI but there
 is no SPI implementation
In-Reply-To: <509A28D3.8000706@oracle.com>
References: <50904A38.5060505@oracle.com> <5090904D.9080801@oracle.com>
	<50909324.1090803@oracle.com> <50937F99.3060501@oracle.com>
	<509418A9.9070207@oracle.com> <50998C85.4050608@oracle.com>
	<509A28D3.8000706@oracle.com>
Message-ID: <509AB537.9080301@oracle.com>

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.
>
> - LocaleServiceProviderPool.java:
>
> - * provider, including the JRE.
> + * provider, including the JRE's FormatData locales.
> *
> * @return an array of the available locales
> */
> public Locale[] getAvailableLocales() {
> - Set<Locale> locList = getAvailableLocaleList();
> + Set<Locale> locList = new HashSet<>();
> + locList.addAll(getAvailableLocaleSet());
> + // Make sure it all contains JRE's FormatData locales for compatibility.
>
> It's not accurate to say FormatData locales. The FormatData locales list
> is no longer a superset.
>
> - <> should be used where it's applicable.
>
> - test/java/util/Locale/Bug8001562.java: line 37 is too long...
>
>
> Otherwise, the fixes look good to me.
>
> Masayoshi
>
>
> On 11/7/2012 7:17 AM, Naoto Sato wrote:
>> Eventually, I merged the fix for 8001562 with 8001205, and here is the
>> combined webrev:
>>
>> http://cr.openjdk.java.net/~naoto/8001205.8001562/webrev.00/
>>
>> This version includes the following:
>>
>> - Previous fix for 8001205
>> - Fix for 8001562, where available locales for JRE's FormatData
>> locales are now included for getAvailableLocales() return values for
>> all locale sensitive services (e.g. DateFormat)
>> - Removed the code for getting rid of Locale.ROOT from the available
>> locales. Returning it will not affect the compatibility with JDK7
>> (it's a superset).
>> - Method name change (getAvailableLocaleList() ->
>> getAvailableLocaleSet()).
>>
>> Please review.
>>
>> 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 wrote:
>>>>> With this fix, no. But another bug was filed regarding the locale
>>>>> sensitive service APIs' (e.g., Collator) getAvailableLocales() return
>>>>> 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 locales are included in the getAvailableLocales (API)? The
>>>>>> fallback adapter is an interesting idea, but it's a bit confusing...
>>>>>>
>>>>>> Thanks,
>>>>>> Masayoshi
>>>>>>
>>>>>> On 10/31/2012 6:44 AM, Naoto Sato wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review the fix for the following bug:
>>>>>>>
>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001205
>>>>>>>
>>>>>>> The fix is simply to supply the fallback locale provider adapter for
>>>>>>> the root locale, when there is no explicit "JRE" adapter is
>>>>>>> specified
>>>>>>> in the locale provider preference list.
>>>>>>>
>>>>>>> The proposed fix is located at:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~naoto/8001205/webrev.00/
>>>>>>>
>>>>>>> Naoto
>>>>>>
>>>>>
>>>>
>>>
>>
>


From masayoshi.okutsu at oracle.com  Wed Nov  7 14:56:39 2012
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 08 Nov 2012 07:56:39 +0900
Subject: <i18n dev> [8]Request for review: 8001205)
 Calendar.getDisplayName(...): Returns null when provider is SPI but there
 is no SPI implementation
In-Reply-To: <509AB537.9080301@oracle.com>
References: <50904A38.5060505@oracle.com> <5090904D.9080801@oracle.com>
	<50909324.1090803@oracle.com> <50937F99.3060501@oracle.com>
	<509418A9.9070207@oracle.com> <50998C85.4050608@oracle.com>
	<509A28D3.8000706@oracle.com> <509AB537.9080301@oracle.com>
Message-ID: <509AE727.3060104@oracle.com>

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.
>>
>> - LocaleServiceProviderPool.java:
>>
>> - * provider, including the JRE.
>> + * provider, including the JRE's FormatData locales.
>> *
>> * @return an array of the available locales
>> */
>> public Locale[] getAvailableLocales() {
>> - Set<Locale> locList = getAvailableLocaleList();
>> + Set<Locale> locList = new HashSet<>();
>> + locList.addAll(getAvailableLocaleSet());
>> + // Make sure it all contains JRE's FormatData locales for 
>> compatibility.
>>
>> It's not accurate to say FormatData locales. The FormatData locales list
>> is no longer a superset.
>>
>> - <> should be used where it's applicable.
>>
>> - test/java/util/Locale/Bug8001562.java: line 37 is too long...
>>
>>
>> Otherwise, the fixes look good to me.
>>
>> Masayoshi
>>
>>
>> On 11/7/2012 7:17 AM, Naoto Sato wrote:
>>> Eventually, I merged the fix for 8001562 with 8001205, and here is the
>>> combined webrev:
>>>
>>> http://cr.openjdk.java.net/~naoto/8001205.8001562/webrev.00/
>>>
>>> This version includes the following:
>>>
>>> - Previous fix for 8001205
>>> - Fix for 8001562, where available locales for JRE's FormatData
>>> locales are now included for getAvailableLocales() return values for
>>> all locale sensitive services (e.g. DateFormat)
>>> - Removed the code for getting rid of Locale.ROOT from the available
>>> locales. Returning it will not affect the compatibility with JDK7
>>> (it's a superset).
>>> - Method name change (getAvailableLocaleList() ->
>>> getAvailableLocaleSet()).
>>>
>>> Please review.
>>>
>>> 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 wrote:
>>>>>> With this fix, no. But another bug was filed regarding the locale
>>>>>> sensitive service APIs' (e.g., Collator) getAvailableLocales() 
>>>>>> return
>>>>>> 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 locales are included in the getAvailableLocales (API)? The
>>>>>>> fallback adapter is an interesting idea, but it's a bit 
>>>>>>> confusing...
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Masayoshi
>>>>>>>
>>>>>>> On 10/31/2012 6:44 AM, Naoto Sato wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Please review the fix for the following bug:
>>>>>>>>
>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001205
>>>>>>>>
>>>>>>>> The fix is simply to supply the fallback locale provider 
>>>>>>>> adapter for
>>>>>>>> the root locale, when there is no explicit "JRE" adapter is
>>>>>>>> specified
>>>>>>>> in the locale provider preference list.
>>>>>>>>
>>>>>>>> The proposed fix is located at:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~naoto/8001205/webrev.00/
>>>>>>>>
>>>>>>>> Naoto
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


From masayoshi.okutsu at oracle.com  Fri Nov  9 07:59:18 2012
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Sat, 10 Nov 2012 00:59:18 +0900
Subject: <i18n dev> [8] Request for review: 8000986: Split
 java.util.spi.CalendarDataProvider into week parameters and field names
 portions
Message-ID: <509D2856.2030607@oracle.com>

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/bugdatabase/view_bug.do?bug_id=8000964

I've manually tested this one, but I didn't take the test case because 
it depends on localization data. We need to rely on the test case 
developed by the SQE team.

Webrev:

http://cr.openjdk.java.net/~okutsu/8/8000986/webrev.00/

Thanks,
Masayoshi





From naoto.sato at oracle.com  Fri Nov  9 11:41:32 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 09 Nov 2012 11:41:32 -0800
Subject: <i18n dev> [8] Request for review: 8000986: Split
 java.util.spi.CalendarDataProvider into week parameters and field names
 portions
In-Reply-To: <509D2856.2030607@oracle.com>
References: <509D2856.2030607@oracle.com>
Message-ID: <509D5C6C.7060901@oracle.com>

I have just one comment. Although it won't affect the test 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
>
> 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/bugdatabase/view_bug.do?bug_id=8000964
>
> I've manually tested this one, but I didn't take the test case because
> it depends on localization data. We need to rely on the test case
> developed by the SQE team.
>
> Webrev:
>
> http://cr.openjdk.java.net/~okutsu/8/8000986/webrev.00/
>
> Thanks,
> Masayoshi
>
>
>
>


From masayoshi.okutsu at oracle.com  Fri Nov  9 17:08:40 2012
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Sat, 10 Nov 2012 10:08:40 +0900
Subject: <i18n dev> [8] Request for review: 8000986: Split
 java.util.spi.CalendarDataProvider into week parameters and field names
 portions
In-Reply-To: <509D5C6C.7060901@oracle.com>
References: <509D2856.2030607@oracle.com> <509D5C6C.7060901@oracle.com>
Message-ID: <509DA918.7010603@oracle.com>

Thanks. I added CalendarNameProviderImpl to GenericTest.java. The test 
passed.

I've updated webrev. No other changes.

http://cr.openjdk.java.net/~okutsu/8/8000986/webrev.01/

Masayoshi

On 11/10/2012 4:41 AM, Naoto Sato wrote:
> I have just one comment. Although it won't affect the test 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
>>
>> 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/bugdatabase/view_bug.do?bug_id=8000964
>>
>> I've manually tested this one, but I didn't take the test case because
>> it depends on localization data. We need to rely on the test case
>> developed by the SQE team.
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~okutsu/8/8000986/webrev.00/
>>
>> Thanks,
>> Masayoshi
>>
>>
>>
>>
>


From naoto.sato at oracle.com  Fri Nov  9 17:15:15 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 09 Nov 2012 17:15:15 -0800
Subject: <i18n dev> [8] Request for review: 8000986: Split
 java.util.spi.CalendarDataProvider into week parameters and field names
 portions
In-Reply-To: <509DA918.7010603@oracle.com>
References: <509D2856.2030607@oracle.com> <509D5C6C.7060901@oracle.com>
	<509DA918.7010603@oracle.com>
Message-ID: <509DAAA3.5080204@oracle.com>

Thanks. The change looks good to me.

Naoto

On 11/9/12 5:08 PM, Masayoshi Okutsu wrote:
> Thanks. I added CalendarNameProviderImpl to GenericTest.java. The test
> passed.
>
> I've updated webrev. No other changes.
>
> http://cr.openjdk.java.net/~okutsu/8/8000986/webrev.01/
>
> Masayoshi
>
> On 11/10/2012 4:41 AM, Naoto Sato wrote:
>> I have just one comment. Although it won't affect the test 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
>>>
>>> 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/bugdatabase/view_bug.do?bug_id=8000964
>>>
>>> I've manually tested this one, but I didn't take the test case because
>>> it depends on localization data. We need to rely on the test case
>>> developed by the SQE team.
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~okutsu/8/8000986/webrev.00/
>>>
>>> Thanks,
>>> Masayoshi
>>>
>>>
>>>
>>>
>>
>


From anton.litvinov at oracle.com  Sun Nov 11 12:07:03 2012
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Mon, 12 Nov 2012 00:07:03 +0400
Subject: <i18n dev> <AWT Dev> [8] Review request for 6789984:
 JPasswordField can not receive keyboard input
In-Reply-To: <509AA26D.9030708@oracle.com>
References: <5092A60A.5020007@oracle.com> <5093BFEC.2050003@oracle.com>
	<5093FE10.8000805@oracle.com> <50979F7F.7050108@oracle.com>
	<50996320.2040504@oracle.com> <509A881D.7090303@oracle.com>
	<509AA26D.9030708@oracle.com>
Message-ID: <50A00567.1060505@oracle.com>

Hello Naoto,

Could you, please, review a modified version of the fix, where a former 
duplicating code "endComposition();disableInputMethod()" was substituted 
for one call to "stopListening()". Also larger testing of the fix was 
done on Linux and Windows machine.

Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.01

I came to a conclusion that substitution of call to 
"disableInputMethod()" for "stopListening()" in 
"sun.awt.im.InputContext", which is code shared between different 
platforms, will not lead to any changes on platforms other than Linux 
and Solaris. In order to prove this the following facts are provided:

 1. Windows implementation of InputMethodAdapter
    "jdk/src/windows/classes/sun/awt/windows/WInputMethod.java" does
    nothing except calling "disableInputMethod()" from its overridden
    "stopListening()", which means that this fix will not change the
    logic in Windows implementation.
 2. Mac OS implementation of InputMethodAdapter
    "jdk/src/macosx/classes/sun/lwawt/macosx/CInputMethod.java" does not
    override "stopListening()" at all and has just a stub implementation
    of "disableInputMethod()", thus the fix cannot influence behavior of
    InputMethodAdapter on Mac OS.

The following tests were run on Linux and Windows with enabled input 
methods, and no negative changes in tests' results for JDK without/with 
fix were observed:

 1. Manual/automatic jtreg tests from java/awt/im directory.
 2. Automatic jtreg tests from Focus, keyboard, KeyboardFocusmanager
    directories.
 3. JCK tests from "api/java_awt/im" and "api/java_awt/InputMethod".


Thank you,
Anton


On 11/7/2012 10:03 PM, Naoto Sato wrote:
> Thank you for trying stopListening() out. Later I figured out that 
> this method is only used when the input method instance switches the 
> underlying input method engine from native OS's InputMethodAdapter 
> instance to pure Java input method, so in this problem case it may not 
> seem to apply. Let me know your further findings.
>
> Naoto
>
> On 11/7/12 8:11 AM, Anton Litvinov wrote:
>> Hello Naoto,
>>
>> Yes, sure, I tried calling "stopListening()" method. But it does not
>> lead to complete disabling of the input methods and appearance of the
>> opportunity of entering a text into JPasswordField, when some
>> composition started in JTextField before switch of focus from the last
>> one to JPasswordField. Such situation happens, because "resetXIC()" is
>> not called after "disableInputMethod()" inside "stopListening()" of
>> "sun.awt.X11InputMethod" for the reason of unset flag "needResetXIC"
>> after a call to "endComposition()". I think that I need to substitute a
>> part of the fix calling to "endComposition()" and "disableInputMethod()"
>> inside "disableNativeIM()" of "sun.awt.im.InputContext" for one call to
>> "stopListening()". But before providing a next version of the fix for a
>> review I will have to run regression tests connected with IM on
>> platforms other than Linux and it will require some time.
>>
>> Thank you,
>> Anton
>>
>> On 11/6/2012 11:21 PM, Naoto Sato wrote:
>>> Hi Anton,
>>>
>>> In order for native input methods to not grab the native events, I
>>> would guess that calling InputMethodAdapter.stopListening() would be
>>> the right solution to me. Have you tried considering calling this?
>>>
>>> Naoto
>>>
>>> On 11/5/12 3:14 AM, Anton Litvinov wrote:
>>>> Hello Naoto,
>>>>
>>>> Thank you for the review. A call to "endComposition()" was added to 
>>>> the
>>>> shared code for resolution of another problem which was additionally
>>>> observed. The problem consists in the fact that some not completely
>>>> composed string inside JTextField can stay in composition state after
>>>> the focus is moved from JTextField to JPasswordField. This not 
>>>> completed
>>>> string marked with underscore disappears from JTextField at the moment
>>>> when JTextField receives focus again. So I decided to make this string
>>>> disappear when a component with disabled input methods, in current 
>>>> case
>>>> JPasswordField, receives focus by a call to "endComposition()" method.
>>>> Perhaps, it would be better to remove this call from the fix at all,
>>>> because absence of end of text composition during switch of focus
>>>> between component with enabled and disabled input methods can be 
>>>> another
>>>> separate issue, would not it? But, on the other hand, since this fix
>>>> brings the case with not composed string to a view, it should contain
>>>> some solution which is specific to Unix platforms.
>>>>
>>>> Also a new comment concerning a root cause of the bug from my view 
>>>> point
>>>> and a proposed solution was added to a page of the bug. Since it is 
>>>> not
>>>> visible on "http://bugs.sun.com" yet, it can be seen on Oracle's
>>>> internal bug tracking resource.
>>>>
>>>> Thank you,
>>>> Anton
>>>>
>>>> On 11/2/2012 9:08 PM, Naoto Sato wrote:
>>>>> Hi Anton,
>>>>>
>>>>> What's the reason for adding endComposition() in the shared code?
>>>>> endComposition() is supposed to end the unfinished composed string
>>>>> that is currently in composition, and the bug does not mention
>>>>> anything regarding the composition. Also, it looks like the bug is
>>>>> localized only to SCIM on Unix platforms, and calling resetXIC() 
>>>>> looks
>>>>> just enough in XIM handling code to me.
>>>>>
>>>>> Naoto
>>>>>
>>>>> On 11/2/12 5:43 AM, Anthony Petrov wrote:
>>>>>> Hi Anton,
>>>>>>
>>>>>> I'm not an expert in IM code, but generally the changes look good
>>>>>> to me.
>>>>>> I'm also CC'ing i18n-dev@ to take a look at this fix.
>>>>>>
>>>>>> My only concern is that you're changing shared code here. Did you 
>>>>>> run
>>>>>> any IM tests on other platforms to make sure no regressions are
>>>>>> introduced?
>>>>>>
>>>>>> Also, could you please add a comment to the bug report explaining 
>>>>>> the
>>>>>> root cause of the issue and how the proposed solution helps resolve
>>>>>> it?
>>>>>>
>>>>>> -- 
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>> On 11/1/2012 8:40 PM, Anton Litvinov wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review the following fix for a bug.
>>>>>>>
>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6789984
>>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.00
>>>>>>>
>>>>>>> This bug consists in inability of JPasswordField to react on any
>>>>>>> keyboard events under certain conditions on Linux OS. The webrev 
>>>>>>> does
>>>>>>> not contain any new "jtreg" test, because a particular Linux OS
>>>>>>> distribution with additionally installed packages are required for
>>>>>>> reproduction of the bug.
>>>>>>>
>>>>>>> Requirements to the environment:
>>>>>>> 1. Oracle Enterprise Linux (OEL) 5.6 x86 64/Oracle Enterprise Linux
>>>>>>> (OEL) 5.5 x86 64
>>>>>>> 2. Package "scim-anthy-1.2.0-6.el5.x86_64" and its all dependent
>>>>>>> packages installed on the OS.
>>>>>>> 3. JDK 8.
>>>>>>> 4. A simple Java Swing application, where a dialog with both
>>>>>>> JTextField and JPasswordField is displayed.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Anton
>>>>>
>>>
>

From naoto.sato at oracle.com  Mon Nov 12 15:08:19 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 12 Nov 2012 15:08:19 -0800
Subject: <i18n dev> <AWT Dev> [8] Review request for 6789984:
 JPasswordField can not receive keyboard input
In-Reply-To: <50A00567.1060505@oracle.com>
References: <5092A60A.5020007@oracle.com> <5093BFEC.2050003@oracle.com>
	<5093FE10.8000805@oracle.com> <50979F7F.7050108@oracle.com>
	<50996320.2040504@oracle.com> <509A881D.7090303@oracle.com>
	<509AA26D.9030708@oracle.com> <50A00567.1060505@oracle.com>
Message-ID: <50A18163.9040801@oracle.com>

The fix looks good. I'd suggest modifying the comment for 
sun.awt.im.InputMethodAdapter.stopListening() too, since the method is 
now being issued even when Java input method is not active.

Also, please make sure there is no issue on switching the input method 
between the input method adapter and a Java input method, such as 
CodePointInputMethod which is in the JDK demo directory.

Thanks!
Naoto

On 11/11/12 12:07 PM, Anton Litvinov wrote:
> Hello Naoto,
>
> Could you, please, review a modified version of the fix, where a former
> duplicating code "endComposition();disableInputMethod()" was substituted
> for one call to "stopListening()". Also larger testing of the fix was
> done on Linux and Windows machine.
>
> Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.01
>
> I came to a conclusion that substitution of call to
> "disableInputMethod()" for "stopListening()" in
> "sun.awt.im.InputContext", which is code shared between different
> platforms, will not lead to any changes on platforms other than Linux
> and Solaris. In order to prove this the following facts are provided:
>
>  1. Windows implementation of InputMethodAdapter
>     "jdk/src/windows/classes/sun/awt/windows/WInputMethod.java" does
>     nothing except calling "disableInputMethod()" from its overridden
>     "stopListening()", which means that this fix will not change the
>     logic in Windows implementation.
>  2. Mac OS implementation of InputMethodAdapter
>     "jdk/src/macosx/classes/sun/lwawt/macosx/CInputMethod.java" does not
>     override "stopListening()" at all and has just a stub implementation
>     of "disableInputMethod()", thus the fix cannot influence behavior of
>     InputMethodAdapter on Mac OS.
>
> The following tests were run on Linux and Windows with enabled input
> methods, and no negative changes in tests' results for JDK without/with
> fix were observed:
>
>  1. Manual/automatic jtreg tests from java/awt/im directory.
>  2. Automatic jtreg tests from Focus, keyboard, KeyboardFocusmanager
>     directories.
>  3. JCK tests from "api/java_awt/im" and "api/java_awt/InputMethod".
>
>
> Thank you,
> Anton
>
>
> On 11/7/2012 10:03 PM, Naoto Sato wrote:
>> Thank you for trying stopListening() out. Later I figured out that
>> this method is only used when the input method instance switches the
>> underlying input method engine from native OS's InputMethodAdapter
>> instance to pure Java input method, so in this problem case it may not
>> seem to apply. Let me know your further findings.
>>
>> Naoto
>>
>> On 11/7/12 8:11 AM, Anton Litvinov wrote:
>>> Hello Naoto,
>>>
>>> Yes, sure, I tried calling "stopListening()" method. But it does not
>>> lead to complete disabling of the input methods and appearance of the
>>> opportunity of entering a text into JPasswordField, when some
>>> composition started in JTextField before switch of focus from the last
>>> one to JPasswordField. Such situation happens, because "resetXIC()" is
>>> not called after "disableInputMethod()" inside "stopListening()" of
>>> "sun.awt.X11InputMethod" for the reason of unset flag "needResetXIC"
>>> after a call to "endComposition()". I think that I need to substitute a
>>> part of the fix calling to "endComposition()" and "disableInputMethod()"
>>> inside "disableNativeIM()" of "sun.awt.im.InputContext" for one call to
>>> "stopListening()". But before providing a next version of the fix for a
>>> review I will have to run regression tests connected with IM on
>>> platforms other than Linux and it will require some time.
>>>
>>> Thank you,
>>> Anton
>>>
>>> On 11/6/2012 11:21 PM, Naoto Sato wrote:
>>>> Hi Anton,
>>>>
>>>> In order for native input methods to not grab the native events, I
>>>> would guess that calling InputMethodAdapter.stopListening() would be
>>>> the right solution to me. Have you tried considering calling this?
>>>>
>>>> Naoto
>>>>
>>>> On 11/5/12 3:14 AM, Anton Litvinov wrote:
>>>>> Hello Naoto,
>>>>>
>>>>> Thank you for the review. A call to "endComposition()" was added to
>>>>> the
>>>>> shared code for resolution of another problem which was additionally
>>>>> observed. The problem consists in the fact that some not completely
>>>>> composed string inside JTextField can stay in composition state after
>>>>> the focus is moved from JTextField to JPasswordField. This not
>>>>> completed
>>>>> string marked with underscore disappears from JTextField at the moment
>>>>> when JTextField receives focus again. So I decided to make this string
>>>>> disappear when a component with disabled input methods, in current
>>>>> case
>>>>> JPasswordField, receives focus by a call to "endComposition()" method.
>>>>> Perhaps, it would be better to remove this call from the fix at all,
>>>>> because absence of end of text composition during switch of focus
>>>>> between component with enabled and disabled input methods can be
>>>>> another
>>>>> separate issue, would not it? But, on the other hand, since this fix
>>>>> brings the case with not composed string to a view, it should contain
>>>>> some solution which is specific to Unix platforms.
>>>>>
>>>>> Also a new comment concerning a root cause of the bug from my view
>>>>> point
>>>>> and a proposed solution was added to a page of the bug. Since it is
>>>>> not
>>>>> visible on "http://bugs.sun.com" yet, it can be seen on Oracle's
>>>>> internal bug tracking resource.
>>>>>
>>>>> Thank you,
>>>>> Anton
>>>>>
>>>>> On 11/2/2012 9:08 PM, Naoto Sato wrote:
>>>>>> Hi Anton,
>>>>>>
>>>>>> What's the reason for adding endComposition() in the shared code?
>>>>>> endComposition() is supposed to end the unfinished composed string
>>>>>> that is currently in composition, and the bug does not mention
>>>>>> anything regarding the composition. Also, it looks like the bug is
>>>>>> localized only to SCIM on Unix platforms, and calling resetXIC()
>>>>>> looks
>>>>>> just enough in XIM handling code to me.
>>>>>>
>>>>>> Naoto
>>>>>>
>>>>>> On 11/2/12 5:43 AM, Anthony Petrov wrote:
>>>>>>> Hi Anton,
>>>>>>>
>>>>>>> I'm not an expert in IM code, but generally the changes look good
>>>>>>> to me.
>>>>>>> I'm also CC'ing i18n-dev@ to take a look at this fix.
>>>>>>>
>>>>>>> My only concern is that you're changing shared code here. Did you
>>>>>>> run
>>>>>>> any IM tests on other platforms to make sure no regressions are
>>>>>>> introduced?
>>>>>>>
>>>>>>> Also, could you please add a comment to the bug report explaining
>>>>>>> the
>>>>>>> root cause of the issue and how the proposed solution helps resolve
>>>>>>> it?
>>>>>>>
>>>>>>> --
>>>>>>> best regards,
>>>>>>> Anthony
>>>>>>>
>>>>>>> On 11/1/2012 8:40 PM, Anton Litvinov wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Please review the following fix for a bug.
>>>>>>>>
>>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6789984
>>>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.00
>>>>>>>>
>>>>>>>> This bug consists in inability of JPasswordField to react on any
>>>>>>>> keyboard events under certain conditions on Linux OS. The webrev
>>>>>>>> does
>>>>>>>> not contain any new "jtreg" test, because a particular Linux OS
>>>>>>>> distribution with additionally installed packages are required for
>>>>>>>> reproduction of the bug.
>>>>>>>>
>>>>>>>> Requirements to the environment:
>>>>>>>> 1. Oracle Enterprise Linux (OEL) 5.6 x86 64/Oracle Enterprise Linux
>>>>>>>> (OEL) 5.5 x86 64
>>>>>>>> 2. Package "scim-anthy-1.2.0-6.el5.x86_64" and its all dependent
>>>>>>>> packages installed on the OS.
>>>>>>>> 3. JDK 8.
>>>>>>>> 4. A simple Java Swing application, where a dialog with both
>>>>>>>> JTextField and JPasswordField is displayed.
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Anton
>>>>>>
>>>>
>>


From sean.coffey at oracle.com  Tue Nov 13 04:33:24 2012
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Tue, 13 Nov 2012 12:33:24 +0000
Subject: <i18n dev> RFR : 8002227 : (tz) Support tzdata2012i
In-Reply-To: <5099BDA5.7020906@oracle.com>
References: <5099BDA5.7020906@oracle.com>
Message-ID: <50A23E14.2080209@oracle.com>

Looking to bump up the tzdata version in jdk7u-dev also.

webrev : http://cr.openjdk.java.net/~coffeys/webrev.2012i.jdk7u/ 
<http://cr.openjdk.java.net/%7Ecoffeys/webrev.2012i.jdk7u/>

regards,
Sean.

-------- Original Message --------
Subject: 	Re: RFR : 8002227 : (tz) Support tzdata2012i
Date: 	Wed, 07 Nov 2012 10:47:17 +0900
From: 	Yuka Kamiya <yuka.kamiya at oracle.com>
To: 	Se?n Coffey <sean.coffey at oracle.com>
CC: 	i18n-dev <i18n-dev at openjdk.java.net>



Hi Se?n,

The fix looks good to me.

Thanks,
--
Yuka

(12/11/07 8:18), Se?n Coffey wrote:
> Looking to bump up the tzdata version in jdk8 and 7u to tzdata2012i which was released recently.
>
> This request is for jdk8.
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8002227
>
> webrev : http://cr.openjdk.java.net/~coffeys/webrev.tzdata2012i/ <http://cr.openjdk.java.net/%7Ecoffeys/webrev.tzdata2012i/>
>
> regards,
> Sean.





From anton.litvinov at oracle.com  Tue Nov 13 06:54:52 2012
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Tue, 13 Nov 2012 18:54:52 +0400
Subject: <i18n dev> <AWT Dev> [8] Review request for 6789984:
 JPasswordField can not receive keyboard input
In-Reply-To: <50A18163.9040801@oracle.com>
References: <5092A60A.5020007@oracle.com> <5093BFEC.2050003@oracle.com>
	<5093FE10.8000805@oracle.com> <50979F7F.7050108@oracle.com>
	<50996320.2040504@oracle.com> <509A881D.7090303@oracle.com>
	<509AA26D.9030708@oracle.com> <50A00567.1060505@oracle.com>
	<50A18163.9040801@oracle.com>
Message-ID: <50A25F3C.7080203@oracle.com>

Hello Naoto,

Thank you for reviewing this fix and pointing to a directory with Java 
input method (IM) implementation. Could you review a new version of the 
webrev containing a correction in comments of 
"sun.awt.im.InputMethodAdapter.stopListening()". In comparison with 
previous webrev the new one has additional changes only in 
"InputMethodAdapter.java".

Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.02

The fix was manually tested with Java input methods (IMs) and native IMs 
loaded simultaneously on Linux and Windows hosts. "CodePointIM.jar" and 
"CityIM.jar" were used as Java IMs. No cases of loosing of ability to 
enter text into JPasswordField were observed after switches from Java to 
native IMs and vice versa. Also the IMs did loose their functional 
capabilities between those switches.

Thank you,
Anton


On 11/13/2012 3:08 AM, Naoto Sato wrote:
> The fix looks good. I'd suggest modifying the comment for 
> sun.awt.im.InputMethodAdapter.stopListening() too, since the method is 
> now being issued even when Java input method is not active.
>
> Also, please make sure there is no issue on switching the input method 
> between the input method adapter and a Java input method, such as 
> CodePointInputMethod which is in the JDK demo directory.
>
> Thanks!
> Naoto
>
> On 11/11/12 12:07 PM, Anton Litvinov wrote:
>> Hello Naoto,
>>
>> Could you, please, review a modified version of the fix, where a former
>> duplicating code "endComposition();disableInputMethod()" was substituted
>> for one call to "stopListening()". Also larger testing of the fix was
>> done on Linux and Windows machine.
>>
>> Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.01
>>
>> I came to a conclusion that substitution of call to
>> "disableInputMethod()" for "stopListening()" in
>> "sun.awt.im.InputContext", which is code shared between different
>> platforms, will not lead to any changes on platforms other than Linux
>> and Solaris. In order to prove this the following facts are provided:
>>
>>  1. Windows implementation of InputMethodAdapter
>>     "jdk/src/windows/classes/sun/awt/windows/WInputMethod.java" does
>>     nothing except calling "disableInputMethod()" from its overridden
>>     "stopListening()", which means that this fix will not change the
>>     logic in Windows implementation.
>>  2. Mac OS implementation of InputMethodAdapter
>>     "jdk/src/macosx/classes/sun/lwawt/macosx/CInputMethod.java" does not
>>     override "stopListening()" at all and has just a stub implementation
>>     of "disableInputMethod()", thus the fix cannot influence behavior of
>>     InputMethodAdapter on Mac OS.
>>
>> The following tests were run on Linux and Windows with enabled input
>> methods, and no negative changes in tests' results for JDK without/with
>> fix were observed:
>>
>>  1. Manual/automatic jtreg tests from java/awt/im directory.
>>  2. Automatic jtreg tests from Focus, keyboard, KeyboardFocusmanager
>>     directories.
>>  3. JCK tests from "api/java_awt/im" and "api/java_awt/InputMethod".
>>
>>
>> Thank you,
>> Anton
>>
>>
>> On 11/7/2012 10:03 PM, Naoto Sato wrote:
>>> Thank you for trying stopListening() out. Later I figured out that
>>> this method is only used when the input method instance switches the
>>> underlying input method engine from native OS's InputMethodAdapter
>>> instance to pure Java input method, so in this problem case it may not
>>> seem to apply. Let me know your further findings.
>>>
>>> Naoto
>>>
>>> On 11/7/12 8:11 AM, Anton Litvinov wrote:
>>>> Hello Naoto,
>>>>
>>>> Yes, sure, I tried calling "stopListening()" method. But it does not
>>>> lead to complete disabling of the input methods and appearance of the
>>>> opportunity of entering a text into JPasswordField, when some
>>>> composition started in JTextField before switch of focus from the last
>>>> one to JPasswordField. Such situation happens, because "resetXIC()" is
>>>> not called after "disableInputMethod()" inside "stopListening()" of
>>>> "sun.awt.X11InputMethod" for the reason of unset flag "needResetXIC"
>>>> after a call to "endComposition()". I think that I need to 
>>>> substitute a
>>>> part of the fix calling to "endComposition()" and 
>>>> "disableInputMethod()"
>>>> inside "disableNativeIM()" of "sun.awt.im.InputContext" for one 
>>>> call to
>>>> "stopListening()". But before providing a next version of the fix 
>>>> for a
>>>> review I will have to run regression tests connected with IM on
>>>> platforms other than Linux and it will require some time.
>>>>
>>>> Thank you,
>>>> Anton
>>>>
>>>> On 11/6/2012 11:21 PM, Naoto Sato wrote:
>>>>> Hi Anton,
>>>>>
>>>>> In order for native input methods to not grab the native events, I
>>>>> would guess that calling InputMethodAdapter.stopListening() would be
>>>>> the right solution to me. Have you tried considering calling this?
>>>>>
>>>>> Naoto
>>>>>
>>>>> On 11/5/12 3:14 AM, Anton Litvinov wrote:
>>>>>> Hello Naoto,
>>>>>>
>>>>>> Thank you for the review. A call to "endComposition()" was added to
>>>>>> the
>>>>>> shared code for resolution of another problem which was additionally
>>>>>> observed. The problem consists in the fact that some not completely
>>>>>> composed string inside JTextField can stay in composition state 
>>>>>> after
>>>>>> the focus is moved from JTextField to JPasswordField. This not
>>>>>> completed
>>>>>> string marked with underscore disappears from JTextField at the 
>>>>>> moment
>>>>>> when JTextField receives focus again. So I decided to make this 
>>>>>> string
>>>>>> disappear when a component with disabled input methods, in current
>>>>>> case
>>>>>> JPasswordField, receives focus by a call to "endComposition()" 
>>>>>> method.
>>>>>> Perhaps, it would be better to remove this call from the fix at all,
>>>>>> because absence of end of text composition during switch of focus
>>>>>> between component with enabled and disabled input methods can be
>>>>>> another
>>>>>> separate issue, would not it? But, on the other hand, since this fix
>>>>>> brings the case with not composed string to a view, it should 
>>>>>> contain
>>>>>> some solution which is specific to Unix platforms.
>>>>>>
>>>>>> Also a new comment concerning a root cause of the bug from my view
>>>>>> point
>>>>>> and a proposed solution was added to a page of the bug. Since it is
>>>>>> not
>>>>>> visible on "http://bugs.sun.com" yet, it can be seen on Oracle's
>>>>>> internal bug tracking resource.
>>>>>>
>>>>>> Thank you,
>>>>>> Anton
>>>>>>
>>>>>> On 11/2/2012 9:08 PM, Naoto Sato wrote:
>>>>>>> Hi Anton,
>>>>>>>
>>>>>>> What's the reason for adding endComposition() in the shared code?
>>>>>>> endComposition() is supposed to end the unfinished composed string
>>>>>>> that is currently in composition, and the bug does not mention
>>>>>>> anything regarding the composition. Also, it looks like the bug is
>>>>>>> localized only to SCIM on Unix platforms, and calling resetXIC()
>>>>>>> looks
>>>>>>> just enough in XIM handling code to me.
>>>>>>>
>>>>>>> Naoto
>>>>>>>
>>>>>>> On 11/2/12 5:43 AM, Anthony Petrov wrote:
>>>>>>>> Hi Anton,
>>>>>>>>
>>>>>>>> I'm not an expert in IM code, but generally the changes look good
>>>>>>>> to me.
>>>>>>>> I'm also CC'ing i18n-dev@ to take a look at this fix.
>>>>>>>>
>>>>>>>> My only concern is that you're changing shared code here. Did you
>>>>>>>> run
>>>>>>>> any IM tests on other platforms to make sure no regressions are
>>>>>>>> introduced?
>>>>>>>>
>>>>>>>> Also, could you please add a comment to the bug report explaining
>>>>>>>> the
>>>>>>>> root cause of the issue and how the proposed solution helps 
>>>>>>>> resolve
>>>>>>>> it?
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> best regards,
>>>>>>>> Anthony
>>>>>>>>
>>>>>>>> On 11/1/2012 8:40 PM, Anton Litvinov wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Please review the following fix for a bug.
>>>>>>>>>
>>>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6789984
>>>>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.00
>>>>>>>>>
>>>>>>>>> This bug consists in inability of JPasswordField to react on any
>>>>>>>>> keyboard events under certain conditions on Linux OS. The webrev
>>>>>>>>> does
>>>>>>>>> not contain any new "jtreg" test, because a particular Linux OS
>>>>>>>>> distribution with additionally installed packages are required 
>>>>>>>>> for
>>>>>>>>> reproduction of the bug.
>>>>>>>>>
>>>>>>>>> Requirements to the environment:
>>>>>>>>> 1. Oracle Enterprise Linux (OEL) 5.6 x86 64/Oracle Enterprise 
>>>>>>>>> Linux
>>>>>>>>> (OEL) 5.5 x86 64
>>>>>>>>> 2. Package "scim-anthy-1.2.0-6.el5.x86_64" and its all dependent
>>>>>>>>> packages installed on the OS.
>>>>>>>>> 3. JDK 8.
>>>>>>>>> 4. A simple Java Swing application, where a dialog with both
>>>>>>>>> JTextField and JPasswordField is displayed.
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>> Anton
>>>>>>>
>>>>>
>>>
>

From naoto.sato at oracle.com  Tue Nov 13 09:30:28 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 13 Nov 2012 09:30:28 -0800
Subject: <i18n dev> <AWT Dev> [8] Review request for 6789984:
 JPasswordField can not receive keyboard input
In-Reply-To: <50A25F3C.7080203@oracle.com>
References: <5092A60A.5020007@oracle.com> <5093BFEC.2050003@oracle.com>
	<5093FE10.8000805@oracle.com> <50979F7F.7050108@oracle.com>
	<50996320.2040504@oracle.com> <509A881D.7090303@oracle.com>
	<509AA26D.9030708@oracle.com> <50A00567.1060505@oracle.com>
	<50A18163.9040801@oracle.com> <50A25F3C.7080203@oracle.com>
Message-ID: <50A283B4.9070702@oracle.com>

Looks good to me. Thank you for fixing this IM bug!

Naoto

On 11/13/12 6:54 AM, Anton Litvinov wrote:
> Hello Naoto,
>
> Thank you for reviewing this fix and pointing to a directory with Java
> input method (IM) implementation. Could you review a new version of the
> webrev containing a correction in comments of
> "sun.awt.im.InputMethodAdapter.stopListening()". In comparison with
> previous webrev the new one has additional changes only in
> "InputMethodAdapter.java".
>
> Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.02
>
> The fix was manually tested with Java input methods (IMs) and native IMs
> loaded simultaneously on Linux and Windows hosts. "CodePointIM.jar" and
> "CityIM.jar" were used as Java IMs. No cases of loosing of ability to
> enter text into JPasswordField were observed after switches from Java to
> native IMs and vice versa. Also the IMs did loose their functional
> capabilities between those switches.
>
> Thank you,
> Anton
>
>
> On 11/13/2012 3:08 AM, Naoto Sato wrote:
>> The fix looks good. I'd suggest modifying the comment for
>> sun.awt.im.InputMethodAdapter.stopListening() too, since the method is
>> now being issued even when Java input method is not active.
>>
>> Also, please make sure there is no issue on switching the input method
>> between the input method adapter and a Java input method, such as
>> CodePointInputMethod which is in the JDK demo directory.
>>
>> Thanks!
>> Naoto
>>
>> On 11/11/12 12:07 PM, Anton Litvinov wrote:
>>> Hello Naoto,
>>>
>>> Could you, please, review a modified version of the fix, where a former
>>> duplicating code "endComposition();disableInputMethod()" was substituted
>>> for one call to "stopListening()". Also larger testing of the fix was
>>> done on Linux and Windows machine.
>>>
>>> Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.01
>>>
>>> I came to a conclusion that substitution of call to
>>> "disableInputMethod()" for "stopListening()" in
>>> "sun.awt.im.InputContext", which is code shared between different
>>> platforms, will not lead to any changes on platforms other than Linux
>>> and Solaris. In order to prove this the following facts are provided:
>>>
>>>  1. Windows implementation of InputMethodAdapter
>>>     "jdk/src/windows/classes/sun/awt/windows/WInputMethod.java" does
>>>     nothing except calling "disableInputMethod()" from its overridden
>>>     "stopListening()", which means that this fix will not change the
>>>     logic in Windows implementation.
>>>  2. Mac OS implementation of InputMethodAdapter
>>>     "jdk/src/macosx/classes/sun/lwawt/macosx/CInputMethod.java" does not
>>>     override "stopListening()" at all and has just a stub implementation
>>>     of "disableInputMethod()", thus the fix cannot influence behavior of
>>>     InputMethodAdapter on Mac OS.
>>>
>>> The following tests were run on Linux and Windows with enabled input
>>> methods, and no negative changes in tests' results for JDK without/with
>>> fix were observed:
>>>
>>>  1. Manual/automatic jtreg tests from java/awt/im directory.
>>>  2. Automatic jtreg tests from Focus, keyboard, KeyboardFocusmanager
>>>     directories.
>>>  3. JCK tests from "api/java_awt/im" and "api/java_awt/InputMethod".
>>>
>>>
>>> Thank you,
>>> Anton
>>>
>>>
>>> On 11/7/2012 10:03 PM, Naoto Sato wrote:
>>>> Thank you for trying stopListening() out. Later I figured out that
>>>> this method is only used when the input method instance switches the
>>>> underlying input method engine from native OS's InputMethodAdapter
>>>> instance to pure Java input method, so in this problem case it may not
>>>> seem to apply. Let me know your further findings.
>>>>
>>>> Naoto
>>>>
>>>> On 11/7/12 8:11 AM, Anton Litvinov wrote:
>>>>> Hello Naoto,
>>>>>
>>>>> Yes, sure, I tried calling "stopListening()" method. But it does not
>>>>> lead to complete disabling of the input methods and appearance of the
>>>>> opportunity of entering a text into JPasswordField, when some
>>>>> composition started in JTextField before switch of focus from the last
>>>>> one to JPasswordField. Such situation happens, because "resetXIC()" is
>>>>> not called after "disableInputMethod()" inside "stopListening()" of
>>>>> "sun.awt.X11InputMethod" for the reason of unset flag "needResetXIC"
>>>>> after a call to "endComposition()". I think that I need to
>>>>> substitute a
>>>>> part of the fix calling to "endComposition()" and
>>>>> "disableInputMethod()"
>>>>> inside "disableNativeIM()" of "sun.awt.im.InputContext" for one
>>>>> call to
>>>>> "stopListening()". But before providing a next version of the fix
>>>>> for a
>>>>> review I will have to run regression tests connected with IM on
>>>>> platforms other than Linux and it will require some time.
>>>>>
>>>>> Thank you,
>>>>> Anton
>>>>>
>>>>> On 11/6/2012 11:21 PM, Naoto Sato wrote:
>>>>>> Hi Anton,
>>>>>>
>>>>>> In order for native input methods to not grab the native events, I
>>>>>> would guess that calling InputMethodAdapter.stopListening() would be
>>>>>> the right solution to me. Have you tried considering calling this?
>>>>>>
>>>>>> Naoto
>>>>>>
>>>>>> On 11/5/12 3:14 AM, Anton Litvinov wrote:
>>>>>>> Hello Naoto,
>>>>>>>
>>>>>>> Thank you for the review. A call to "endComposition()" was added to
>>>>>>> the
>>>>>>> shared code for resolution of another problem which was additionally
>>>>>>> observed. The problem consists in the fact that some not completely
>>>>>>> composed string inside JTextField can stay in composition state
>>>>>>> after
>>>>>>> the focus is moved from JTextField to JPasswordField. This not
>>>>>>> completed
>>>>>>> string marked with underscore disappears from JTextField at the
>>>>>>> moment
>>>>>>> when JTextField receives focus again. So I decided to make this
>>>>>>> string
>>>>>>> disappear when a component with disabled input methods, in current
>>>>>>> case
>>>>>>> JPasswordField, receives focus by a call to "endComposition()"
>>>>>>> method.
>>>>>>> Perhaps, it would be better to remove this call from the fix at all,
>>>>>>> because absence of end of text composition during switch of focus
>>>>>>> between component with enabled and disabled input methods can be
>>>>>>> another
>>>>>>> separate issue, would not it? But, on the other hand, since this fix
>>>>>>> brings the case with not composed string to a view, it should
>>>>>>> contain
>>>>>>> some solution which is specific to Unix platforms.
>>>>>>>
>>>>>>> Also a new comment concerning a root cause of the bug from my view
>>>>>>> point
>>>>>>> and a proposed solution was added to a page of the bug. Since it is
>>>>>>> not
>>>>>>> visible on "http://bugs.sun.com" yet, it can be seen on Oracle's
>>>>>>> internal bug tracking resource.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Anton
>>>>>>>
>>>>>>> On 11/2/2012 9:08 PM, Naoto Sato wrote:
>>>>>>>> Hi Anton,
>>>>>>>>
>>>>>>>> What's the reason for adding endComposition() in the shared code?
>>>>>>>> endComposition() is supposed to end the unfinished composed string
>>>>>>>> that is currently in composition, and the bug does not mention
>>>>>>>> anything regarding the composition. Also, it looks like the bug is
>>>>>>>> localized only to SCIM on Unix platforms, and calling resetXIC()
>>>>>>>> looks
>>>>>>>> just enough in XIM handling code to me.
>>>>>>>>
>>>>>>>> Naoto
>>>>>>>>
>>>>>>>> On 11/2/12 5:43 AM, Anthony Petrov wrote:
>>>>>>>>> Hi Anton,
>>>>>>>>>
>>>>>>>>> I'm not an expert in IM code, but generally the changes look good
>>>>>>>>> to me.
>>>>>>>>> I'm also CC'ing i18n-dev@ to take a look at this fix.
>>>>>>>>>
>>>>>>>>> My only concern is that you're changing shared code here. Did you
>>>>>>>>> run
>>>>>>>>> any IM tests on other platforms to make sure no regressions are
>>>>>>>>> introduced?
>>>>>>>>>
>>>>>>>>> Also, could you please add a comment to the bug report explaining
>>>>>>>>> the
>>>>>>>>> root cause of the issue and how the proposed solution helps
>>>>>>>>> resolve
>>>>>>>>> it?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> best regards,
>>>>>>>>> Anthony
>>>>>>>>>
>>>>>>>>> On 11/1/2012 8:40 PM, Anton Litvinov wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Please review the following fix for a bug.
>>>>>>>>>>
>>>>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6789984
>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.00
>>>>>>>>>>
>>>>>>>>>> This bug consists in inability of JPasswordField to react on any
>>>>>>>>>> keyboard events under certain conditions on Linux OS. The webrev
>>>>>>>>>> does
>>>>>>>>>> not contain any new "jtreg" test, because a particular Linux OS
>>>>>>>>>> distribution with additionally installed packages are required
>>>>>>>>>> for
>>>>>>>>>> reproduction of the bug.
>>>>>>>>>>
>>>>>>>>>> Requirements to the environment:
>>>>>>>>>> 1. Oracle Enterprise Linux (OEL) 5.6 x86 64/Oracle Enterprise
>>>>>>>>>> Linux
>>>>>>>>>> (OEL) 5.5 x86 64
>>>>>>>>>> 2. Package "scim-anthy-1.2.0-6.el5.x86_64" and its all dependent
>>>>>>>>>> packages installed on the OS.
>>>>>>>>>> 3. JDK 8.
>>>>>>>>>> 4. A simple Java Swing application, where a dialog with both
>>>>>>>>>> JTextField and JPasswordField is displayed.
>>>>>>>>>>
>>>>>>>>>> Thank you,
>>>>>>>>>> Anton
>>>>>>>>
>>>>>>
>>>>
>>


From yuka.kamiya at oracle.com  Tue Nov 13 17:37:12 2012
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Wed, 14 Nov 2012 10:37:12 +0900
Subject: <i18n dev> RFR : 8002227 : (tz) Support tzdata2012i
In-Reply-To: <50999AAC.5040408@oracle.com>
References: <50999AAC.5040408@oracle.com>
Message-ID: <50A2F5C8.5050901@oracle.com>

It looks ok to me.

Thanks,
--
Yuka

(12/11/07 8:18), Se?n Coffey wrote:
> Looking to bump up the tzdata version in jdk8 and 7u to tzdata2012i which was released recently.
>
> This request is for jdk8.
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8002227
>
> webrev : http://cr.openjdk.java.net/~coffeys/webrev.tzdata2012i/ <http://cr.openjdk.java.net/%7Ecoffeys/webrev.tzdata2012i/>
>
> regards,
> Sean.


From anthony.petrov at oracle.com  Thu Nov 15 05:51:15 2012
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Thu, 15 Nov 2012 17:51:15 +0400
Subject: <i18n dev> <AWT Dev> [7u12] Review request for 6789984:
 JPasswordField can not receive keyboard input
In-Reply-To: <50A4AB3D.6020002@oracle.com>
References: <50A4AB3D.6020002@oracle.com>
Message-ID: <50A4F353.5080209@oracle.com>

(also cc'ing i18n-dev@)

Approved, provided the code compiles and works as expected in the 7u 
release.

--
best regards,
Anthony

On 11/15/12 12:43, Anton Litvinov wrote:
> Hello,
>
> Please review the following fix for a bug. It is a backport of the fix
> which is already reviewed and committed into JDK 8 repository. This fix
> is identical to the fix for JDK 8.
>
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6789984
> Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.02
> JDK 8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f32a0aee7bb9
>
> Thank you,
> Anton

From naoto.sato at oracle.com  Thu Nov 15 11:49:59 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 15 Nov 2012 11:49:59 -0800
Subject: <i18n dev> [8] Request for review: 7199750: Loading sequence of
 service provider is changed
Message-ID: <50A54767.3020900@oracle.com>

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 implementations for the same 
locale, the latter one found through ServiceLoader.loadInstalled() is 
invoked, which is incompatible with JDK7. With this fix, it has the same 
behavior with JDK7 where the firstly found one is used.

Naoto

From masayoshi.okutsu at oracle.com  Thu Nov 15 15:16:24 2012
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 16 Nov 2012 08:16:24 +0900
Subject: <i18n dev> [8] Request for review: 7199750: Loading sequence of
 service provider is changed
In-Reply-To: <50A54767.3020900@oracle.com>
References: <50A54767.3020900@oracle.com>
Message-ID: <50A577C8.6090206@oracle.com>

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 implementations for the same 
> locale, the latter one found through ServiceLoader.loadInstalled() is 
> invoked, which is incompatible with JDK7. With this fix, it has the 
> same behavior with JDK7 where the firstly found one is used.
>
> Naoto


From anton.litvinov at oracle.com  Fri Nov 16 05:57:34 2012
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Fri, 16 Nov 2012 17:57:34 +0400
Subject: <i18n dev> <AWT Dev> [7u12] Review request for 6789984:
 JPasswordField can not receive keyboard input
In-Reply-To: <50A4F353.5080209@oracle.com>
References: <50A4AB3D.6020002@oracle.com> <50A4F353.5080209@oracle.com>
Message-ID: <50A6464E.9030609@oracle.com>

Hello Naoto,

Since you approved this fix for JDK 8 originally, could you please 
review this fix for JDK 7 also. Currently this request has one approval 
from AWT team and the second lacking approval is a prerequisite for a 
subsequent push approval request.

Thank you,
Anton

On 11/15/2012 5:51 PM, Anthony Petrov wrote:
> (also cc'ing i18n-dev@)
>
> Approved, provided the code compiles and works as expected in the 7u 
> release.
>
> -- 
> best regards,
> Anthony
>
> On 11/15/12 12:43, Anton Litvinov wrote:
>> Hello,
>>
>> Please review the following fix for a bug. It is a backport of the fix
>> which is already reviewed and committed into JDK 8 repository. This fix
>> is identical to the fix for JDK 8.
>>
>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6789984
>> Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.02
>> JDK 8 changeset: 
>> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f32a0aee7bb9
>>
>> Thank you,
>> Anton

From naoto.sato at oracle.com  Fri Nov 16 09:38:58 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 16 Nov 2012 09:38:58 -0800
Subject: <i18n dev> <AWT Dev> [7u12] Review request for 6789984:
 JPasswordField can not receive keyboard input
In-Reply-To: <50A6464E.9030609@oracle.com>
References: <50A4AB3D.6020002@oracle.com> <50A4F353.5080209@oracle.com>
	<50A6464E.9030609@oracle.com>
Message-ID: <50A67A32.8000803@oracle.com>

Looks good to me.

Naoto

On 11/16/12 5:57 AM, Anton Litvinov wrote:
> Hello Naoto,
>
> Since you approved this fix for JDK 8 originally, could you please
> review this fix for JDK 7 also. Currently this request has one approval
> from AWT team and the second lacking approval is a prerequisite for a
> subsequent push approval request.
>
> Thank you,
> Anton
>
> On 11/15/2012 5:51 PM, Anthony Petrov wrote:
>> (also cc'ing i18n-dev@)
>>
>> Approved, provided the code compiles and works as expected in the 7u
>> release.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 11/15/12 12:43, Anton Litvinov wrote:
>>> Hello,
>>>
>>> Please review the following fix for a bug. It is a backport of the fix
>>> which is already reviewed and committed into JDK 8 repository. This fix
>>> is identical to the fix for JDK 8.
>>>
>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6789984
>>> Webrev: http://cr.openjdk.java.net/~alitvinov/6789984/webrev.02
>>> JDK 8 changeset:
>>> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f32a0aee7bb9
>>>
>>> Thank you,
>>> Anton


From Alan.Bateman at oracle.com  Wed Nov 21 09:45:06 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 21 Nov 2012 17:45:06 +0000
Subject: <i18n dev> Do developers or end-users create
	currency.properties?
In-Reply-To: <507D904B.4020103@oracle.com>
References: <507C3445.2060208@oracle.com> <507D5B82.7060902@oracle.com>
	<507D904B.4020103@oracle.com>
Message-ID: <50AD1322.8080004@oracle.com>

On 16/10/2012 17:50, Naoto Sato wrote:
> The idea was that "currency.properties" was intended for the 
> "emergency" situation, where JRE's update could not keep up with 
> customers' needs. The assumption was JRE's lib/currency.data should 
> contain the latest currency data with the JRE updates.
>
> Naoto
If there is a need for an override mechanism then the simplest might be 
to just support a system property that allows a properties file to 
specified with the overridden currency data. This seems preferable to 
copying it into the ${java.home}/lib directory. If you agree then the 
question becomes whether this should be part of the specification or 
something that is JDK specific. I've put a first version here and 
perhaps we can discuss this with a view to coming up with a solution:

http://cr.openjdk.java.net/~alanb/8003846/webrev/

It basically just allows java.util.data.currency to be set to the 
location of a currency properties file. If not defined then it will look 
in ${java.home}/lib as before so we get compatibility with jdk7.

-Alan.

From naoto.sato at oracle.com  Wed Nov 21 12:32:37 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 21 Nov 2012 12:32:37 -0800
Subject: <i18n dev> Do developers or end-users create
	currency.properties?
In-Reply-To: <50AD1322.8080004@oracle.com>
References: <507C3445.2060208@oracle.com> <507D5B82.7060902@oracle.com>
	<507D904B.4020103@oracle.com> <50AD1322.8080004@oracle.com>
Message-ID: <50AD3A65.9010307@oracle.com>

Hi Alan,

I think it's a good idea to provide a way to specify the currency 
properties file location. As to whether it belongs to spec or not, I 
think we need make it as part of spec, otherwise it may not conform to 
the existing spec, i.e., lib/currency.properties will not be read if 
this new mechanism is invoked.

Naoto

On 11/21/12 9:45 AM, Alan Bateman wrote:
> On 16/10/2012 17:50, Naoto Sato wrote:
>> The idea was that "currency.properties" was intended for the
>> "emergency" situation, where JRE's update could not keep up with
>> customers' needs. The assumption was JRE's lib/currency.data should
>> contain the latest currency data with the JRE updates.
>>
>> Naoto
> If there is a need for an override mechanism then the simplest might be
> to just support a system property that allows a properties file to
> specified with the overridden currency data. This seems preferable to
> copying it into the ${java.home}/lib directory. If you agree then the
> question becomes whether this should be part of the specification or
> something that is JDK specific. I've put a first version here and
> perhaps we can discuss this with a view to coming up with a solution:
>
> http://cr.openjdk.java.net/~alanb/8003846/webrev/
>
> It basically just allows java.util.data.currency to be set to the
> location of a currency properties file. If not defined then it will look
> in ${java.home}/lib as before so we get compatibility with jdk7.
>
> -Alan.


From Alan.Bateman at oracle.com  Wed Nov 21 12:49:21 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 21 Nov 2012 20:49:21 +0000
Subject: <i18n dev> Do developers or end-users create
	currency.properties?
In-Reply-To: <50AD3A65.9010307@oracle.com>
References: <507C3445.2060208@oracle.com> <507D5B82.7060902@oracle.com>
	<507D904B.4020103@oracle.com> <50AD1322.8080004@oracle.com>
	<50AD3A65.9010307@oracle.com>
Message-ID: <50AD3E51.4020907@oracle.com>

On 21/11/2012 20:32, Naoto Sato wrote:
> Hi Alan,
>
> I think it's a good idea to provide a way to specify the currency 
> properties file location. As to whether it belongs to spec or not, I 
> think we need make it as part of spec, otherwise it may not conform to 
> the existing spec, i.e., lib/currency.properties will not be read if 
> this new mechanism is invoked.
If you have a preference to have keep it in the spec then I can leave it 
there. All it means that every implementation would need to support this 
property and this format, if it were JDK specific then it would need to 
be documented somewhere else although it could be the same format as 
what we have now and it would need to continue to support 
lib/currency.properties for compatibility reasons.

So do you agree with the proposed property name and the minor tweak to 
the spec?

-Alan

From naoto.sato at oracle.com  Wed Nov 21 12:52:17 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 21 Nov 2012 12:52:17 -0800
Subject: <i18n dev> Do developers or end-users create
	currency.properties?
In-Reply-To: <50AD3E51.4020907@oracle.com>
References: <507C3445.2060208@oracle.com> <507D5B82.7060902@oracle.com>
	<507D904B.4020103@oracle.com> <50AD1322.8080004@oracle.com>
	<50AD3A65.9010307@oracle.com> <50AD3E51.4020907@oracle.com>
Message-ID: <50AD3F01.9070708@oracle.com>

On 11/21/12 12:49 PM, Alan Bateman wrote:
> So do you agree with the proposed property name and the minor tweak to
> the spec?

Yep.

Naoto


From Alan.Bateman at oracle.com  Tue Nov 27 02:48:00 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 27 Nov 2012 10:48:00 +0000
Subject: <i18n dev> RFR (S): 7155168:
 java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo
In-Reply-To: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com>
References: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com>
Message-ID: <50B49A60.4010708@oracle.com>

On 27/11/2012 10:22, Staffan Larsen wrote:
> Please review this fix for the java/util/TimeZone/Bug6912560.java test.
>
> The problem with the test is that it fails when running with Java Flight Recorder enabled. This is because JFR will call TimeZone.getDefault() when it starts up, before the main() method is called. This will cause TimeZone to cache the value so that when the test calls TimeZone.getDefault() it will get the old value. The solution here is to reset the value in the beginning of the test.
>
> Webrev: http://cr.openjdk.java.net/~sla/7155168/webrev.00/test/java/util/TimeZone/Bug6912560.java.sdiff.html
>
> Thanks,
> /Staffan


From Alan.Bateman at oracle.com  Tue Nov 27 03:02:42 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 27 Nov 2012 11:02:42 +0000
Subject: <i18n dev> RFR (S): 7155168:
 java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo
In-Reply-To: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com>
References: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com>
Message-ID: <50B49DD2.9000509@oracle.com>

On 27/11/2012 10:22, Staffan Larsen wrote:
> Please review this fix for the java/util/TimeZone/Bug6912560.java test.
>
> The problem with the test is that it fails when running with Java Flight Recorder enabled. This is because JFR will call TimeZone.getDefault() when it starts up, before the main() method is called. This will cause TimeZone to cache the value so that when the test calls TimeZone.getDefault() it will get the old value. The solution here is to reset the value in the beginning of the test.
>
> Webrev: http://cr.openjdk.java.net/~sla/7155168/webrev.00/test/java/util/TimeZone/Bug6912560.java.sdiff.html
>
I suspect this test will fail with java agents too, say when doing code 
coverage during test runs.

It might be better to just change the @run tag to specify -D 
user.timezone= Asia/Tokyo, assuming this solves the problem too.

-Alan.

From Alan.Bateman at oracle.com  Tue Nov 27 05:57:16 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 27 Nov 2012 13:57:16 +0000
Subject: <i18n dev> RFR (S): 7155168:
 java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo
In-Reply-To: <4808282E-0F56-4BED-B805-F21A3673BECB@oracle.com>
References: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com>
	<50B49DD2.9000509@oracle.com>
	<4808282E-0F56-4BED-B805-F21A3673BECB@oracle.com>
Message-ID: <50B4C6BC.9000307@oracle.com>

On 27/11/2012 12:26, Staffan Larsen wrote:
> :
>
> The test installs a security manager and that has to be present during 
> the call to getDefault() when getDefault() does the real work (not 
> just reading from the cache). Setting -Duser.timezone will not help as 
> the only fix.
>
What I mean is change the @run line to this:

@run main/othervm -Djava.security.manager -Duser.timezone= Asia/Tokyo ...

I have not tried it to know if the "/" will cause a problem on Windows.

-Alan.

From sean.coffey at oracle.com  Tue Nov 27 08:02:28 2012
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Tue, 27 Nov 2012 16:02:28 +0000
Subject: <i18n dev> RFR (S): 7155168:
 java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo
In-Reply-To: <50B49DD2.9000509@oracle.com>
References: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com>
	<50B49DD2.9000509@oracle.com>
Message-ID: <50B4E414.3060500@oracle.com>

> I suspect this test will fail with java agents too, say when doing 
> code coverage during test runs.
>
> It might be better to just change the @run tag to specify -D 
> user.timezone= Asia/Tokyo, assuming this solves the problem too. 
This test runs in othervm mode by default. Any java agents calling into 
this would already have been causing an issue. Right ?
Is this outside the scope of the fix we need in 7155168 ?

regards,
Sean.

On 27/11/2012 11:02, Alan Bateman wrote:
> On 27/11/2012 10:22, Staffan Larsen wrote:
>> Please review this fix for the java/util/TimeZone/Bug6912560.java test.
>>
>> The problem with the test is that it fails when running with Java 
>> Flight Recorder enabled. This is because JFR will call 
>> TimeZone.getDefault() when it starts up, before the main() method is 
>> called. This will cause TimeZone to cache the value so that when the 
>> test calls TimeZone.getDefault() it will get the old value. The 
>> solution here is to reset the value in the beginning of the test.
>>
>> Webrev: 
>> http://cr.openjdk.java.net/~sla/7155168/webrev.00/test/java/util/TimeZone/Bug6912560.java.sdiff.html
>>
> I suspect this test will fail with java agents too, say when doing 
> code coverage during test runs.
>
> It might be better to just change the @run tag to specify -D 
> user.timezone= Asia/Tokyo, assuming this solves the problem too.
>
> -Alan.


From sean.coffey at oracle.com  Wed Nov 28 05:30:12 2012
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Wed, 28 Nov 2012 13:30:12 +0000
Subject: <i18n dev> RFR (S): 7155168:
 java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo
In-Reply-To: <202EF436-70AB-4E7E-939E-0A68B95668D5@oracle.com>
References: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com>
	<50B49DD2.9000509@oracle.com> <50B4E414.3060500@oracle.com>
	<202EF436-70AB-4E7E-939E-0A68B95668D5@oracle.com>
Message-ID: <50B611E4.6030009@oracle.com>

Staffan,

perhaps you can leave out the setting of security manager on the @run 
tags. Security manager can be added through the code as per current 
testcase.

@run main/othervm -Duser.timezone=Asia/Tokyo Bug6912560

should work ?

regards,
Sean.
> --- a/test/java/util/TimeZone/Bug6912560.java
> +++ b/test/java/util/TimeZone/Bug6912560.java
> @@ -26,7 +26,7 @@
>  /*
>   * @test
>   * @bug 6912560
> - * @run main/othervm Bug6912560
> + * @run main/othervm -Duser.timezone=Asia/Tokyo Bug6912560
>   * @summary Make sure that file path canonicalization in
>   * sun.util.calendar.ZoneInfoFile works with the default security
>   * manager.
> @@ -37,9 +37,8 @@ import java.util.*;
>
>  public class Bug6912560 {
>      public static void main(String[] args) {
> -        // set the user.timezone property
> +        // expected timezone
>          String tzname = "Asia/Tokyo";
> -        System.setProperty("user.timezone", tzname);
>
>          System.setSecurityManager(new SecurityManager());



On 28/11/2012 12:59, Staffan Larsen wrote:
> Did we conclude that my original change was good, or was there an alternative?
>
> Thanks,
> /Staffan
>
> On 27 nov 2012, at 17:02, Se?n Coffey <sean.coffey at oracle.com> wrote:
>
>>> I suspect this test will fail with java agents too, say when doing code coverage during test runs.
>>>
>>> It might be better to just change the @run tag to specify -D user.timezone= Asia/Tokyo, assuming this solves the problem too.
>> This test runs in othervm mode by default. Any java agents calling into this would already have been causing an issue. Right ?
>> Is this outside the scope of the fix we need in 7155168 ?
>>
>> regards,
>> Sean.
>>
>> On 27/11/2012 11:02, Alan Bateman wrote:
>>> On 27/11/2012 10:22, Staffan Larsen wrote:
>>>> Please review this fix for the java/util/TimeZone/Bug6912560.java test.
>>>>
>>>> The problem with the test is that it fails when running with Java Flight Recorder enabled. This is because JFR will call TimeZone.getDefault() when it starts up, before the main() method is called. This will cause TimeZone to cache the value so that when the test calls TimeZone.getDefault() it will get the old value. The solution here is to reset the value in the beginning of the test.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~sla/7155168/webrev.00/test/java/util/TimeZone/Bug6912560.java.sdiff.html
>>>>
>>> I suspect this test will fail with java agents too, say when doing code coverage during test runs.
>>>
>>> It might be better to just change the @run tag to specify -D user.timezone= Asia/Tokyo, assuming this solves the problem too.
>>>
>>> -Alan.


From masayoshi.okutsu at oracle.com  Wed Nov 28 06:41:56 2012
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 28 Nov 2012 23:41:56 +0900
Subject: <i18n dev> RFR (S): 7155168:
 java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo
In-Reply-To: <202EF436-70AB-4E7E-939E-0A68B95668D5@oracle.com>
References: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com>
	<50B49DD2.9000509@oracle.com> <50B4E414.3060500@oracle.com>
	<202EF436-70AB-4E7E-939E-0A68B95668D5@oracle.com>
Message-ID: <50B622B4.4030608@oracle.com>

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 original change was good, or was there an alternative?
>
> Thanks,
> /Staffan
>
> On 27 nov 2012, at 17:02, Se?n Coffey <sean.coffey at oracle.com> wrote:
>
>>> I suspect this test will fail with java agents too, say when doing code coverage during test runs.
>>>
>>> It might be better to just change the @run tag to specify -D user.timezone= Asia/Tokyo, assuming this solves the problem too.
>> This test runs in othervm mode by default. Any java agents calling into this would already have been causing an issue. Right ?
>> Is this outside the scope of the fix we need in 7155168 ?
>>
>> regards,
>> Sean.
>>
>> On 27/11/2012 11:02, Alan Bateman wrote:
>>> On 27/11/2012 10:22, Staffan Larsen wrote:
>>>> Please review this fix for the java/util/TimeZone/Bug6912560.java test.
>>>>
>>>> The problem with the test is that it fails when running with Java Flight Recorder enabled. This is because JFR will call TimeZone.getDefault() when it starts up, before the main() method is called. This will cause TimeZone to cache the value so that when the test calls TimeZone.getDefault() it will get the old value. The solution here is to reset the value in the beginning of the test.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~sla/7155168/webrev.00/test/java/util/TimeZone/Bug6912560.java.sdiff.html
>>>>
>>> I suspect this test will fail with java agents too, say when doing code coverage during test runs.
>>>
>>> It might be better to just change the @run tag to specify -D user.timezone= Asia/Tokyo, assuming this solves the problem too.
>>>
>>> -Alan.


From staffan.larsen at oracle.com  Tue Nov 27 04:26:17 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 27 Nov 2012 13:26:17 +0100
Subject: <i18n dev> RFR (S): 7155168:
	java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo
In-Reply-To: <50B49DD2.9000509@oracle.com>
References: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com>
	<50B49DD2.9000509@oracle.com>
Message-ID: <4808282E-0F56-4BED-B805-F21A3673BECB@oracle.com>


On 27 nov 2012, at 12:02, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 27/11/2012 10:22, Staffan Larsen wrote:
>> 
>> Please review this fix for the java/util/TimeZone/Bug6912560.java test.
>> 
>> The problem with the test is that it fails when running with Java Flight Recorder enabled. This is because JFR will call TimeZone.getDefault() when it starts up, before the main() method is called. This will cause TimeZone to cache the value so that when the test calls TimeZone.getDefault() it will get the old value. The solution here is to reset the value in the beginning of the test.
>> 
>> Webrev: http://cr.openjdk.java.net/~sla/7155168/webrev.00/test/java/util/TimeZone/Bug6912560.java.sdiff.html
>> 
> I suspect this test will fail with java agents too, say when doing code coverage during test runs.
> 
> It might be better to just change the @run tag to specify -D user.timezone= Asia/Tokyo, assuming this solves the problem too.

The test installs a security manager and that has to be present during the call to getDefault() when getDefault() does the real work (not just reading from the cache). Setting -Duser.timezone will not help as the only fix.

/Staffan

From staffan.larsen at oracle.com  Tue Nov 27 06:08:17 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 27 Nov 2012 15:08:17 +0100
Subject: <i18n dev> RFR (S): 7155168:
	java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo
In-Reply-To: <50B4C6BC.9000307@oracle.com>
References: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com>
	<50B49DD2.9000509@oracle.com>
	<4808282E-0F56-4BED-B805-F21A3673BECB@oracle.com>
	<50B4C6BC.9000307@oracle.com>
Message-ID: <BCD520CD-BE79-404C-A25C-E575F32FD121@oracle.com>

Setting -Djava.security.manager on the @run gives me an AccessControlException from jtreg. I could work around this by creating a policy file, I guess.

Exception in thread "main" java.security.AccessControlException: access denied ("java.io.FilePermission" "/Users/staffan/mercurial/jdk8-tl/jdk/JTwork/classes/java/util/TimeZone/Bug6912560.jta" "read")
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:364)
	at java.security.AccessController.checkPermission(AccessController.java:560)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
	at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
	at java.io.FileInputStream.<init>(FileInputStream.java:125)
	at java.io.FileInputStream.<init>(FileInputStream.java:91)
	at java.io.FileReader.<init>(FileReader.java:58)
	at com.sun.javatest.regtest.MainWrapper.main(MainWrapper.java:45)

On 27 nov 2012, at 14:57, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 27/11/2012 12:26, Staffan Larsen wrote:
>> 
>> :
>> 
>> The test installs a security manager and that has to be present during the call to getDefault() when getDefault() does the real work (not just reading from the cache). Setting -Duser.timezone will not help as the only fix.
>> 
> What I mean is change the @run line to this:
> 
> @run main/othervm -Djava.security.manager -Duser.timezone= Asia/Tokyo ...
> 
> I have not tried it to know if the "/" will cause a problem on Windows.
> 
> -Alan.


From staffan.larsen at oracle.com  Wed Nov 28 04:59:45 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 28 Nov 2012 13:59:45 +0100
Subject: <i18n dev> RFR (S): 7155168:
	java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo
In-Reply-To: <50B4E414.3060500@oracle.com>
References: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com>
	<50B49DD2.9000509@oracle.com> <50B4E414.3060500@oracle.com>
Message-ID: <202EF436-70AB-4E7E-939E-0A68B95668D5@oracle.com>

Did we conclude that my original change was good, or was there an alternative?

Thanks,
/Staffan

On 27 nov 2012, at 17:02, Se?n Coffey <sean.coffey at oracle.com> wrote:

>> I suspect this test will fail with java agents too, say when doing code coverage during test runs.
>> 
>> It might be better to just change the @run tag to specify -D user.timezone= Asia/Tokyo, assuming this solves the problem too. 
> This test runs in othervm mode by default. Any java agents calling into this would already have been causing an issue. Right ?
> Is this outside the scope of the fix we need in 7155168 ?
> 
> regards,
> Sean.
> 
> On 27/11/2012 11:02, Alan Bateman wrote:
>> On 27/11/2012 10:22, Staffan Larsen wrote:
>>> Please review this fix for the java/util/TimeZone/Bug6912560.java test.
>>> 
>>> The problem with the test is that it fails when running with Java Flight Recorder enabled. This is because JFR will call TimeZone.getDefault() when it starts up, before the main() method is called. This will cause TimeZone to cache the value so that when the test calls TimeZone.getDefault() it will get the old value. The solution here is to reset the value in the beginning of the test.
>>> 
>>> Webrev: http://cr.openjdk.java.net/~sla/7155168/webrev.00/test/java/util/TimeZone/Bug6912560.java.sdiff.html
>>> 
>> I suspect this test will fail with java agents too, say when doing code coverage during test runs.
>> 
>> It might be better to just change the @run tag to specify -D user.timezone= Asia/Tokyo, assuming this solves the problem too.
>> 
>> -Alan.
> 


From staffan.larsen at oracle.com  Wed Nov 28 06:26:03 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 28 Nov 2012 15:26:03 +0100
Subject: <i18n dev> RFR (S): 7155168:
	java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo
In-Reply-To: <50B611E4.6030009@oracle.com>
References: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com>
	<50B49DD2.9000509@oracle.com> <50B4E414.3060500@oracle.com>
	<202EF436-70AB-4E7E-939E-0A68B95668D5@oracle.com>
	<50B611E4.6030009@oracle.com>
Message-ID: <102AD127-510E-44B4-94A3-E2A6F52A93C3@oracle.com>


On 28 nov 2012, at 14:30, Se?n Coffey <sean.coffey at oracle.com> wrote:

> Staffan,
> 
> perhaps you can leave out the setting of security manager on the @run tags. Security manager can be added through the code as per current testcase.
> 
> @run main/othervm -Duser.timezone=Asia/Tokyo Bug6912560
> 
> should work ?

This only works if I also add the TimeZone.setDefault(null); call from my webrev. The reason is that the security manager needs to be active when TimeZone.getDefault() is called without the timezone being cached. Since the first call to getDefault() will not have a security manager set, I have to reset the cached copy.

/Staffan

> 
> regards,
> Sean.
>> --- a/test/java/util/TimeZone/Bug6912560.java
>> +++ b/test/java/util/TimeZone/Bug6912560.java
>> @@ -26,7 +26,7 @@
>> /*
>>  * @test
>>  * @bug 6912560
>> - * @run main/othervm Bug6912560
>> + * @run main/othervm -Duser.timezone=Asia/Tokyo Bug6912560
>>  * @summary Make sure that file path canonicalization in
>>  * sun.util.calendar.ZoneInfoFile works with the default security
>>  * manager.
>> @@ -37,9 +37,8 @@ import java.util.*;
>> 
>> public class Bug6912560 {
>>     public static void main(String[] args) {
>> -        // set the user.timezone property
>> +        // expected timezone
>>         String tzname = "Asia/Tokyo";
>> -        System.setProperty("user.timezone", tzname);
>> 
>>         System.setSecurityManager(new SecurityManager());
> 
> 
> 
> On 28/11/2012 12:59, Staffan Larsen wrote:
>> Did we conclude that my original change was good, or was there an alternative?
>> 
>> Thanks,
>> /Staffan
>> 
>> On 27 nov 2012, at 17:02, Se?n Coffey <sean.coffey at oracle.com> wrote:
>> 
>>>> I suspect this test will fail with java agents too, say when doing code coverage during test runs.
>>>> 
>>>> It might be better to just change the @run tag to specify -D user.timezone= Asia/Tokyo, assuming this solves the problem too.
>>> This test runs in othervm mode by default. Any java agents calling into this would already have been causing an issue. Right ?
>>> Is this outside the scope of the fix we need in 7155168 ?
>>> 
>>> regards,
>>> Sean.
>>> 
>>> On 27/11/2012 11:02, Alan Bateman wrote:
>>>> On 27/11/2012 10:22, Staffan Larsen wrote:
>>>>> Please review this fix for the java/util/TimeZone/Bug6912560.java test.
>>>>> 
>>>>> The problem with the test is that it fails when running with Java Flight Recorder enabled. This is because JFR will call TimeZone.getDefault() when it starts up, before the main() method is called. This will cause TimeZone to cache the value so that when the test calls TimeZone.getDefault() it will get the old value. The solution here is to reset the value in the beginning of the test.
>>>>> 
>>>>> Webrev: http://cr.openjdk.java.net/~sla/7155168/webrev.00/test/java/util/TimeZone/Bug6912560.java.sdiff.html
>>>>> 
>>>> I suspect this test will fail with java agents too, say when doing code coverage during test runs.
>>>> 
>>>> It might be better to just change the @run tag to specify -D user.timezone= Asia/Tokyo, assuming this solves the problem too.
>>>> 
>>>> -Alan.
> 


From staffan.larsen at oracle.com  Wed Nov 28 08:23:53 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 28 Nov 2012 17:23:53 +0100
Subject: <i18n dev> RFR (S): 7155168:
	java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo
In-Reply-To: <50B622B4.4030608@oracle.com>
References: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com>
	<50B49DD2.9000509@oracle.com> <50B4E414.3060500@oracle.com>
	<202EF436-70AB-4E7E-939E-0A68B95668D5@oracle.com>
	<50B622B4.4030608@oracle.com>
Message-ID: <6B76C7D7-4B79-4D9D-AB97-6A81C61CBF87@oracle.com>


On 28 nov 2012, at 15:41, Masayoshi Okutsu <masayoshi.okutsu at oracle.com> wrote:

> 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.

Calling TimeZone.setDefault(null) from JFR turned out to be hard since TimeZone.getDefault() is called from so many places and often indirectly (for example "new Date()"). This made it very hard to make sure it got reset correctly.

Thus, I'd like to change the test program instead.

/Staffan

> 
> Thanks,
> Masayoshi
> 
> On 2012/11/28 21:59, Staffan Larsen wrote:
>> Did we conclude that my original change was good, or was there an alternative?
>> 
>> Thanks,
>> /Staffan
>> 
>> On 27 nov 2012, at 17:02, Se?n Coffey <sean.coffey at oracle.com> wrote:
>> 
>>>> I suspect this test will fail with java agents too, say when doing code coverage during test runs.
>>>> 
>>>> It might be better to just change the @run tag to specify -D user.timezone= Asia/Tokyo, assuming this solves the problem too.
>>> This test runs in othervm mode by default. Any java agents calling into this would already have been causing an issue. Right ?
>>> Is this outside the scope of the fix we need in 7155168 ?
>>> 
>>> regards,
>>> Sean.
>>> 
>>> On 27/11/2012 11:02, Alan Bateman wrote:
>>>> On 27/11/2012 10:22, Staffan Larsen wrote:
>>>>> Please review this fix for the java/util/TimeZone/Bug6912560.java test.
>>>>> 
>>>>> The problem with the test is that it fails when running with Java Flight Recorder enabled. This is because JFR will call TimeZone.getDefault() when it starts up, before the main() method is called. This will cause TimeZone to cache the value so that when the test calls TimeZone.getDefault() it will get the old value. The solution here is to reset the value in the beginning of the test.
>>>>> 
>>>>> Webrev: http://cr.openjdk.java.net/~sla/7155168/webrev.00/test/java/util/TimeZone/Bug6912560.java.sdiff.html
>>>>> 
>>>> I suspect this test will fail with java agents too, say when doing code coverage during test runs.
>>>> 
>>>> It might be better to just change the @run tag to specify -D user.timezone= Asia/Tokyo, assuming this solves the problem too.
>>>> 
>>>> -Alan.
>