Re: Arithmetic overflow checking

From:

=?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk>

Newsgroups:

comp.lang.java.programmer

Date:

Thu, 21 Jul 2011 17:06:12 -0400

Message-ID:

<4e2894c8$0$309$14726298@news.sunsite.dk>

On 7/20/2011 10:21 PM, Arved Sandstrom wrote:

On 11-07-20 08:50 PM, Arne Vajh?j wrote:

On 7/20/2011 6:36 AM, Arved Sandstrom wrote:

On 11-07-19 10:31 PM, Arne Vajh?j wrote:

On 7/19/2011 9:07 PM, markspace wrote:

On 7/19/2011 5:54 PM, Arne Vajh?j wrote:

On Jul 8, 10:27 am, Gene Wirchenko<ge...@ocis.net> wrote:

Java is designed to behave that way. That does not mean that it
is not wrong.

> On 7/8/2011 4:15 PM, lewbloch wrote:

It doesn't mean that it is wrong.

Yes, but given that there are already two languages under discussion,
then it seems rather obvious that his point is that Java should have
been designed different 16 years ago not change overflow handling
in Java 8.

I think the point being made is that it's behavior that could be
improved *now*.

The prescience required to see 16 years into the future is darn hard. I
don't think anyone at all has that kind of skill or knowledge. It would
have been better however to acknowledge sometime in the past that Java
needed to be improved in some fundamental ways and then make those
changes.

Generics should have been reifiable, primitives should be "first class
objects," integer math should be checked for overflow where the
programmer deems needed. These things have been lacking for some time,
and are still needed, imo.

Today it is a must that changes must not break existing code.

That still leaves some room for improvements.

But it tend to become messy.

Sometimes we just need to realize that a wrong decision was
made, that we are stuck with it and that it should be done
correctly in the next language.

Changes, even backwards-incompatible changes, to version X of a language
do not break existing code *unless* users of that existing code make a
conscious choice to operate that code in the new environment. I am not
convinced there is a strong need to do that.

As an example, and I'm sure I'm not alone in this, I routinely maintain
applications in 2011 that are J2EE 1.4 or Java EE 5. No shortage of them
are J2EE 1.4. Some colleagues who maintain other big web apps I am
familiar with have to deal with Struts 1. The penetration of Java EE 6
applications and Java EE 6 servers into the local big business and
government scene is paltry.

In terms of the associated Java versions, it's true that many folks use
Java 5 or 6 (frequently 1.6 latest update) even if they are developing
for a J2EE 1.4 server, but in my experience there has rarely been a
compelling need for it. To put it another way, I have little time for
someone who argues that they just absolutely need a cool Java 6 language
feature but they can't be bothered to upgrade from J2EE 1.4.

Looking at the Oracle support roadmaps for J2SE/Java SE, fact is that
J2SE 1.4, and Java 5/6, will have some form of adequate support for a
long time yet (http://www.oracle.com/technetwork/java/eol-135779.html).
If Java 8, for example, decided to make some backwards-incompatible
changes to the language, people with existing code bases would have
sufficient options with Java 7 or earlier to keep them happy for a long,
long time. I simply do not see the validity of an argument that says
that the existence of an incompatible Java 8 or 9 is going to affect any
of these people. As it is, I expect not to be primarily working with
Java EE 6 and JDK 7 until 2015 at the earliest...and that may be
optimistic for the Java EE side of things.

It is true that migrating code to new EE and SE versions are usually
a lot behind.

But eventually the code get lifted.

Typical because the vendors stop support for the platform.

And changes that does not create runtime exceptions or compile
time warnings, but silently changes the semantics are about as
bad as they get.

The fact that it may take many years before the problems are felt does
not make the problem smaller.

I should point out that I'm not talking about arithmetic overflow
checking or any other specific feature here. I am quite unconcerned
about arithmetic overflow checking in Java, because I see at least two
better solutions than changing the language: either (1) using a
different language, or (2) being aware of your quantities and actually
putting some thought into your design to avoid overflow. These have been
suggested already.

I'm talking about backwards-incompatible changes in general. There's no
need to worry about "silent changes to semantics", because by definition
you cannot expect your old source to be compatible with this newest
version. You're told that, and you're told why. You can figure out what
you need to change if you intend to upgrade some codebase, compiler
warnings or no compiler warnings.

Talking about Java specifically, SE or EE, there is a great deal of
advance warning. You're typically going to have close to a decade of
warning that you need to make certain modifications, if a version at
some point introduces backwards incompatibilities. This is more than
enough time. Since changes that _are_ backwards incompatible will almost
certainly be important changes that should have been introduced much
earlier anyway, and everyone's code should use them, and it will help
everyone's code, where's the downside in forcing people to do some
necessary work? People certainly do take advantage of new APIs and
language features that _are_ backwards compatible, and they need to put
in a lot of work to do that, so how is it somehow a bad thing that
they've got to do a bit of work to upgrade a codebase into a new

> backwards-incompatible version?

There are usually plenty of warnings.

But that does not make the cost go away.

And cost is bad.

Not wanting to spend 6 or 7 digit dollar amounts verifying that
code still works as original intended does not imply that you may
not want new features.

What percentage of business types do you think care about new language
features and new APIs? 10 percent? 5 percent? One percent? What they
care about is can you develop their latest pet project for them. Since
we devs usually can cobble something together, albeit with difficulty,
even with ancient libraries and old language versions, that's how it
goes in real life.

Let me give you just one example; not so many months ago I had to go
through a lengthy and arduous process with one client, involving much
analysis and multiple meetings, offering assurances all the way up to
Director of IT level, just to bump up an EclipseLink minor version. To
the typical conservative client any upgrade of any library is a Big
Deal. You certainly won't see them clamouring for the speedy adoption of
a new JDK because it offers support for lambdas.

More breaking of existing code will make it even harder to get
permission to upgrade.

It is exactly to get permission to upgrade that the compatibility
is so important.

As for code working as originally intended, show me the production
application that is substantively defect-free and works as originally
intended. About the worst that will happen with an upgrade is that the
typical app will break in new ways.

Sometimes these new breakages are beneficial even. I'm minded of when we
moved a complex J2EE app from one old app server over to a newish one
from another vendor. Suddenly dozens of new defects appeared. Turned out
that all of them were real code defects and that the old app server
simply sucked that bad. My feeling is that forced adoption of better VMs
and better servers and better language features, backwards-incompatible
or no, is generally a good thing - it exposes flaws in codebases. They
didn't get _created_, they were already there.

Most/all code has bugs but migrating to a new runtime with slightly
different semantics will most likely increase the number of bugs
(the old ones will not go away and new will come).

Arne