I am pushing this changeset but backing out the changes to
ProblemList.txt. Those tests
are still failing depending on the machine and user permissions. I have
a fair idea what is going wrong with them, and will
work on them with their associated CR (7150557).
Thanks,
Kurchi
On 7/12/2012 7:55
I used a new workspace and missed adding it to mercurial. The test
remains the same,
I'll push it after adding the test.
- Kurchi
On 7/12/12 12:16 AM, Alan Bateman wrote:
On 12/07/2012 00:45, Kurchi Hazra wrote:
On 7/11/12 4:24 PM, Chris Hegarty wrote:
On 12 Jul 2012, at 00:15, Kurchi
Hazra
On 12/07/2012 00:45, Kurchi Hazra wrote:
On 7/11/12 4:24 PM, Chris Hegarty wrote:
On 12 Jul 2012, at 00:15, Kurchi
Hazra wrote:
Thanks for the review Alan. Updated webrev:
http://cr.openjdk.java.net/~khazra/7160252/webrev.01/
Looks fine.
Trivially, is there an opportunity to make any field
Thanks Kurchi, looks fine.
-Chris
Kurchi Hazra wrote:
>On 7/11/12 4:24 PM, Chris Hegarty wrote:
>> On 12 Jul 2012, at 00:15, Kurchi Hazra
>> wrote:
>>
>>> Thanks for the review Alan. Updated webrev:
>>> http://cr.openjdk.java.net/~khazra/7160252/webrev.01/
>> Looks fine.
>>
>> Trivially, is t
On 7/11/12 4:24 PM, Chris Hegarty wrote:
On 12 Jul 2012, at 00:15, Kurchi Hazra wrote:
Thanks for the review Alan. Updated webrev:
http://cr.openjdk.java.net/~khazra/7160252/webrev.01/
Looks fine.
Trivially, is there an opportunity to make any fields final since initFields is
replaced with
On 12 Jul 2012, at 00:15, Kurchi Hazra wrote:
> Thanks for the review Alan. Updated webrev:
> http://cr.openjdk.java.net/~khazra/7160252/webrev.01/
Looks fine.
Trivially, is there an opportunity to make any fields final since initFields is
replaced with a constructor?
-Chris.
>
> - Kurchi
Thanks for the review Alan. Updated webrev:
http://cr.openjdk.java.net/~khazra/7160252/webrev.01/
- Kurchi
On 7/11/12 5:45 AM, Alan Bateman wrote:
On 26/06/2012 22:57, Kurchi Hazra wrote:
Hi,
On Mac OS X, for Preferences, a new child added event was not being
delivered to a NodeChangeLis
On 26/06/2012 22:57, Kurchi Hazra wrote:
Hi,
On Mac OS X, for Preferences, a new child added event was not being
delivered to a NodeChangeListener since the existing code depended on the
return value of addNode() in the native code, which returns true if a new
node is added. However, since
Hi,
On Mac OS X, for Preferences, a new child added event was not being
delivered to a NodeChangeListener since the existing code depended on the
return value of addNode() in the native code, which returns true if a new
node is added. However, since addNode() was being called erroneously aft
