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.