Re: Review request: JDK-8020191 System.getProperty( " os.name " ) returns " Windows NT (unknown) " on Windows 8.1

[Kurchi Subhra Hazra]

Changes look good to me (once Alan's point is verified).

Thanks,

- Kurchi


On Wed, Jul 31, 2013 at 7:15 AM, Alan Bateman wrote:

>
> The changes in the webrev look okay to me but the reference to the "app
> compatibility shim" in the MS article is a bit confusing and not clear to
> me (with checking into it more) whether this might consider java.exe as
> something that isn't targeted to Windows 8.1. So can you verify that you
> have checked it on the latest 8.1 preview?
>
> As regards the helper library then this could be useful in the future (for
> now then it probably complicates things because the JDK still has to run on
> older versions of Windows).
>
> -Alan.
>
>
>
> On 31/07/2013 05:53, Alexey Utkin wrote:
>
>> Bug description:
>> 
>> https://jbs.oracle.com/bugs/**browse/JDK-8020191
>> 
>> http://bugs.sun.com/view_bug.**do?bug_id=8020191
>>
>> Here is the suggested fix:
>> http://cr.openjdk.java.net/~**uta/openjdk-webrevs/JDK-**
>> 8020191/webrev.00/
>>
>> Summary:
>> We need to be consistent with the rest of OS, so I extend the case for
>> 6.3 internal version number by values "Windows 8.1" for workstation OS, and
>> "Windows Server 2012 R2" for server OS.
>> (http://msdn.microsoft.com/en-**us/library/windows/desktop/**
>> dn302074.aspx
>> )
>>
>> But we get a chance to have a wrong OS name due to MS compatibility
>> problems.
>>
>> Here is the problem description:
>>
>> http://social.msdn.microsoft.**com/forums/windowsazure/zh-tw/**
>> c471de52-611f-435d-ab44-**56064e5fd7d5/windows-81-**
>> preview-getversionex-reports-**629200
>>
>> and MS respond:
>> http://msdn.microsoft.com/en-**us/library/windows/desktop/**
>> dn302074.aspx
>>
>> Quotations:
>> "In Windows 8.1 Preview, we have introduced a new API, Versionhelpers
>> API, that deprecates the need for using GetVersion(Ex) APIs. This addresses
>> difficulties in interpreting the numerical value returned by the
>> GetVersion(Ex) APIs."
>>
>> "The internal version number for Windows 8.1 Preview and Windows Server
>> 2012 R2 Preview is 6.3. Only apps that are targeting Windows 8.1 will
>> receive a return value of 6.3. Those apps that are not targeted for Windows
>> 8.1 will receive a return value of 6.2 unless previously shimmed as
>> discussed below."
>>
>>
>> Regards,
>> -uta
>>
>
>

hg: jdk8/tl/jdk: 7025238: HttpURLConnection does not handle URLs with an empty path component.

[kurchi . subhra . hazra]

Changeset: 2b156531b7eb
Author:arieber
Date:  2013-06-19 17:41 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2b156531b7eb

7025238: HttpURLConnection does not handle URLs with an empty path component.
Summary: Prepend a '/' to file when path is empty
Reviewed-by: chegar, khazra

! src/share/classes/sun/net/www/http/HttpClient.java
+ test/sun/net/www/http/HttpClient/B7025238.java

hg: jdk8/tl/jdk: 8016698: Cleanup overrides warning in sun/tools/ClassDeclaration.java

[kurchi . subhra . hazra]

Changeset: e1b18a666f76
Author:khazra
Date:  2013-06-19 14:13 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e1b18a666f76

8016698: Cleanup overrides warning in sun/tools/ClassDeclaration.java
Summary: Override Object.hashCode()
Reviewed-by: alanb, chegar

! src/share/classes/sun/tools/java/ClassDeclaration.java

hg: jdk8/tl/jdk: 8016576: Overrides warnings in jdi and jconsole

[kurchi . subhra . hazra]

Changeset: de6b93fd6d23
Author:khazra
Date:  2013-06-19 14:02 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/de6b93fd6d23

8016576: Overrides warnings in jdi and jconsole
Summary: Implement hashCode() in classes emitting warnings
Reviewed-by: alanb, chegar

! src/share/classes/com/sun/tools/jdi/SDE.java
! src/share/classes/sun/tools/jconsole/inspector/XObject.java

hg: jdk8/tl/jdk: 7169142: CookieHandler does not work with localhost

[kurchi . subhra . hazra]

Changeset: 42f9ad39bf42
Author:khazra
Date:  2013-06-13 17:48 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/42f9ad39bf42

7169142: CookieHandler does not work with localhost
Summary: Add .local to derived effective hostnames without dot
Reviewed-by: chegar

! src/share/classes/java/net/CookieManager.java
+ test/java/net/CookieHandler/LocalHostCookie.java

hg: jdk8/tl/jdk: 8015421: NegativeArraySizeException occurs in ChunkedOutputStream() with Integer.MAX_VALUE

[kurchi . subhra . hazra]

Changeset: ff83bd43e36a
Author:khazra
Date:  2013-06-13 11:23 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff83bd43e36a

8015421: NegativeArraySizeException occurs in ChunkedOutputStream() with 
Integer.MAX_VALUE
Summary: Ensure integer overflow does not occur
Reviewed-by: chegar

! src/share/classes/sun/net/www/http/ChunkedOutputStream.java

hg: jdk8/tl/jdk: 7051862: CookiePolicy spec conflicts with CookiePolicy.ACCEPT_ORIGINAL_SERVER

[kurchi . subhra . hazra]

Changeset: 8b65dfe8f509
Author:khazra
Date:  2013-06-07 10:59 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8b65dfe8f509

7051862: CookiePolicy spec conflicts with CookiePolicy.ACCEPT_ORIGINAL_SERVER
Summary: Return false for null arguments in 
ACCEPT_ORIGINAL_SERVER#shouldAccept()
Reviewed-by: chegar

! src/share/classes/java/net/CookiePolicy.java
! test/java/net/CookieHandler/CookieManagerTest.java

hg: jdk8/tl/jdk: 2 new changesets

[kurchi . subhra . hazra]

Changeset: 11cdcf87ad5d
Author:jzavgren
Date:  2013-05-31 15:23 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11cdcf87ad5d

8008972: Memory leak: Java_java_net_TwoStacksPlainDatagramSocketImpl_receive0 
[parfait]
Summary: Modified the code so that "jumbo frames" are truncated before buffer 
allocation is considered. This makes the buffer length a reliable indication 
that a buffer has been allocated, and it can then be used during clean up.
Reviewed-by: chegar, khazra, alanb
Contributed-by: john.zavg...@oracle.com

! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c
! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c

Changeset: f6e6c27c19f3
Author:jzavgren
Date:  2013-05-31 15:18 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f6e6c27c19f3

7188517: Check on '$' character is missing in the HttpCookie class constructor
Summary: Modified the constructor code so that the cookie names are examined 
for leading dollar signs and if they do, an illegal argument exception is 
thrown.
Reviewed-by: chegar, khazra, michaelm
Contributed-by: john.zavg...@oracle.com

! src/share/classes/java/net/HttpCookie.java
! test/java/net/CookieHandler/TestHttpCookie.java

Re: Code Review Request: 7186555: (prefs) continual printing of BackingStoreException on console on Linux

[Kurchi Subhra Hazra]

On 5/21/13 9:53 AM, Kurchi Subhra Hazra wrote:

On 5/21/13 9:40 AM, Mike Duigou wrote:
Any chance that it would be possible to stop the periodic attempts to 
sync preferences?


- I did think of that too - but the syncing may fail(temporarily) if 
the prefs object could not retrieve the lock to the
associated prefs file. We could stop syncing attempts if the sync 
fails say n number of times - but I do not think

that is a good solution.
- Just to add, why I don't think the above is a good solution, one might 
be trying to acquire lock on a remote file
over NFS, and the syncing may fail temporarily because of an erratic 
network connection.


 We may however be able to stop the syncing attempts if we are 
guaranteed by some error code that any future

writing attempts will fail. I'll check on that.

- Kurchi



The log spamming is a symptom, not the cause.

Could the prefs code be enhanced to better determine if writing is 
possible before attempting and failing?


Mike

On May 21 2013, at 01:21 , Mandy Chung wrote:


On 5/21/2013 1:42 AM, Kurchi Hazra wrote:

Hi,

   Please review this change to fix 718655. The bug complaints 
about continuous BackingStoreExceptions
printed on the console, the user is just seeing logged warnings 
from BackingStoreExceptions raised in periodic attempts to sync 
preferences. Preferences use sun.util.logging.PlatformLogger.java 
which is enabled by default, and has a default level of INFO. 
Changing the logging in this file to FINE prevents the user from 
seeing information that he/she is not interested in.

   Bug: http://bugs.sun.com/view_bug.do?bug_id=7186555
Webrev:http://cr.openjdk.java.net/~khazra/7186555/webrev.00/

Looks good and L116 emits a INFO log message that should be changed 
to FINE too.


Mandy

Re: Code Review Request: 7186555: (prefs) continual printing of BackingStoreException on console on Linux

[Kurchi Subhra Hazra]

On 5/21/13 9:40 AM, Mike Duigou wrote:

Any chance that it would be possible to stop the periodic attempts to sync 
preferences?


- I did think of that too - but the syncing may fail(temporarily) if the 
prefs object could not retrieve the lock to the
associated prefs file. We could stop syncing attempts if the sync fails 
say n number of times - but I do not think

that is a good solution.
 We may however be able to stop the syncing attempts if we are 
guaranteed by some error code that any future

writing attempts will fail. I'll check on that.

- Kurchi



The log spamming is a symptom, not the cause.

Could the prefs code be enhanced to better determine if writing is possible 
before attempting and failing?

Mike

On May 21 2013, at 01:21 , Mandy Chung wrote:


On 5/21/2013 1:42 AM, Kurchi Hazra wrote:

Hi,

   Please review this change to fix 718655. The bug complaints about continuous 
BackingStoreExceptions
printed on the console, the user is just seeing logged warnings from 
BackingStoreExceptions raised in periodic attempts to sync preferences. 
Preferences use sun.util.logging.PlatformLogger.java which is enabled by 
default, and has a default level of INFO. Changing the logging in this file to 
FINE prevents the user from seeing information that he/she is not interested in.
   Bug: http://bugs.sun.com/view_bug.do?bug_id=7186555
Webrev:http://cr.openjdk.java.net/~khazra/7186555/webrev.00/


Looks good and L116 emits a INFO log message that should be changed to FINE too.

Mandy

Re: Code Review Request: 7186555: (prefs) continual printing of BackingStoreException on console on Linux

[Kurchi Subhra Hazra]

On 5/21/13 1:35 AM, Mandy Chung wrote:

Kurchi,

The windows implementation also emits warning messages that should be 
fixed up too since we don't want to emit anything to interfere the 
application logging.  The default logging configuration (default level 
is INFO) should apply to the application logging and the runtime like 
this case should have a different default level (e.g SEVERE) so that 
our implementation can use the appropriate level rather than forcing 
to use FINE etc.  This is something for future enhancement (I'll file 
a RFE).


For this bug, have you considered setting the level to SEVERE and 
change its default instead of changing to FINE?


Thanks for the review. That did occur to me, but I was not sure which 
one is preferable. I will do the relevant changes and get back

with another webrev.

- Kurchi



Mandy

On 5/21/2013 9:21 AM, Mandy Chung wrote:

On 5/21/2013 1:42 AM, Kurchi Hazra wrote:


Hi,

   Please review this change to fix 718655. The bug complaints about 
continuous BackingStoreExceptions
printed on the console, the user is just seeing logged warnings from 
BackingStoreExceptions raised in periodic attempts to sync 
preferences. Preferences use sun.util.logging.PlatformLogger.java 
which is enabled by default, and has a default level of INFO. 
Changing the logging in this file to FINE prevents the user from 
seeing information that he/she is not interested in.

   Bug: http://bugs.sun.com/view_bug.do?bug_id=7186555
Webrev:http://cr.openjdk.java.net/~khazra/7186555/webrev.00/



Looks good and L116 emits a INFO log message that should be changed 
to FINE too.


Mandy

hg: jdk8/tl/jdk: 7150552: network test hangs [macosx]

[kurchi . subhra . hazra]

Changeset: a8be9405bb4b
Author:khazra
Date:  2013-05-16 10:58 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a8be9405bb4b

7150552: network test hangs [macosx]
Summary: Remove usage of test/sun/net/www/httptest
Reviewed-by: chegar

! test/ProblemList.txt
! test/java/net/CookieHandler/CookieManagerTest.java
! test/sun/net/www/protocol/http/B6299712.java

hg: jdk8/tl/jdk: 6328537: Improve javadocs for Socket class by adding references to SocketOptions

[kurchi . subhra . hazra]

Changeset: 790d292ee761
Author:khazra
Date:  2013-05-14 12:01 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/790d292ee761

6328537: Improve javadocs for Socket class by adding references to SocketOptions
Summary: Insert references to SocketOptions.java where applicable
Reviewed-by: alanb, chegar

! src/share/classes/java/net/ServerSocket.java
! src/share/classes/java/net/Socket.java

hg: jdk8/tl/jdk: 8014254: Selector in HttpServer introduces a 1000 ms delay when using KeepAlive

[kurchi . subhra . hazra]

Changeset: 86c1e8c799f5
Author:khazra
Date:  2013-05-13 13:48 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86c1e8c799f5

8014254: Selector in HttpServer introduces a 1000 ms delay when using KeepAlive
Summary: Rearrange event-handling code to remove bottle-neck. Also reviewed by 
mh...@mhcomputing.net.
Reviewed-by: chegar, alanb

! src/share/classes/sun/net/httpserver/ServerImpl.java

hg: jdk8/tl/jdk: 8013140: Heap corruption with NetworkInterface.getByInetAddress() and long i/f name

[kurchi . subhra . hazra]

Changeset: 3062bf908281
Author:khazra
Date:  2013-05-02 14:26 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3062bf908281

8013140: Heap corruption with NetworkInterface.getByInetAddress() and long i/f 
name
Summary: Remove buffer overruns in native code
Reviewed-by: alanb, chegar

! src/solaris/native/java/net/NetworkInterface.c

Fwd: Latency in starting threads on Mac OS X

[Kurchi Subhra Hazra]

Forwarding to core-libs.

- Kurchi

 Original Message 
Subject:Latency in starting threads on Mac OS X
Date:   Tue, 16 Apr 2013 15:57:06 +0300
From:   Dr Heinz M. Kabutz 
Organization:   JavaSpecialists.eu
To: macosx-port-...@openjdk.java.net



Good day my fellow Mac OS X users!

Yesterday, whilst teaching my Concurrency Specialist Course, I wanted to
demonstrate to my class how slow it was starting threads and how much
better it is to use a FixedThreadPool.  The question that I wanted to
answer was: How many microseconds does it take on average to start a
simple thread and what is the maximum time it could take?

We all know that it can take in the milliseconds range to do the following:

Thread t = new Thread(); // even without it actually doing anything
t.start();

This is one of the reasons why the fixed thread pool only starts the
threads as we submit jobs to it, since the up-front cost might not be
worth the wait.

But how long do you think the *maximum* was that I had to wait for
t.start() to return?  100ms?  200ms?

Actually, the longest I had to wait turned out to be about 250 seconds.
Yes.  That is *seconds*, not *milliseconds*.  Just to start a single thread.

This is most certainly a bug in the OpenJDK on Mac OS X.  We did not see
this behaviour on Linux nor on Windows 7.

The bug started in OpenJDK 1.7.0_06.  Prior to that it hardly ever took
longer than 30ms to start a single thread.

java version "1.7.0_05"
heinz$ java ThreadLeakMac2
time = 1, threads = 4
time = 2, threads = 346
time = 4, threads = 7378
time = 7, threads = 9614
time = 12, threads = 10027
time = 14, threads = 10063
time = 17, threads = 26965
time = 38, threads = 27013
time = 39, threads = 452053

java version "1.7.0_06"
heinz$ java ThreadLeakMac2
time = 1, threads = 6
time = 2, threads = 256
time = 6, threads = 373
*snip*
time = 111, threads = 42592
time = 200, threads = 49419
time = 333, threads = 58976
*snip*
time = 3245, threads = 202336
time = 3706, threads = 203702
*snip*
time = 5835, threads = 267872
time = 6455, threads = 269238
time = 9170, threads = 270603

In my code, I make sure that the thread has stopped before creating the
next one by calling join().

public class ThreadLeakMac2 {
   public static void main(String[] args) throws InterruptedException {
   long threads = 0;
   long max = 0;
   while(true) {
   long time = System.currentTimeMillis();
   Thread thread = new Thread();
   thread.start(); // should finish almost immediately
   time = System.currentTimeMillis() - time;
   thread.join(); // short delay, hopefully
   threads++;
   if (time>  max) {
   max = time;
   System.out.println("time = " + time +
  ", threads = " + threads);
   }
   }
   }
}

This would be another nice test case for Alexey's concurrency stress
test harness.

(I also posted this to the concurrency-interest list.)

Regards

Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Sun Java Champion
IEEE Certified Software Development Professional
http://www.javaspecialists.eu
Tel: +30 69 75 595 262
Skype: kabutz

hg: jdk8/tl/jdk: 5001942: Missings SOCKS support for direct connections

[kurchi . subhra . hazra]

Changeset: b702977e7212
Author:khazra
Date:  2013-04-05 12:12 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b702977e7212

5001942: Missings SOCKS support for direct connections
Summary: Add support for socksNonProxyHosts
Reviewed-by: chegar, khazra
Contributed-by: Christos Zoulas 

! src/share/classes/sun/net/spi/DefaultProxySelector.java
! test/java/net/Socks/SocksProxyVersion.java

hg: jdk8/tl/jdk: 7017962: Obsolete link is used in URL class level spec

[kurchi . subhra . hazra]

Changeset: 77bde15bc6a9
Author:khazra
Date:  2013-01-25 11:52 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77bde15bc6a9

7017962: Obsolete link is used in URL class level spec
Summary: Change the link to an archived document
Reviewed-by: chegar, mduigou

! src/share/classes/java/net/URL.java

hg: jdk8/tl/jdk: 7171415: java.net.URI.equals/hashCode not consistent for some URIs

[kurchi . subhra . hazra]

Changeset: e8414d69692c
Author:khazra
Date:  2013-01-17 14:50 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8414d69692c

7171415: java.net.URI.equals/hashCode not consistent for some URIs
Summary: Rewrite URI.hashCode() to consider encoded characters, also reviewed 
by vita...@gmail.com, schlo...@gmail.com
Reviewed-by: chegar

! src/share/classes/java/net/URI.java
! test/java/net/URI/Test.java

hg: jdk8/tl/jdk: 7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or by "couldn't get file lock"

[kurchi . subhra . hazra]

Changeset: 43d2e02c4098
Author:khazra
Date:  2012-11-30 12:00 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43d2e02c4098

7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or 
by "couldn't get file lock"
Summary: Set -Djava.util.prefs.userRoot to current working directory of user in 
the prefs tests
Reviewed-by: alanb, chegar, weijun, dxu

! test/java/util/prefs/AddNodeChangeListener.java
! test/java/util/prefs/CheckUserPrefsStorage.sh
! test/java/util/prefs/CommentsInXml.java
! test/java/util/prefs/ConflictInFlush.java
! test/java/util/prefs/ExportNode.java
! test/java/util/prefs/ExportSubtree.java
! test/java/util/prefs/PrefsSpi.sh
! test/java/util/prefs/RemoveNullKeyCheck.java
! test/java/util/prefs/RemoveReadOnlyNode.java
! test/java/util/prefs/RemoveUnregedListener.java

hg: jdk8/tl/jdk: 8003518: (prefs) Tests in jdk/test/java/util/prefs should not be run concurrently

[kurchi . subhra . hazra]

Changeset: 0ee09f17361e
Author:khazra
Date:  2012-11-16 12:28 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ee09f17361e

8003518: (prefs) Tests in jdk/test/java/util/prefs should not be run 
concurrently
Summary: Add java/util/prefs to exclusiveAccess.dirs in TEST.ROOT
Reviewed-by: alanb, mchung

! test/TEST.ROOT

Re: Code Review Request: 8003518: (prefs) Tests in jdk/test/java/util/prefs should not be run concurrently

[Kurchi Subhra Hazra]

Updated webrev: http://cr.openjdk.java.net/~khazra/8003518/webrev.01/

- Kurchi

On 11/15/12 10:28 PM, Alan Bateman wrote:

On 16/11/2012 06:16, Kurchi Subhra Hazra wrote:


Hi,

   The tests in jdk/test/util/prefs are not good candidates to run 
concurrently,
since on platforms such as Windows and Mac OS X, they currently 
read/write from
the same location on the persistent storage. This fix simply informs 
jtreg[1] to

not run these tests concurrently when using the conc:value option.

Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003518
Webrev: http://cr.openjdk.java.net/~khazra/8003518/webrev/
Looks fine, the only thing I suggest it adding it after java/rmi,  
that would make it consistent with othervm.dirs where the order is 
java, javax, com, sun.


-Alan.

Code Review Request: 8003518: (prefs) Tests in jdk/test/java/util/prefs should not be run concurrently

[Kurchi Subhra Hazra]

Hi,

   The tests in jdk/test/util/prefs are not good candidates to run concurrently,
since on platforms such as Windows and Mac OS X, they currently read/write from
the same location on the persistent storage. This fix simply informs jtreg[1] to
not run these tests concurrently when using the conc:value option.

Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003518
Webrev: http://cr.openjdk.java.net/~khazra/8003518/webrev/


Thanks,
- Kurchi

[1] http://openjdk.java.net/jtreg/

hg: jdk8/tl/jdk: 7198073: (prefs) user prefs not saved [macosx]

[kurchi . subhra . hazra]

Changeset: 3a6b76a468bd
Author:khazra
Date:  2012-10-16 15:23 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3a6b76a468bd

7198073: (prefs) user prefs not saved [macosx]
Summary: Using class member field to get node instead of argument
Reviewed-by: alanb

! src/macosx/classes/java/util/prefs/MacOSXPreferences.java
+ test/java/util/prefs/CheckUserPrefFirst.java
+ test/java/util/prefs/CheckUserPrefLater.java
+ test/java/util/prefs/CheckUserPrefsStorage.sh

Re: Code Review Request: 7198073: (prefs) user prefs not saved [macosx]

[Kurchi Subhra Hazra]

On 10/16/12 2:54 AM, Alan Bateman wrote:

On 16/10/2012 01:53, Kurchi Hazra wrote:

Hi Alan,

   Please find an updated webrev with a test included: 
http://cr.openjdk.java.net/~khazra/7198073/webrev.01/


CheckUserPrefsStorage.sh is the main entry point - it runs 
CheckUserPrefFirst first (which creates and attempts to store a 
preference),
and then runs CheckUserPrefLater (which attempts to retrieve the 
preference stored by the former).
Thanks for adding a test, it looks good to me, I just wonder if we 
should run with java.util.prefs.userRoot=. so that we don't leave 
anything behind in the event that CheckUserPrefLater doesn't run.


That did occur to me, but I have not yet checked what 
java.util.prefs.userRoot=. actually implies while using jtreg.
When I get more time to work on 7197662, I will be updating all the 
prefs test including this one.


Thanks,
Kurchi

Re: Code Review Request: 7198073: (prefs) user prefs not saved [macosx]

[Kurchi Subhra Hazra]

On 10/12/12 12:43 AM, Alan Bateman wrote:

On 12/10/2012 01:21, Kurchi Hazra wrote:

Hi,

   This is a regression introduced by the fix for 7160252[1] that I 
pushed a few weeks ago. We should
really be using the class member field isUser, rather than the 
argument passed in the constructor as a parameter
for cfFileForNode(). Due to this wrong parameter being passed, user 
preferences were never getting stored into

permanent storage.

Webrev: http://cr.openjdk.java.net/~khazra/7198073/webrev.00/
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198073

Thanks,
Kurchi

[1] http://cr.openjdk.java.net/~khazra/7160252/webrev.02/
Kurchi - thanks for tracking this one down, looking at it now it is 
obvious how this slipped through. I think the proposed change is okay 
although I think we need to do a bit of clean-up on this code at some 
point (not for this change, I realize this one needs to be fixed in 7u 
and I don't want to muddy the waters).
 Right, I will have to spend more time cleaning up this after 
committing this fix.


The other thin is tests. The preferences implementation that came via 
the Mac port is turning out to have a bit of a bug tail and one or two 
regressions have sneaked in along the way too. Do you think you could 
add a test for this issue? 

 Let me get back to you on this.

Also at some point we need to look at the test coverage and quality of 
the tests for this area as most/all of these Mac specific issues 
should have been caught before it ever went in.

 I agree. Again, this will be a longer time goal for me.

- Kurchi

Re: 8000269: Cleanup javadoc warnings

[Kurchi Subhra Hazra]

On 9/29/12 2:23 PM, Ulf Zibis wrote:


Am 29.09.2012 22:52, schrieb Alan Bateman:


http://cr.openjdk.java.net/~alanb/8000269/webrev/index.html


Class.java :

You mean java.io.FilePermission.java?


- in lines 702, 825 indentation should be 8.
- in line 826 I guess you wanted to move the curly brace to line 825
Curly Brace: I think that's the style we use when the method signature 
spreads across multiple lines.


- Kurchi


I've only reviewed the Sdiffs, so maybe there are more such cases, 
even in other classes.


-Ulf

hg: jdk8/tl/jdk: 7195933: There is incorrect link to "Info-ZIP Application Note 970311" in doc page of Package java.util.zip

[kurchi . subhra . hazra]

Changeset: e143d8f8e477
Author:dxu
Date:  2012-09-18 14:45 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e143d8f8e477

7195933: There is incorrect link to "Info-ZIP Application Note 970311" in doc 
page of Package java.util.zip
Summary: Correct a java doc link in java.util.zip package page
Reviewed-by: chegar, lancea, sherman
Contributed-by: dan...@oracle.com

! src/share/classes/java/util/zip/package.html

Re: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io

[Kurchi Subhra Hazra]

Thanks for cleaning up those spaces Dan. The changes look fine.
Sorry for the extra trouble!

- Kurchi

On 8/28/12 10:22 PM, Dan Xu wrote:
It is funny. :) I have searched all source codes under jdk and removed 
spaces for the similar cases.


Please review the new version of change at, 
http://cr.openjdk.java.net/~dxu/7193406/webrev.03/.


Thanks for your comment!

-Dan


On 08/28/2012 05:32 PM, Kurchi Hazra wrote:
Irony of the day - those changes were done by me! 
(http://cr.openjdk.java.net/~khazra/7157893/webrev.02/)  :D


They were probably a mistake/oversight. I guess the better way is 
without those extra spaces. See 
http://docs.oracle.com/javase/tutorial/java/javaOO/annotations.html.


If you have time, maybe you can remove those spaces I put in as a 
part of this CR.


Thanks!
Kurchi

On 8/28/2012 5:23 PM, Dan Xu wrote:
I also thought the space was not needed. But when I made the 
changes, I found that many similar codes had the space when two or 
more warning types need to be suppressed. For example, 
java/util/Collections.java,  java/util/Arrays.java, 
java/util/ComparableTimSort.java, and etc. If only one warning type 
needs to be suppressed, I don't see the space in our codes. Thanks!


-Dan



On 08/28/2012 05:08 PM, Kurchi Hazra wrote:
I don't think you need the space before "unchecked" and the one 
after "rawtypes" in lines 128 and 147 in
http://cr.openjdk.java.net/~dxu/7193406/webrev.02/src/share/classes/java/util/PropertyResourceBundle.java.sdiff.html. 



- Kurchi

On 8/28/2012 4:57 PM, Dan Xu wrote:

Thanks for all your good suggestions!

I have updated my changes, which revoke changes to makefiles and 
put @SuppressWarnings outside methods instead of introducing local 
variables for small methods.


The webrev is at 
http://cr.openjdk.java.net/~dxu/7193406/webrev.02/. Thanks!


-Dan

On 08/27/2012 04:33 PM, Stuart Marks wrote:

On 8/27/12 3:55 AM, Doug Lea wrote:

The underlying issue is that code size is one of the criteria
that JITs use to decide to compile/inline etc. So long as they do
so, there will be cases here and there where it critically
important to keep sizes small in bottleneck code. Not many,
but still enough for me to object to efforts that might
blindly increase code size for the sake of warnings cleanup.


I'm pleased that warnings cleanup has attracted this much 
attention. :-)


I was wondering where rule about @SuppressWarnings and local 
variables originally came from, and I tracked this back to 
Effective Java, Item 24, which says (as part of a fairly long 
discussion)


If you find yourself using the SuppressWarnings annotation
on a method or constructor that's more than one line long,
you may be able to move it onto a local variable declaration.
You may have to declare a new local variable, but it's worth it.

Aha! So it's all Josh Bloch's fault! :-)

