Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!feeder.news-service.com!tudelft.nl!txtfeed1.tudelft.nl!dedekind.zen.co.uk!zen.net.uk!hamilton.zen.co.uk!shaftesbury.zen.co.uk.POSTED!not-for-mail Date: Thu, 21 Jul 2011 12:11:55 +0100 From: RedGrittyBrick User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 Newsgroups: comp.lang.java.programmer Subject: Re: Arithmetic overflow checking References: <015aeb15-57db-48ab-9cd4-77f8448b632f@w24g2000yqw.googlegroups.com> <1f9c17dltrhlmhifuigoa914477r4rg1e1@4ax.com> <09fe171s46ilvq9qmn254dctunm6noh0ps@4ax.com> <4e262731$0$314$14726298@news.sunsite.dk> <4e26300b$0$309$14726298@news.sunsite.dk> <4e26b4ed$0$2501$db0fefd9@news.zen.co.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Lines: 65 Message-ID: <4e28097f$0$2533$da0feed9@news.zen.co.uk> Organization: Zen Internet NNTP-Posting-Host: 975e39c6.news.zen.co.uk X-Trace: DXC=ZEQi;UfnZY`iecb`[XPR_jnok4Z\ RedGrittyBrick wrote: >> Arved Sandstrom wrote: >>> Holding back from certain language changes just so someone can >>> compile a codebase written against Java 5 on a Java 9 compiler, and have >>> it work, is holding back the entire language. >> >> Why is this a problem? >> >> Firstly, you can use `javac -source 1.3` to compile old code, can't you? >> > > No. Not if you want some of the new features. [...] > > You also have to make sure that all your third-party libraries for > that build conform to the older spec. > > Targeting an old version is an all-or-nothing proposition. > All good points but I feel your "No." is more like a "Yes, but". If everyone at Oracle went mad and Java 1.9 changed the language spec so that integer arithmetic could throw an IntegerOverflowException, presumably they could arrange things in the compiler (and JVM) so that the `-source 1.5` option would compile the code such that integer operations would never throw an IntegerOverflowException thus satisfying Arved's objection - couldn't they? >> Secondly, a future version of Java could introduce some mechanism such >> as in-line compiler directives that turn new >> compiler-behaviours/language-features on for specified classes or for >> specified sections of code (I'm thinking of Perl's `use feature` pragma >> but I'm sure this sort of idea exists in other languages). >> > > It'll come down to someone's perception of how valuable that feature > is against the cost. Sure (assuming you're talking about the cost of adding that feature to javac and JVM etc), I'm speaking hypothetically. @IntegerOverflowExceptions(true) int c = a + b; @IntegerOverflowExceptions(false) It looks horrid to me, and presumably there's lots of issues to overcome, better syntax to achieve the same ends, but essentially, if Sunacle felt it worthwhile, something could be done to introduce new behaviours whilst making them optional for existing code that those behaviours would break? Whilst I personally (think I) have no need for arithmetic overflow checking of this sort, I imagine some clever language designers could provide for it in a way that didn't break existing crypto libraries that rely on such overflows being ignored. Perhaps I'm wrong, but people seem to be saying "you just can't do this because it would break existing code" - I haven't grasped why those people are sure this is the case. Despite the above, I'm in favour of keeping the language relatively simple. -- RGB