Review: JDK 8 CR for Support Integer overflow updated

[Jeff Hain]

>Saturating arithmetic can be useful but there have been few requests.

Some needs can be unformulated until someone fulfils them :)
But indeed not being hit by integer/modulo arithmetic while still being exact
is surely a more common need than "jumping" to the closest value.
I must be biased due to mostly using the later.


>Choosing names can be difficult to get the right meaning. I don't
    see these are an improvement.

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 "xxxExact".
But if such methods shall never be added, it's all right.


>In your subsequent email, I found that the asXXX and toXXX variants
    to be too similar to
>make it clear which throws and which does not or other differences
    unless it were a pervasive
>pattern that all developers would know and use.

I had in mind that "as" contained an idea of identity, and "to" an idea of movement/change,
so that "asInt" implies that the value does not change (throws if out of range) and "toInt"
that it could change, but maybe that's only true in my (too low) english :)


>Interesting, my impression from some trials was the Hotspot already
    had some speedup for abs().

Hotspot doesn't seem to always use its speedup then, or it's not as good,
or it (or my CPU) has even better speedups for bits shifts :)


Jeff

PS: About JodaTime I said "if the maintainer reads this": I had in mind it was someone used to this list, but of course it's Stephen :)