In the warnings cleanup thus far, and in Dan's webrev, we've 
followed this rule fairly strictly. But since we seem to have 
evidence that this change isn't worth it, we should consider 
relaxing the rule for performance-critical code. How about adding 
a local variable for @SuppressWarnings only if the method is, 
say, longer than ten lines? (Or some other suitable threshold.) 
For short methods the annotation should be placed on the method 
itself.


The risk of suppressing other warnings inadvertently is pretty 
small in a short method, and short methods are the ones most 
likely to be impacted by the addition of a local variable 
affecting compilation/inlining decisions. Right?


(Also, while I've recommended that people follow the local 
variable rule fairly strictly, I think it tends to garbage up 
short methods. So I wouldn't mind seeing the rule relaxed on 
readability grounds as well.)


s'marks








--
-Kurchi

hg: jdk8/tl/jdk: 7168172: (fs) Files.isReadable slow on Windows

[kurchi . subhra . hazra]

Changeset: bd91a601265c
Author:khazra
Date:  2012-08-24 11:48 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd91a601265c

7168172: (fs) Files.isReadable slow on Windows
Summary: Remove DACL checking for read access, also reviewed by 
ulf.zi...@cosoco.de, zhong.j...@gmail.com
Reviewed-by: alanb

! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java

hg: jdk8/tl/jdk: 7184287: (prefs) BackingStoreException when calling flush on root node[macosx]

