Hi,
The following webrev removes warnings in sun.rmi.* packages. I have
neglected nearly all
deprecation warnings, since this code uses deprecated classes such as
java.rmi.server.LogStream
with no suggested replacements. I have included -Xlint:all,-deprecation
as an option instead
in the a
Corrected the subject line.
Hi,
The following webrev removes warnings in sun.rmi.* packages. I have
neglected nearly all
deprecation warnings, since this code uses deprecated classes such as
java.rmi.server.LogStream
with no suggested replacements. I have included -Xlint:all,-deprecation
a
ctionTable.get(id);
---
< idObj = new Integer(id);
< info = connectionTable.get(idObj);
158c160
> connectionTable.put(id, info);
---
< connectionTable.put(idObj, info);
.
-Chris.
On 22/02
connectionTable.get(id);
---
< idObj = new Integer(id);
< info = connectionTable.get(idObj);
158c160
> connectionTable.put(id, info);
---
< connectionTable.put(idObj, info);
.
-Chris.
On
Hi Stuart,
Thanks for the detailed explanation. Here is an updated webrev:
http://cr.openjdk.java.net/~khazra/7146763/webrev.02/
- Kurchi
On 2/24/2012 12:54 AM, Stuart Marks wrote:
On 2/22/12 1:25 PM, Kurchi Hazra wrote:
On 2/22/2012 10:01 AM, Rémi Forax wrote:
Hi Kurchi, hi all,
in
ed on, since it implicitly also builds files from sun/tools
with more then 400
warnings in them. The change in this file has now been removed.
- Kurchi
On 2/24/2012 11:01 AM, Kurchi Hazra wrote:
Hi Stuart,
Thanks for the detailed explanation. Here is an updated webrev:
http://cr.openjdk.jav
tion is caught. (This kind of change is usually out of bounds
for warnings changes but, as above, since I'm closer to this code I'd
say to go ahead with it.)
Thanks,
s'marks
On 2/24/12 2:24 PM, Kurchi Hazra wrote:
Hi,
Please ignore the previous webrev and see this instead:
ht
03547.html
[2]
http://stuartmarks.wordpress.com/2011/04/29/when-should-diamond-be-used/
On 2/28/12 3:22 PM, Kurchi Hazra wrote:
Hi Stuart,
Thanks for your comments. Regarding the use of diamonds, I remember
this issue
coming up when i was
fixing networking warnings. See :
http://mail.openjd
Hi,
jdk8 build is breaking if SKIP_BOOT_CYCLE is set to false due to some
changes made
as a part of warnings cleanup in sun.rmi.* (see 7146763) that are
incompatible with the
code in the corba respository. This CR is simply to revert back the
changes made to files
in sun/rmi/rmic for the ti
Hi,
The warning fixes in sun/rmi/rmic originally pushed as a part of CR
7146763, were undone by 7151348
due to build breakage when SKIP_BOOT_CYCLE is set to false.
This CR attempts to incorporate these warning fixes into jdk8. Most
of the changes have already been code-reviewed [1],
but o
Hi,
These changes cleanup warnings in java.util.* and were contributed by
Remi Forax ([email protected]).
Specifically the files that I merged/had conflicts are:
src/share/classes/java/util/Currency.java
src/share/classes/java/util/EnumMap.java
src/share/classes/java/util/PropertyPermissio
Hi Stuart,
Please find the updated webrev here:
http://cr.openjdk.java.net/~khazra/7157893/webrev.01/
I hope to have included all the suggestions correctly. Also, note that I
made some new changes in Hashtable.java at lines 185, 355 and 910 to get
rid of some additional warnings.
Thanks
with this one. I have updated EnumMap.java to remove cast in
unmaskNull() and then remove the unrequired casts. (and some changes in
724, 740 and 789 while I was there)
Thanks,
Kurchi
Mike
On Apr 10 2012, at 16:15 , Kurchi Hazra wrote:
Hi Stuart,
Please find the updated webrev h
Sorry, I forgot to insert a link to the webrev :
http://cr.openjdk.java.net/~khazra/7157893/webrev.02/
- Kurchi
On 4/16/2012 12:31 PM, Kurchi Hazra wrote:
On 4/13/2012 8:26 PM, Mike Duigou wrote:
Looks good for commit. Just a few notes
EnumMap.java:
maskNull seemed to have the
Hi,
Updated webrev:
http://cr.openjdk.java.net/~khazra/7160242/webrev.01/
Thanks,
Kurchi
On 4/21/2012 4:23 AM, Rémi Forax wrote:
On 04/21/2012 09:52 AM, Alan Bateman wrote:
On 20/04/2012 20:09, Kurchi Subhra Hazra wrote:
Hi,
This change inserts a null check for the key being passed to
Pref
, Kurchi Hazra wrote:
Hi,
Updated webrev:
http://cr.openjdk.java.net/~khazra/7160242/webrev.01/
Thanks,
Kurchi
Hi Kurchi,
Object.requireNonNull() return the first argument,
so there is no need to store it again in key.
So instead of
key = Objects.requireNonNull(key, "Specified key cann
Hi,
While syncing user preferences, a BackingStoreException is not expected,
since
the current user should be able to read/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 nod
Thanks Alan for the thumbs up.
I filed 7164636 for the cleanup.
- Kurchi
On 4/26/2012 12:18 AM, Alan Bateman wrote:
On 26/04/2012 01:34, Kurchi Hazra wrote:
Hi,
While syncing user preferences, a BackingStoreException is not
expected, since
the current user should be able to read/write
Hi,
This is a simple fix to enable AbstractPreferences.remove() to check
for a null argument and
throw a NullPointerException if required.
I have also modified test/java/util/prefs/RemoveNullKeyCheck.java to
cover this case.
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7165118
our change.
D'oh, sorry obviously you're right. Somehow I overlooked most
important line of this change! Anyway, you are right we should update
the docs.
-Chris.
David
Oh, nice to see a test added for this too.
-Chris.
David
On 2/05/2012 5:01 AM, Kurchi Hazra wrote:
Hi,
Thi
Requesting approval to commit fix for CR 7118100.
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7118100
Webrev: http://cr.openjdk.java.net/~khazra/7118100/webrev.01/
This had been reviewed by Alan Bateman. [1]
This fix has been pushed into jdk8 [2]
Thanks,
Kurchi
[1]
http://mail.op
Hi,
This change aims at removing some rawtype usages in
src/macosx/classes/java/util/prefs that were brought
into jdk8 with the macport. I have added @Override tags too where
applicable.
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7164636
Webrev: http://cr.openjdk.java.net/~kha
angedFiles and cachedFiles do not need to be set to
null (I
believe this will generate a little less bytecode), as this is the
default reference value. Since you are in clean-up mode ;-)
-Chris.
On 11/05/2012 22:46, Kurchi Hazra wrote:
Hi,
This change aims at removing some rawtype usages in
src/mac
Hi,
This is a minor change to java_props_md.c to return "Windows 8" as
the "os.name" for Windows version 6.2.
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170169
Webrev: http://cr.openjdk.java.net/~khazra/7170169/webrev.00/
Thanks,
Kurchi
Requesting approval to commit fix for CR 7170169.
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170169
Webrev: http://cr.openjdk.java.net/~khazra/7170169/7u6/webrev.00/
This had been reviewed by darcy, dholmes, alanb, chegar. [1]
This fix has been pushed into jdk8 [2]
Thanks,
Kurchi
Hi,
This is a minor change in java_props_md.c to return "Windows Server 2012" as
the "os.name" when running on Windows Server 2012.
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173645 (To appear soon)
Webrev: http://cr.openjdk.java.net/~khazra/7173645/webrev.00/
Thanks,
Kurchi
Thanks for updating this. This looks good to me. I guess Stuart will be
sponsoring the patch.
There are a couple of other switch statements in
src/share/classes/java/util/regex/Pattern.java.
which are not throwing fallthrough warnings (in Netbeans at least),
although there is fallthrough happ
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
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
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
AM, Kurchi Subhra Hazra wrote:
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 1
I just tried running these tests with -Djava.net.preferIPv4Stack set
to true, but they still fail. I remember working on some of these
failures in networking where ipv6 multicast was buggy,
but absolutely nothing made those tests work.
However, in this case, if we make sure that the address th
This is a request for approval to backport the fix for 7160252 from 8 to 7u8.
Bug:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160252
Webrev:http://cr.openjdk.java.net/~khazra/7160252/7u8/webrev.00/
This had been reviewed by Alan Bateman and Chris Hegarty. [1]
This fix has been pushed i
This is a request for approval to backport the fix for 7184287 rom 8 to
7u8.
Bug:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184287
Webrev:http://cr.openjdk.java.net/~khazra/7184287/7u8/webrev.00/
This had been reviewed by Alan Bateman. [1]
This fix has been pushed into jdk8 [2]. The
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
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 sp
Hi,
The tests in java/util/prefs creates new nodes under the user's home
directory.
This causes the tests to start out with pre-existing preferences and
sometimes
leads to interference between the tests. This fix is to change the userRoot
property for each of these tests so these tests create
.
Thanks!
- Kurchi
-Chris.
-Dan
On Thu 20 Sep 2012 02:22:15 PM PDT, Kurchi Hazra wrote:
Hi,
The tests in java/util/prefs creates new nodes under the user's home
directory.
This causes the tests to start out with pre-existing preferences and
sometimes
leads to interference between the tes
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
prefere
(which attempts to retrieve the
preference stored by the former).
Thanks,
Kurchi
On 12.10.2012 07:57, Kurchi Subhra Hazra wrote:
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
This is a request for approval to backport the fix for 7198073 from 8 to
7u12.
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198073
Webrev: http://cr.openjdk.java.net/~khazra/7198073/7u12/webrev/
This change been reviewed by Alan Bateman [1] and the fix has been
pushed into jdk8 [
ctive platform uses to store
preferences.
Thanks,
Kurchi
On 9/21/12 11:49 AM, Kurchi Hazra wrote:
On 21.09.2012 02:03, Chris Hegarty wrote:
On 21/09/12 01:12, Dan Xu wrote:
Kurchi,
Can you append bug number 7197662 to @bug field in each test so that it
is easy to check its history?
Yes, th
Isn't the optimal granularity value different for different number of
cores, differing amounts of memory available in a machine etc?
If someone is trying to use a parallelSort to take adavntage of all the
cores in a machine, he is anyway a little bit of an
advanced user I guess.
- Kurchi
On 21
thout having
to run benchmarks, profiling, etc. I am concerned that exposing the threshold
will simply confuse most developers.
-Chris
On 21 Dec 2012, at 18:21, Kurchi Hazra wrote:
Isn't the optimal granularity value different for different number of cores,
differing amounts of memory av
Hi Sherman,
As I was telling you, I had a very minor comment - the javadoc for the
enums DayOfWeek and Month shows the days/months in alphabetical order.
I am not sure if it is somehow possible to bypass that and show them in
the order of their occurrence instead.
Thanks,
- Kurchi
On 15.01.2
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.PlatformLog
Right - I think I can disable syncing attempts for a file once we get an
EACCESS error code . Locked files
should return EAGAIN. I'll have to check on how this works on
Solaris/Linux/Mac and will follow up.
Thanks for digging up the history.
- Kurchi
On 5/21/2013 10:28 AM, Mike Duigou wrote:
Hi,
This is to elimnate the overrides warning from ClassDeclaration.java.
This class is used by rmi, but sun/tools/java and
sun/tools/javac also heavily uses it, let me know if anyone else should
also be reviewing it.
Bug: http://bugs.sun.com/view_bug.do?bug_id=8016698 [To appear]
Webrev: htt
On 6/14/2013 11:56 PM, Alan Bateman wrote:
On 14/06/2013 23:59, Kurchi Hazra wrote:
Hi,
This is to elimnate the overrides warning from ClassDeclaration.java.
This class is used by rmi, but sun/tools/java and
sun/tools/javac also heavily uses it, let me know if anyone else
should also be
ClassDefinition#subClassOf(),
which walks up the inheritance path of the concerned
class to check if any of those are equal to the argument
ClassDeclaration (and hence have equal Types)..
- Kurchi
On 6/17/2013 10:45 AM, Kurchi Hazra wrote:
On 6/14/2013 11:56 PM, Alan Bateman wrote:
On 14/06/2013 23
uals ;-) Otherwise, looks fine
to me.
-Chris.
On 06/18/2013 12:01 AM, Kurchi Hazra wrote:
I spent some more time reviewing this, I believe the equals()
implementation is correct. Given one string, we get a unique
Identifier. The Identifier has the associated Type cached - so given an
Identifie
51 matches
Mail list logo
