Re: New constructor in sun.tools.java.ClassPath builds a path using File.separator instead of File.pathSeparatorChar

On 04/12/2012 04:26 PM, Alan Bateman wrote: On 12/04/2012 08:22, Deven You wrote: I have verified this commit. Thanks Alan and Charles! The change-set that Charles pushed added test/sun/tools/classpath/ RMICClassPathTest.java but I didn't see it in the original webrev. I see now that your ori

Re: Generics & Reification Was Code Review Request: 7157893: Warnings Cleanup in java.util.*

On 4/11/12 4:42 AM, Rémi Forax wrote: On 04/07/2012 02:35 AM, Stuart Marks wrote: In order to program effectively with generics, I think you have to understand erasure and its implications. It may have been an unfortunate choice, but erasure is part of the language and we have to deal with it an

Re: Code Review Request: 7157893: Warnings Cleanup in java.util.*

Thanks for the updates. They look fine to me. I think Mike Duigou was still looking at the changes; I'd suggest waiting for him to respond. s'marks On 4/10/12 4:15 PM, Kurchi Hazra wrote: Hi Stuart, Please find the updated webrev here: http://cr.openjdk.java.net/~khazra/7157893/webrev.01/

hg: jdk8/tl/jdk: 7160895: tools/launcher/VersionCheck.java attempts to launch .debuginfo

Changeset: 70d82f2a6c11 Author:dcubed Date: 2012-04-12 16:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/70d82f2a6c11 7160895: tools/launcher/VersionCheck.java attempts to launch .debuginfo Summary: Do not install .debuginfo files in bin dir. Reviewed-by: ksrini, sspitsyn

RFR [JDK8]: 7160380 Sync JDK8 with JAXP 1.4.5

This is a follow-up update on Kelly's change that dropped the jaxp source drop bundle process. With this update, the jaxp source in JDK8 will be sync-ed with the current JAXP 1.4.5, and also JDK7u (the last change was 7151484). Going forward, we'll follow the process to put any changes into JD

hg: jdk8/tl/jdk: 7067045: replaceAll("\u20ac", "$"); causses java.lang.StringIndexOutOfBoundsExceptio

Changeset: e65a1756d825 Author:sherman Date: 2012-04-12 15:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e65a1756d825 7067045: replaceAll("\u20ac", "$"); causses java.lang.StringIndexOutOfBoundsExceptio Summary: Updated to throw IAE instead. Reviewed-by: lancea ! src/sh

Re: Codereview request 7067045: replaceAll("\u20ac", "$"); causses java.lang.StringIndexOutOfBoundsExceptio

Looks OK to me Best Lance On Apr 12, 2012, at 4:09 PM, Xueming Shen wrote: > Hi > > Please help review the change for 7067045. > > The change is to throw a more meaningful IAE instead of the > StringIndexoutputOfBoundsException > if backslash or $ is the last character in the replacement strin

Codereview request 7067045: replaceAll("\u20ac", "$"); causses java.lang.StringIndexOutOfBoundsExceptio

Hi Please help review the change for 7067045. The change is to throw a more meaningful IAE instead of the StringIndexoutputOfBoundsException if backslash or $ is the last character in the replacement string. (as the API indicated, the backslash and $ character in String's regex replacement and

hg: jdk8/tl/jdk: 7152690: Initialization error with charset SJIS_0213 when security manager is enabled

Changeset: 587243bf0862 Author:sherman Date: 2012-04-12 10:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/587243bf0862 7152690: Initialization error with charset SJIS_0213 when security manager is enabled Summary: To use doPrivileged block to wrap the data reading code Re

hg: jdk8/tl/jdk: 7156873: (zipfs) FileSystems.newFileSystem(uri, env) fails for uri with escaped octets

Changeset: 642c6d4aaaed Author:sherman Date: 2012-04-12 10:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/642c6d4aaaed 7156873: (zipfs) FileSystems.newFileSystem(uri, env) fails for uri with escaped octets Summary: To use URI.getRawSchemeSpecificPart() to get the scheme p

Re: RFR 7116200: (cs) test/java/nio/charset/coders/StreamTimeout.java fails with "Address already in use"

Thanks, guys. I appreciate the feedback (and the welcome Rémi). I'll pick it up from here, update the copyright, double check the formatting, and send it off for final review and submission by Alan or Chris. Thanks again, Jim On 04/12/2012 07:45 AM, Rémi Forax wrote: On 04/12/2012 01:42

Re: Replace the static error string in ZIP_Put_In_Cache0 with on stack memory

Hi Alan, I made a new webrev, added the comments and the 2 other modification. It's now : http://cr.openjdk.java.net/~zhouyx/7159982/webrev.02/ On Thu, Apr 12, 2012 at 4:24 PM, Alan Bateman wrote: > On 12/04/2012 06:40, Sean Chou wrote: > >> Hi Alan, >> >>Many thanks. >> >>I updated

Re: RFR 7116200: (cs) test/java/nio/charset/coders/StreamTimeout.java fails with "Address already in use"

On 04/12/2012 01:42 PM, Alan Bateman wrote: On 11/04/2012 22:51, Rémi Forax wrote: Following the ideas of Alan, I've also removed the unnecessary code, waitABit is not called anymore, and I've inserted a join to be sure that the thread is finished before performing the cleanup. Rémi Thanks

Re: RFR 7116200: (cs) test/java/nio/charset/coders/StreamTimeout.java fails with "Address already in use"

On 11/04/2012 22:51, Rémi Forax wrote: Following the ideas of Alan, I've also removed the unnecessary code, waitABit is not called anymore, and I've inserted a join to be sure that the thread is finished before performing the cleanup. Rémi Thanks Rémi, this looks good. Just some background

Re: Integer.parseInt

+1 to Benedict and Martin -Ulf Am 12.04.2012 11:35, schrieb Martin Desruisseaux: Le 12/04/12 10:57, Benedict Elliott Smith a écrit : I think in this case it is reasonable to leave it to the user to ensure that the input remains consistent for the duration of the call. It can be documented if n

Re: New constructor in sun.tools.java.ClassPath builds a path using File.separator instead of File.pathSeparatorChar

Hi Alan, I choose the test/sun/tools/classpath/ RMICClassPathTest.java because the fix is made in sun.tools.java.ClassPath. However the test case uses BatchEnvironment.createClassPath to create a new ClassPath. I think test/sun/tools/classpath/ is more closer to sun.tools.java.ClassPath. On

Re: Integer.parseInt

Le 12/04/12 10:57, Benedict Elliott Smith a écrit : I think in this case it is reasonable to leave it to the user to ensure that the input remains consistent for the duration of the call. It can be documented if necessary, but as I say I think all imperative methods come with that caveat by defin

Re: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid)