[kurchi . subhra . hazra]

Changeset: 74ceda3a98a0
Author:khazra
Date:  2012-07-24 13:38 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/74ceda3a98a0

7184287: (prefs) BackingStoreException when calling flush on root node[macosx]
Summary: Change implementation to enable user without administrative privileges 
to call flush
Reviewed-by: alanb

! src/macosx/classes/java/util/prefs/MacOSXPreferences.java
! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java
! test/ProblemList.txt

Re: Code Review Request: 7184287: (prefs) BackingStoreException when calling flush on root node[macosx]

[Kurchi Subhra Hazra]

Thanks Alan. There is another bug on synchronization in the prefs 
implementation that I need to look into.


I will get rid of the extra brace, and push this then.

- Kurchi

On 7/22/12 12:16 PM, Alan Bateman wrote:

On 19/07/2012 19:31, Kurchi Subhra Hazra wrote:

Hi,

While flushing user preferences, a BackingStoreException is not 
expected, since

the current user should be able to write such preferences to the
persistent storage (unlike system preferences, where current user needs
to have admin rights). This fix aims at allowing a user preference node
to flush any changes to the persistent storage on Mac OS X.

Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184287
Webrev: http://cr.openjdk.java.net/~khazra/7184287/webrev.00/

Thanks,
Kurchi
I looked at the changes and the approach looks good to me. Hopefully 
this is the end of the issues with the preferences API on Mac. The 
only thing that doesn't seem right to me is MacOSXPreferences.java 
L234 where it looks like an additional brace has sneaked in.


