Oops! Integer.compare

[Roedy Green]

I was doing some subtraction in sort Comparators, when I noticed a
method Integer.compare that would handle the nice cases properly.

I thought to myself, I wonder why I never noticed that before. (Turns
out it was introduced in 1.7).

The catch was though that Jet stopped working.

Why?

Jet only supports up to Java 1.6.

When I compile with switches to generate Java 1.6 code, it is happy to
use new 1.7 code from the library. It then generates class files and
jars marked as legit 1.6 code. Ouch!

The official way to do this is to find old rt.jars to generate old
code. Is that the best way to catch these errors?
--
Roedy Green Canadian Mind Products
http://mindprod.com
I would be quite surprised if the NSA (National Security Agency)
did not have a computer program to scan bits of shredded
documents and electronically put them back together like a giant
jigsaw puzzle. This suggests you cannot just shred, you must also burn.
..

 

[Lew]

I was doing some subtraction in sort Comparators, when I noticed a
method Integer.compare that would handle the nice cases properly.

I thought to myself, I wonder why I never noticed that before. (Turns
out it was introduced in 1.7).

The catch was though that Jet stopped working.

Why?

Jet only supports up to Java 1.6.

When I compile with switches to generate Java 1.6 code, it is happy to
use new 1.7 code from the library. It then generates class files and
jars marked as legit 1.6 code. Ouch!

The official way to do this is to find old rt.jars to generate old
code. Is that the best way to catch these errors?

Yes. You use Java 6 boot JARs in the "-bootclasspath" argument to "javac".

 

[Owen Jacobson]

I was doing some subtraction in sort Comparators, when I noticed a
method Integer.compare that would handle the nice cases properly.

I thought to myself, I wonder why I never noticed that before. (Turns
out it was introduced in 1.7).

The catch was though that Jet stopped working.

Why?

Jet only supports up to Java 1.6.

When I compile with switches to generate Java 1.6 code, it is happy to
use new 1.7 code from the library. It then generates class files and
jars marked as legit 1.6 code. Ouch!

The official way to do this is to find old rt.jars to generate old
code. Is that the best way to catch these errors?

It's usually easier to keep a complete JDK installation around for the
oldest runtime version you want to support, and compile your code with
that JDK. That takes care of language and bytecode compatibility (the
default -source and -target versions for a given version of the JDK are
exactly the version of the JDK itself) as well as library compatibility
(the JDK uses its version's runtime library to find symbols by default).

Sun, and now Oracle, try fairly hard to ensure forward source and
binary compatibility, so you can still run your compiled code on newer
runtimes if you like.

-o