On 12/04/2012 00:48, Rob McKenna wrote: Hi folks, I'm hoping for some feedback on the above. Webrev: http://cr.openjdk.java.net/~robm/4244896/webrev.00/ Thanks for taking this one on, a destroyForcibly is really useful to have (destroy was always misleading given that that is was actually a S

Re: Integer.parseInt

> > Remi and I have in the past had differences of opinion on the utility of > introducing CharSequence versions of such methods. > > One benefit to using a string is that the object is immutable; there are > no time-of-check-versus-time-of-**use conditions to worry about. Robust > code should arg

Re: Codereview request for 7152690: Initialization error with charset SJIS_0213 when security manager is enabled

On 12/04/2012 05:27, Xueming Shen wrote: Hi Please help codereview the change for #7152690 http://cr.openjdk.java.net/~sherman/7152690/webrev This is an overlook when we changed SJIS_0213 implementation in 7. The "resource reading" obviously needs to be wrapped in doPrivileged block. This l

Re: Codereview request 7156873: (zipfs) FileSystems.newFileSystem(uri, env) fails for uri with escaped octets

On 12/04/2012 07:40, Xueming Shen wrote: Hi Please help review the fix for 7156873. It appears URI.getRawSchemeSpecificPart() is the more appropriate method to use to obtain the "scheme", which returns the scheme in its "quoted" form. http://cr.openjdk.java.net/~sherman/7156873/webrev This

Re: New constructor in sun.tools.java.ClassPath builds a path using File.separator instead of File.pathSeparatorChar

On 12/04/2012 08:22, Deven You wrote: I have verified this commit. Thanks Alan and Charles! The change-set that Charles pushed added test/sun/tools/classpath/ RMICClassPathTest.java but I didn't see it in the original webrev. I see now that your original mail had the proposed test in a separat

Re: Replace the static error string in ZIP_Put_In_Cache0 with on stack memory

On 12/04/2012 06:40, Sean Chou wrote: Hi Alan, Many thanks. I updated the patch, ZIP_Open frees the error message and set "Zip file open error". The new webrev is : http://cr.openjdk.java.net/~zhouyx/7159982/webrev.01/

Re: Codereview request 7156873: (zipfs) FileSystems.newFileSystem(uri, env) fails for uri with escaped octets

Looks fine to me Sherman. -Chris. On 12/04/12 07:40, Xueming Shen wrote: Hi Please help review the fix for 7156873. It appears URI.getRawSchemeSpecificPart() is the more appropriate method to use to obtain the "scheme", which returns the scheme in its "quoted" form. http://cr.openjdk.java.net

Re: RFR 7116200: (cs) test/java/nio/charset/coders/StreamTimeout.java fails with "Address already in use"

This is looking much better, thank you. I know it was there already, but I think we should remove the System.exit. It doesn't play well with samevm/agentvm mode. If this is deemed important enough ( and I'm not sure it is ) then a volatile failed/unexpected field may be appropriate, otherwise

Re: New constructor in sun.tools.java.ClassPath builds a path using File.separator instead of File.pathSeparatorChar

I have verified this commit. Thanks Alan and Charles! On 04/12/2012 03:12 PM, Charles Lee wrote: On 04/11/2012 03:44 PM, Deven You wrote: On 04/10/2012 04:12 PM, Alan Bateman wrote: On 09/04/2012 10:32, Deven You wrote: : The issue is reported by one of our test team which maintains a set

Re: New constructor in sun.tools.java.ClassPath builds a path using File.separator instead of File.pathSeparatorChar

On 04/11/2012 03:44 PM, Deven You wrote: On 04/10/2012 04:12 PM, Alan Bateman wrote: On 09/04/2012 10:32, Deven You wrote: : The issue is reported by one of our test team which maintains a set of ORB test cases. Okay but I guess I'm still a bit curious as it's not obvious that rmic (or rmic

hg: jdk8/tl/jdk: 6610897: New constructor in sun.tools.java.ClassPath builds a path using File.separator instead of File.pathSeparator

Changeset: c98a013ec628 Author:youdwei Date: 2012-04-12 15:04 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c98a013ec628 6610897: New constructor in sun.tools.java.ClassPath builds a path using File.separator instead of File.pathSeparator Reviewed-by: alanb ! src/share/cla