-Alan.

Code Review Request: 7184287: (prefs) BackingStoreException when calling flush on root node[macosx]

[Kurchi Subhra Hazra]

Hi, 

While flushing user preferences, a BackingStoreException is not expected, since 
the current user should be able to write such preferences to the 
persistent storage (unlike system preferences, where current user needs 
to have admin rights). This fix aims at allowing a user preference node 
to flush any changes to the persistent storage on Mac OS X.

Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184287 
Webrev: http://cr.openjdk.java.net/~khazra/7184287/webrev.00/ 

Thanks, 
Kurchi

hg: jdk8/tl/jdk: 7185051: Remove TestProviderLeak.java from the ProblemList

[kurchi . subhra . hazra]

Changeset: 773474da570b
Author:khazra
Date:  2012-07-18 15:19 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/773474da570b

7185051: Remove TestProviderLeak.java from the ProblemList
Summary: Remove TestProviderLeak.java from jdk test problem list.
Reviewed-by: khazra
Contributed-by: dan...@oracle.com

! test/ProblemList.txt

hg: jdk8/tl/jdk: 7177045: Rework the TestProviderLeak.java regression test, it is too fragile to low memory errors.

[kurchi . subhra . hazra]

Changeset: 1469be7182b4
Author:khazra
Date:  2012-07-16 16:30 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1469be7182b4

