Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #14796 > unrolled thread

Oops! Integer.compare

Back to article view | Back to comp.lang.java.programmer

Contents

  Oops! Integer.compare Roedy Green <see_website@mindprod.com.invalid> - 2012-05-25 12:00 -0700
    Re: Oops! Integer.compare Lew <lewbloch@gmail.com> - 2012-05-25 13:23 -0700
    Re: Oops! Integer.compare Owen Jacobson <angrybaldguy@gmail.com> - 2012-05-29 20:18 -0400

#14796 — Oops! Integer.compare

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.
.

[toc] | [next] | [standalone]

#14798

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".

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#14928

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 
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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web