compatibility java 4 -> 5

[oliv]

Hi,
In which case, a desktop java application working with a sun jre1.4
could not work with a sun jre 5 ?
I thought Sun guaranteed that compatibility (adds deprecated method
but not remove anything..)

thanks

 

[Daniel Pitts]

Hi,
In which case, a desktop java application working with a sun jre1.4
could not work with a sun jre 5 ?
I thought Sun guaranteed that compatibility (adds deprecated method
but not remove anything..)

thanks

A compiled Java 4 class SHOULD be compatible with Java 5 (byte-code
compatibility). This does not guaranty that there haven't been any
bugs introduced between versions.

Also, source code isn't necessarily compatible. Java 5 has added a few
keywords, and if those keywords were used as symbols in the Java 1.4
code, you'll get a compiler error.

 

[Oliver Wong]

Hi,
In which case, a desktop java application working with a sun jre1.4
could not work with a sun jre 5 ?
I thought Sun guaranteed that compatibility (adds deprecated method
but not remove anything..)

I believe the JVMs always have class file compatibility (that is, a
newer JVM can always correctly read from a class file intended for an
older JVM). The source compatibility is strived for, but not guaranteed,
as Sun sometimes add new keywords (such as "assert" or "enum"). Weaker
still is the API compatibility. The class library functionality may change
as errors and bugs are fixed. If your program depended on buggy behaviour
to work correctly, it may no longer work in future versions.

For the exact list of changes, see:
http://java.sun.com/j2se/1.5.0/compatibility.html

- Oliver

 

[Joshua Cranmer]

A compiled Java 4 class SHOULD be compatible with Java 5 (byte-code
compatibility). This does not guaranty that there haven't been any
bugs introduced between versions.

Also, source code isn't necessarily compatible. Java 5 has added a few
keywords, and if those keywords were used as symbols in the Java 1.4
code, you'll get a compiler error.

There's more than just new symbols: variable arguments can break a few
methods -- Arrays.asList being the most well-known.

 

[Tom Hawtin]

There's more than just new symbols: variable arguments can break a few
methods -- Arrays.asList being the most well-known.

Does it actually break anything? My recollection was that all old code
would work, but may produce a warning. New code may well have bugs (like
passing an int[] and expecting a List<int> or List<Integer> instead of
List<int[]>).

Tom Hawtin

 

[Joshua Cranmer]

There's more than just new symbols: variable arguments can break a few
methods -- Arrays.asList being the most well-known.

Does it actually break anything? My recollection was that all old code
would work, but may produce a warning. New code may well have bugs (like
passing an int[] and expecting a List<int> or List<Integer> instead of
List<int[]>).

Tom Hawtin

It compiles, but you might be surprised at the results.

List x = Arrays.asList(new Integer[] {new Integer(1), new Integer(2),new
Integer(3)});
System.out.println(x.get(0));

// 1.4- output: 1
// 1.5+ output: [Ljava/lang/Integer;@#######

The combination of generics and variable arguments throws off the compiler.

 

[Tom Hawtin]

It compiles, but you might be surprised at the results.

List x = Arrays.asList(new Integer[] {new Integer(1), new Integer(2),new
Integer(3)});
System.out.println(x.get(0));

// 1.4- output: 1
// 1.5+ output: [Ljava/lang/Integer;@#######

I am *very* surprised at those results.

import java.util.*;

class AsList {
public static void main(String[] args) {
List x = Arrays.asList(new Integer[] {
new Integer(1), new Integer(2),new Integer(3)
});
System.out.println(x.get(0));
}
}

Prints "1" for me.

The combination of generics and variable arguments throws off the compiler.

Is it really anything to do with generics. Isn't the behaviour the same
if you called a method that took had a fixed Integer... parameter? It
gets more dogdy with the likes of Object..., because Object[] is an Object.

Tom Hawtin

 

[Mike Schilling]

I believe the JVMs always have class file compatibility (that is, a
newer JVM can always correctly read from a class file intended for an
older JVM). The source compatibility is strived for, but not
guaranteed, as Sun sometimes add new keywords (such as "assert" or
"enum"). Weaker still is the API compatibility. The class library
functionality may change as errors and bugs are fixed.

And introduced.