7177045: Rework the TestProviderLeak.java regression test, it is too fragile to 
low memory errors.
Summary: Increase Xmx to 20 MB and add mechanisms to eat up most of the JVM 
free memory.
Reviewed-by: wetmore
Contributed-by: dan...@oracle.com

! test/com/sun/crypto/provider/KeyFactory/TestProviderLeak.java

Code Review Request: 7183800: TEST_BUG: Update tests to run on Ubuntu 12.04 (localhost is 127.0.1.1)

[Kurchi Subhra Hazra]

Hi,

   Some tests in our test repository assume that 
InetAddress.getLocalHost() will return 127.0.0.1. However, with
linux systems running Ubuntu 12.04 now returning 127.0.1.1 as localhost, 
these tests are failing. I have changed two
of the NIO tests to remove their dependency on 
InetAddress.getLocalHost(). A third test has been added to

the ProblemList.txt since the changes required for it are more involved.

Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7183800
Webrev: http://cr.openjdk.java.net/~khazra/7183800/webrev.00/


Thanks,
Kurchi

hg: jdk8/tl/jdk: 7160252: (prefs) NodeAddedEvent was not delivered when new node add when new Node

[kurchi . subhra . hazra]

Changeset: e9461aeff91f
Author:khazra
Date:  2012-07-13 16:02 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e9461aeff91f

