Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Oops! Integer.compare
29 views
Skip to first unread message
Roedy Green
May 25, 2012, 3:00:28 PM5/25/12
to
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.
.
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
May 25, 2012, 4:23:41 PM5/25/12
to
Roedy Green wrote:
> 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".
> 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?
--
Lew
Owen Jacobson
May 29, 2012, 8:18:48 PM5/29/12
to
On 2012-05-25 19:00:28 +0000, Roedy Green said:
> 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
> 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?
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
0 new messages