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

On 04/25/2012 12:20 AM, Kurchi Hazra wrote: Thanks Remi. I changed it: http://cr.openjdk.java.net/~khazra/7160242/webrev.02/ Thumb up. Can you also point out what advantage using Object.requireNonNull has over simply doing a key == null check as I was doing before? Josh Bloch words are be

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

Thanks Remi. I changed it: http://cr.openjdk.java.net/~khazra/7160242/webrev.02/ Can you also point out what advantage using Object.requireNonNull has over simply doing a key == null check as I was doing before? Thanks, Kurchi On 4/24/2012 3:07 PM, Rémi Forax wrote: On 04/24/2012 11:49 PM,

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

On 04/24/2012 11:49 PM, 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, "Sp

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

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 w

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

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

hg: jdk8/tl/jdk: 7151434: java -jar -XX crashes java launcher

Changeset: f68c854fa584 Author:ksrini Date: 2012-04-24 10:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f68c854fa584 7151434: java -jar -XX crashes java launcher Reviewed-by: mchung, darcy ! src/share/bin/java.c ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/Te

Re: Please review: 7151434: java -jar -XX crashes java launcher

Hi Kumar, The launcher changes looks fine, but I recommend generally documenting the null-handling protocol in these sort of functions. We generally don't include bug ids in the next of the test, but I see the test file does that in other areas. Cheers, -Joe On 04/24/2012 08:24 AM, Kumar

Re: Please review: 7151434: java -jar -XX crashes java launcher

Looks good to me. Mandy On 4/24/2012 8:24 AM, Kumar Srinivasan wrote: Hi, Could you please review this, actually the launcher is a 2 line change, but when I was testing/experimenting with this, it was hard to inspect the .jtr file for test failure, the test framework is cleanup to help the re

Please review: 7151434: java -jar -XX crashes java launcher

Hi, Could you please review this, actually the launcher is a 2 line change, but when I was testing/experimenting with this, it was hard to inspect the .jtr file for test failure, the test framework is cleanup to help the reader quickly identify the failing test cases. http://cr.openjdk.java.net

Re: Remove the assert in Integer.valueOf()

Am 24.04.2012 15:56, schrieb Rémi Forax: Here, I don't really ask for tweaking something but more to remove an assert which do something which is unrelated to the current algorithm. In my opinion, it's a debug assert used during the development that slip into the production code. The fact that th

Re: Remove the assert in Integer.valueOf()

On 24/04/2012 14:56, Rémi Forax wrote: Here, I don't really ask for tweaking something but more to remove an assert which do something which is unrelated to the current algorithm. In my opinion, it's a debug assert used during the development that slip into the production code. The fact that t

Re: Remove the assert in Integer.valueOf()

On 04/24/2012 02:12 AM, Ulf Zibis wrote: Hi Rémi, I think, instead tweaking the java code, Hotspot inlining heuristic should better be changed to count the bytes of the compiled code. Than any code would benefit from, not only Integer.valueOf(). -Ulf Here, I don't really ask for tweaking so

hg: jdk8/tl/jdk: 7163865: Performance improvement for DateFormatSymbols.getZoneIndex(String)

Changeset: 2c35304e885a Author:youdwei Date: 2012-04-24 21:06 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c35304e885a 7163865: Performance improvement for DateFormatSymbols.getZoneIndex(String) Reviewed-by: okutsu ! src/share/classes/java/text/DateFormatSymbols.java

Re: sun.management.Agent: the properties.putAll API may fail with ConcurrentModifcationException on multi-thread scenario

Deven, After close look and off-line discussion with David Holmes, the changes looks good for me. I'll take care of the rest. We have one more place in Agent.java executing exactly the same code so I'll change both of them on your behalf. -Dmitry On 2012-04-23 11:43, Deven You wrote: Thanks

Re: Port to HP Itanium OpenVMS

Hi Josef, first of all, the right mailing list for your question would be porters-...@openjdk.java.net (I've redirected this mail to the new list ) Porting to OpenVMS Itanium would be particularly hard, because it involves two steps: 1. porting to a new processor architecture (IA64) 2. porting