7160252: (prefs) NodeAddedEvent was not delivered when new node add when new 
Node
Summary: Change native code to convey to Java code whether a new node was added
Reviewed-by: alanb, chegar

! src/macosx/classes/java/util/prefs/MacOSXPreferences.java
! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java
! src/macosx/native/java/util/MacOSXPreferencesFile.m
+ test/java/util/prefs/AddNodeChangeListener.java

Re: Code Review Request: 7160252: (prefs) NodeAddedEvent was not delivered when new node add when new Node

[Kurchi Subhra Hazra]

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


Thanks for pointing that out. How about: 
http://cr.openjdk.java.net/~khazra/7160252/webrev.02/
Looks fine except that the test case is missing from latest webrev. 
Assuming that test/java/util/prefs/AddNodeChangeListener.java hasn't 
changed from the original webrev then I think you are all set to push.


-Alan.

Re: Bug 7176907 - Patches for javac warnings cleanup (text and util) from Adopt OpenJDK

[Kurchi Subhra Hazra]

Hi,

  I was just going through the patches, there are some more fallthrough 
cases in

src/share/classes/java/util/regex/Pattern.java.(for example in line 2247).
Are these not generating warnings?

- Kurchi

On 6/20/12 7:30 AM, Martijn Verburg wrote:


Hi all,

Apologies, I didn't check that attachments were stripped.  The patches
can be found at:


https://raw.github.com/AdoptOpenJDK/PatchReview/master/submitted/core_java_text.patch

https://raw.github.com/AdoptOpenJDK/PatchReview/master/submitted/core_java_util.patch

Cheers,
Martijn


Hi Martijn,
the two patches looks good.

A minor nit, why is there a space between the '(' and the readUByte() in
readUShort.

Thanks for the quick review! No reason on the whitespace, I've fixed that now.

Quick question.  Is there a checkstyle or jcheck that we should be
applying to any corelib patches going forwards?

Cheers,
Martijn

hg: jdk8/tl/jdk: 7173645: (props) System.getProperty("os.name") should return "Windows Server 2012" for Windows Server 2012

[kurchi . subhra . hazra]

Changeset: af313ded4ffb
Author:khazra
Date:  2012-06-06 11:37 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/af313ded4ffb

7173645: (props) System.getProperty("os.name") should return "Windows Server 
2012" for Windows Server 2012
Summary: Enable Windows Server 2012 to be recognized as "os.name"
Reviewed-by: alanb, dholmes, chegar

! src/windows/native/java/lang/java_props_md.c

hg: jdk8/tl/jdk: 7171591: getDefaultScopeID() in src/solaris/native/java/net/net_util_md.c should return a value

[kurchi . subhra . hazra]

Changeset: eb441933f6fe
Author:khazra
Date:  2012-05-29 13:16 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eb441933f6fe

7171591: getDefaultScopeID() in src/solaris/native/java/net/net_util_md.c 
should return a value
Summary: Use CHECK_NULL_RETURN instead of CHECK_NULL
Reviewed-by: alanb

! src/solaris/native/java/net/net_util_md.c

hg: jdk8/tl/jdk: 7170169: (props) System.getProperty("os.name") should return "Windows 8" when run on Windows 8

[kurchi . subhra . hazra]

Changeset: 0c3d9050c918
Author:khazra
Date:  2012-05-23 10:41 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0c3d9050c918

7170169: (props) System.getProperty("os.name") should return "Windows 8" when 
run on Windows 8
Summary: Enable Windows Version 6.2 to be recognized as Windows 8
Reviewed-by: darcy, dholmes, alanb, chegar

! src/windows/native/java/lang/java_props_md.c

Re: Code Review Request: 7170169: (props) System.getProperty("os.name") should return "Windows 8" when run on Windows 8

[Kurchi Subhra Hazra]

I ran the tests in jdk/test/java/lang and they all pass. Let me know if 
you think some other tests should also

be run.

- Kurchi

On 5/22/12 7:33 PM, David Holmes wrote:

On 23/05/2012 11:32 AM, Kurchi Hazra wrote:

Hi,

This is a minor change to java_props_md.c to return "Windows 8" as the
"os.name" for Windows version 6.2.


