Re: Arithmetic overflow checking
RedGrittyBrick wrote:
lewbloch wrote:
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 ha=
ve
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".
It's a fair cop.
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?
Sure. I present the obstacles not as stoppers but as things for which
the designer(s) of such a change must be responsible.
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).
Yes, and they would have to. The issue is with the statement that
"Java should have feature /X/" without any concept of the challenges
that must be addressed.
If the challenges are too expensive to overcome, or lack sufficient
widespread utility, or are too foreign to the ethos of the language,
then it might be best to reject the feature even if there does exist a
good use case for it somewhere.
Patricia and Arved, among others, have made the point that focusing on
changes to Java when there are suitable alternative languages (that
even run on the JVM!) is not always optimal. Why change Java if
Javascript or Ruby or Scala can do the job for you right now?
And what about the suggestion to write a CheckedInteger type that does
what you need? You can get what you need without waiting for some
potential future revolution in Java, and without leaving the
comforting security of your favorite language.
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.
That's not my claim. My claim is that you just can't do this
irresponsibly lest you break existing code. I also believe that
others' suggestions in this thread can solve the problem immediately
without requiring Draconian and slow-to-arrive changes in the
language.
Despite the above, I'm in favour of keeping the language relatively simpl=
e.
That's especially valid given that the language supports the desired
functionality as long as you're willing to be a programmer and write
the necessary code. I especially endorse Arved's comment:
Why are you wanting to rely on overflow detection to
save your program when 99 percent of the possible legal values for your
chosen data type are also wrong for the design problem, and you're
obviously not concerned about that at all? Why don't you write a proper
class for your data type?
--
Lew