Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!nx02.iad01.newshosting.com!newshosting.com!69.16.185.11.MISMATCH!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!postnews.google.com!m5g2000prh.googlegroups.com!not-for-mail From: lewbloch Newsgroups: comp.lang.java.programmer Subject: Re: Arithmetic overflow checking Date: Wed, 20 Jul 2011 09:51:33 -0700 (PDT) Organization: http://groups.google.com Lines: 35 Message-ID: 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> NNTP-Posting-Host: 216.239.45.16 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: posting.google.com 1311181474 6996 127.0.0.1 (20 Jul 2011 17:04:34 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 20 Jul 2011 17:04:34 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: m5g2000prh.googlegroups.com; posting-host=216.239.45.16; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: ASELCHRU X-HTTP-UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.56 Safari/535.1,gzip(gfe) Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:6311 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. For example, if you're developing to Java 6 and want to keep generics but don't want autoboxing, you cannot use '-source 1.3 -target 1.3'. So, if you have a library that breaks with Java 5 or later, such as commons-lang enumerations under rare situations, you cannot accommodate that simply by 'source 1.4'ing it without giving up other desirable 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. > 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. -- Lew