Is there any windows version specific code that might also need 
updating to allow for Windows 8 aka 6.2?


David


Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170169
Webrev: http://cr.openjdk.java.net/~khazra/7170169/webrev.00/

Thanks,
Kurchi

hg: jdk8/tl/jdk: 7164636: (prefs) Cleanup src/macosx/classes/java/util/prefs

[kurchi . subhra . hazra]

Changeset: 9a18e318f95a
Author:khazra
Date:  2012-05-15 11:51 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9a18e318f95a

7164636: (prefs) Cleanup src/macosx/classes/java/util/prefs
Summary: Remove rawtype usages and other code cleanup
Reviewed-by: chegar, briangoetz

! src/macosx/classes/java/util/prefs/MacOSXPreferences.java
! src/macosx/classes/java/util/prefs/MacOSXPreferencesFactory.java
! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java

hg: jdk8/tl/jdk: 7096436: (sc) SocketChannel.connect fails on Windows 8 when channel configured non-blocking

[kurchi . subhra . hazra]

Changeset: 5152c832745a
Author:khazra
Date:  2012-05-09 16:55 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5152c832745a

7096436: (sc) SocketChannel.connect fails on Windows 8 when channel configured 
non-blocking
Summary: Set localAddress only when connection is established
Reviewed-by: alanb

! src/share/classes/sun/nio/ch/SocketChannelImpl.java

hg: jdk8/tl/jdk: 7165118: (prefs) AbstractPreferences.remove(null) does not throw NPE

[kurchi . subhra . hazra]

Changeset: 59121a4c71c6
Author:khazra
Date:  2012-05-09 11:14 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/59121a4c71c6

7165118: (prefs) AbstractPreferences.remove(null) does not throw NPE
Summary: Insert null argument check in AbstractPreferences.remove()
Reviewed-by: dholmes, chegar, alanb

! src/share/classes/java/util/prefs/AbstractPreferences.java
! test/java/util/prefs/RemoveNullKeyCheck.java

hg: jdk8/tl/jdk: 7118100: (prefs) Inconsistency when using system and user preference on OSX Lion

[kurchi . subhra . hazra]

Changeset: 108a02a57b75
Author:khazra
Date:  2012-04-26 12:04 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/108a02a57b75

7118100: (prefs) Inconsistency when using system and user preference on OSX Lion
Summary: Enable user to read/write preferences to persistent storage
Reviewed-by: alanb

! src/macosx/classes/java/util/prefs/MacOSXPreferences.java
! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java

hg: jdk8/tl/jdk: 7160242: (prefs) Preferences.remove(null) does not throw NPE [macosx]

[kurchi . subhra . hazra]

Changeset: 3e398b549cea
Author:khazra
Date:  2012-04-25 12:31 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e398b549cea

7160242: (prefs) Preferences.remove(null) does not throw NPE [macosx]
Summary: Insert null check of argument in remove()'s implementation
Reviewed-by: forax, chegar, alanb

! src/macosx/classes/java/util/prefs/MacOSXPreferences.java
+ test/java/util/prefs/RemoveNullKeyCheck.java

hg: jdk8/tl/jdk: 7144274: [macosx] Default IPv6 multicast interface is not being set when calling MulticastSocket.joinGroup()

[kurchi . subhra . hazra]

Changeset: fcdbd1f34309
Author:khazra
Date:  2012-04-24 14:59 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fcdbd1f34309

7144274: [macosx] Default IPv6 multicast interface is not being set when 
calling MulticastSocket.joinGroup()
Summary: Get default interface for Mac OS X when interface is not set
Reviewed-by: chegar

! src/solaris/native/java/net/PlainDatagramSocketImpl.c
! src/solaris/native/java/net/net_util_md.c

Code Review Request: 7160242: (prefs) Preferences.remove(null) does not throw NPE [macosx]

[Kurchi Subhra Hazra]

Hi,

This change inserts a null check for the key being passed to 
Preferences.remove() on Mac, so that
the method throws a NullPointerException when key is null (according to 
its specification).


Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160242
Webrev: http://cr.openjdk.java.net/~khazra/7160242/webrev.00/ Thanks, 
Kurchi

hg: jdk8/tl/jdk: 7158636: InterfaceAddress.getBroadcast() returns invalid broadcast address on WLAN

[kurchi . subhra . hazra]

Changeset: 715f50872ae7
Author:khazra
Date:  2012-04-19 18:11 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/715f50872ae7

7158636: InterfaceAddress.getBroadcast() returns invalid broadcast address on 
WLAN
Summary: Update Windows native code to infer WLAN interface type in Windows 
Vista and later
Reviewed-by: chegar, alanb

! src/windows/native/java/net/NetworkInterface.c
! src/windows/native/java/net/NetworkInterface.h

hg: jdk8/tl/jdk: 7162385: TEST_BUG: sun/net/www/protocol/jar/B4957695.java failing again

[kurchi . subhra . hazra]

Changeset: bc51d0569ccd
Author:khazra
Date:  2012-04-19 13:26 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bc51d0569ccd

7162385: TEST_BUG: sun/net/www/protocol/jar/B4957695.java failing again
Summary: Enable finding "foo1.jar"
Reviewed-by: chegar

! test/sun/net/www/protocol/jar/B4957695.java

hg: jdk8/tl/jdk: 7157893: Warnings Cleanup in java.util.*

[kurchi . subhra . hazra]

Changeset: 1757f049e8c0
Author:khazra
Date:  2012-04-17 12:21 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1757f049e8c0

7157893: Warnings Cleanup in java.util.*
Summary: Minor code changes to cleanup warnings in java.util.*
Reviewed-by: mduigou, naoto, smarks
Contributed-by: Remi Forax 

! src/share/classes/java/util/AbstractCollection.java
! src/share/classes/java/util/AbstractList.java
! src/share/classes/java/util/AbstractMap.java
! src/share/classes/java/util/AbstractSet.java
! src/share/classes/java/util/ArrayDeque.java
! src/share/classes/java/util/ArrayList.java
! src/share/classes/java/util/Arrays.java
! src/share/classes/java/util/Calendar.java
! src/share/classes/java/util/Collections.java
! src/share/classes/java/util/ComparableTimSort.java
! src/share/classes/java/util/Currency.java
! src/share/classes/java/util/EnumMap.java
! src/share/classes/java/util/EnumSet.java
! src/share/classes/java/util/HashMap.java
! src/share/classes/java/util/HashSet.java
! src/share/classes/java/util/Hashtable.java
! src/share/classes/java/util/IdentityHashMap.java
! src/share/classes/java/util/IllegalFormatConversionException.java
! src/share/classes/java/util/JumboEnumSet.java
! src/share/classes/java/util/LinkedHashMap.java
! src/share/classes/java/util/Observable.java
! src/share/classes/java/util/PriorityQueue.java
! src/share/classes/java/util/Properties.java
! src/share/classes/java/util/PropertyPermission.java
! src/share/classes/java/util/RegularEnumSet.java
! src/share/classes/java/util/ResourceBundle.java
! src/share/classes/java/util/ServiceLoader.java
! src/share/classes/java/util/TimeZone.java
! src/share/classes/java/util/TreeMap.java
! src/share/classes/java/util/TreeSet.java
! src/share/classes/java/util/WeakHashMap.java

