hg: jdk8/tl/jdk: 4153167: separate between ANSI and OEM code pages on Windows

Changeset: d38fed7d2ea7 Author:sherman Date: 2012-02-16 22:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d38fed7d2ea7 4153167: separate between ANSI and OEM code pages on Windows Summary: To use OEM code page for System.out&err when not redirected Reviewed-by: alanb ! sr

Re: cost of Java "assert" when disabled?

On 17/02/2012 9:40 AM, Vitaly Davidovich wrote: The asserts can be enabled/disabled at startup time, but I don't consider that an advantage over conditional compilation. In fact, it's less convenient in some cases, e.g. you can't conditionally add/remove class fields, can't surround blocks of co

Re: cost of Java "assert" when disabled?

Thanks to all for the prompt and enlightening discussion, and especially to David for the succinct summary. -- ramki On Thu, Feb 16, 2012 at 3:15 PM, David Holmes wrote: > The corelibs side of things seems to have gotten dropped from the cc list > - added back. > > > On 17/02/2012 8:21 AM, Vital

Re: cost of Java "assert" when disabled?

The asserts can be enabled/disabled at startup time, but I don't consider that an advantage over conditional compilation. In fact, it's less convenient in some cases, e.g. you can't conditionally add/remove class fields, can't surround blocks of code with condition, etc. There are workarounds, bu

Re: cost of Java "assert" when disabled?

The corelibs side of things seems to have gotten dropped from the cc list - added back. On 17/02/2012 8:21 AM, Vitaly Davidovich wrote: Don't want to sidetrack this thread but I really wish javac had proper conditional compilation support, which would make this issue mostly moot. But the whol

Re: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows

On 16/02/2012 20:18, Xueming Shen wrote: Thanks Alan, webrev has been updated accordingly. http://cr.openjdk.java.net/~sherman/4153167/webrev -Sherman This looks reasonable to me, will be interesting to see if anyone notices. -Alan.

cost of Java "assert" when disabled?

A Java language newbie question: Does anyone have any ballpark numbers on the cost (and its scaling) of peppering assert's in your Java code, but with asserts disabled (-da) ? In other words, is the disabled cost so vanishingly small that we need not think twice when using them, or should one be c

Re: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows

Thanks Alan, webrev has been updated accordingly. http://cr.openjdk.java.net/~sherman/4153167/webrev -Sherman On 02/15/2012 07:00 AM, Alan Bateman wrote: On 13/02/2012 17:36, Xueming Shen wrote: : The webrev is at http://cr.openjdk.

hg: jdk8/tl/jdk: 6708398: Support integer overflow

Changeset: b971b51bec01 Author:sherman Date: 2012-02-16 11:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b971b51bec01 6708398: Support integer overflow Summary: Added add/sub/multiply/toIntExact methods to j.l.Math and StrictMath classes Reviewed-by: emcmanus Contributed

Re: Review: JDK 8 CR for Support Integer overflow updated

Reviewed-by: emcmanus Éamonn On 16 February 2012 08:23, Xueming Shen wrote: > I can do the commit. > > > On 2/16/2012 8:09 AM, Roger Riggs wrote: >> >> I don't anticipate making any more changes though a few of the >> comments deserve followup as a separate CR. >> >> Is there an OpenJDK commit

Re: Review: JDK 8 CR for Support Integer overflow updated

I can do the commit. On 2/16/2012 8:09 AM, Roger Riggs wrote: I don't anticipate making any more changes though a few of the comments deserve followup as a separate CR. Is there an OpenJDK committer who would commit? Thanks, Roger Updated the webrev for CR6708398: http://cr.openjdk.

Re: Review: JDK 8 CR for Support Integer overflow updated

I don't anticipate making any more changes though a few of the comments deserve followup as a separate CR. Is there an OpenJDK committer who would commit? Thanks, Roger Updated the webrev for CR6708398: http://cr.openjdk.java.net/~rriggs/6708398.2

Re: Re : Re : Review: JDK 8 CR for Support Integer overflow updated

On 02/14/2012 05:20 PM, Jeff Hain wrote: Indeed "exact" can be understood as "mathematically exact", and it's concise. The main problem I see with "exact" is if wanting to add some non-throwing version afterwards: it should have a close but different name, and I don't see how if using "xxxExac

Re: java.io.File field "path" is not declared final

On 15/02/2012 17:34, Rémi Forax wrote: Reported by a user on the concurrency-interest mailing list, File field "path" is not declared final but should be. Thanks for forwarding Rémi. I did reply on concurrency-interest but I forgot that my original subscription there was @sun.com. I've created