hg: jdk8/tl/jdk: 7152856: TEST_BUG: sun/net/www/protocol/jar/B4957695.java failing on Windows

[kurchi . subhra . hazra]

Changeset: 31c15e2f51ba
Author:khazra
Date:  2012-04-17 11:59 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/31c15e2f51ba

7152856: TEST_BUG: sun/net/www/protocol/jar/B4957695.java failing on Windows
Summary: Remove usage of HTTP Server at test/sun/net/www/httptest
Reviewed-by: chegar, alanb

! test/sun/net/www/protocol/jar/B4957695.java

hg: jdk8/tl/jdk: 7152007: Fix warnings in sun/rmi/rmic

[kurchi . subhra . hazra]

Changeset: 337d4570b8d6
Author:khazra
Date:  2012-03-16 11:52 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/337d4570b8d6

7152007: Fix warnings in sun/rmi/rmic
Summary: Minor code changes to remove warnings in sun/rmi/rmic
Reviewed-by: chegar, smarks

! src/share/classes/sun/rmi/rmic/BatchEnvironment.java
! src/share/classes/sun/rmi/rmic/Main.java
! src/share/classes/sun/rmi/rmic/RMIGenerator.java
! src/share/classes/sun/rmi/rmic/newrmic/Main.java
! src/share/classes/sun/rmi/rmic/newrmic/Resources.java

hg: jdk8/tl/jdk: 7045655: An empty InMemoryCookieStore should not return true for removeAll

[kurchi . subhra . hazra]

Changeset: 3bfebedb549f
Author:khazra
Date:  2012-03-15 13:21 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3bfebedb549f

7045655: An empty InMemoryCookieStore should not return true for removeAll
Summary: CookieStore.removeAll() should return false for an empty CookieStore
Reviewed-by: chegar

! src/share/classes/java/net/InMemoryCookieStore.java
! test/java/net/CookieHandler/NullUriCookieTest.java

hg: jdk8/tl/jdk: 7151348: Build breaks due to warning clean up in sun.rmi.*(7146763)

[kurchi . subhra . hazra]

Changeset: ce6b852bf4e2
Author:khazra
Date:  2012-03-05 17:38 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ce6b852bf4e2

7151348: Build breaks due to warning clean up in sun.rmi.*(7146763)
Summary: Undo changes to sun/rmi/rmic/* commited as fix for 7146763
Reviewed-by: smarks

! src/share/classes/sun/rmi/rmic/BatchEnvironment.java
! src/share/classes/sun/rmi/rmic/Main.java
! src/share/classes/sun/rmi/rmic/RMIGenerator.java
! src/share/classes/sun/rmi/rmic/newrmic/Main.java
! src/share/classes/sun/rmi/rmic/newrmic/Resources.java

hg: jdk8/tl/jdk: 7146763: Warnings cleanup in the sun.rmi and related packages

[kurchi . subhra . hazra]

Changeset: 8f61ac5986ee
Author:khazra
Date:  2012-03-02 13:48 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8f61ac5986ee

7146763: Warnings cleanup in the sun.rmi and related packages
Summary: Cleanup warnings and use jkd7 features in sun.rmi.*
Reviewed-by: smarks, chegar, forax, dmocek

! make/sun/rmi/cgi/Makefile
! make/sun/rmi/registry/Makefile
! make/sun/rmi/rmi/Makefile
! make/sun/rmi/rmid/Makefile
! src/share/classes/com/sun/rmi/rmid/ExecOptionPermission.java
! src/share/classes/com/sun/rmi/rmid/ExecPermission.java
! src/share/classes/sun/rmi/log/ReliableLog.java
! src/share/classes/sun/rmi/registry/RegistryImpl.java
! src/share/classes/sun/rmi/rmic/BatchEnvironment.java
! src/share/classes/sun/rmi/rmic/Main.java
! src/share/classes/sun/rmi/rmic/RMIGenerator.java
! src/share/classes/sun/rmi/rmic/newrmic/Main.java
! src/share/classes/sun/rmi/rmic/newrmic/Resources.java
! src/share/classes/sun/rmi/server/ActivatableRef.java
! src/share/classes/sun/rmi/server/Activation.java
! src/share/classes/sun/rmi/server/ActivationGroupImpl.java
! src/share/classes/sun/rmi/server/LoaderHandler.java
! src/share/classes/sun/rmi/server/MarshalInputStream.java
! src/share/classes/sun/rmi/server/UnicastRef.java
! src/share/classes/sun/rmi/server/UnicastRef2.java
! src/share/classes/sun/rmi/server/UnicastServerRef.java
! src/share/classes/sun/rmi/server/Util.java
! src/share/classes/sun/rmi/server/WeakClassHashMap.java
! src/share/classes/sun/rmi/transport/ConnectionInputStream.java
! src/share/classes/sun/rmi/transport/DGCAckHandler.java
! src/share/classes/sun/rmi/transport/DGCClient.java
! src/share/classes/sun/rmi/transport/DGCImpl.java
! src/share/classes/sun/rmi/transport/ObjectTable.java
! src/share/classes/sun/rmi/transport/StreamRemoteCall.java
! src/share/classes/sun/rmi/transport/Target.java
! src/share/classes/sun/rmi/transport/Transport.java
! src/share/classes/sun/rmi/transport/WeakRef.java
! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java
! src/share/classes/sun/rmi/transport/proxy/HttpInputStream.java
! src/share/classes/sun/rmi/transport/proxy/HttpSendSocket.java
! src/share/classes/sun/rmi/transport/proxy/RMIMasterSocketFactory.java
! src/share/classes/sun/rmi/transport/tcp/ConnectionMultiplexer.java
! src/share/classes/sun/rmi/transport/tcp/TCPChannel.java
! src/share/classes/sun/rmi/transport/tcp/TCPEndpoint.java
! src/share/classes/sun/rmi/transport/tcp/TCPTransport.java