compatibility java 4 -> 5

Thread view:

oliv@linuxmail.org - 31 May 2007 14:48 GMT

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

Reply to this Message

Daniel Pitts - 31 May 2007 15:04 GMT

On May 31, 6:48 am, o...@linuxmail.org wrote:

> Hi,
> In which case, a desktop java application working with a sun jre1.4
[quoted text clipped - 3 lines]
>
> 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.

Reply to this Message

Joshua Cranmer - 31 May 2007 22:49 GMT

> On May 31, 6:48 am, o...@linuxmail.org wrote:
>> Hi,
[quoted text clipped - 12 lines]
> 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.

Reply to this Message

Tom Hawtin - 31 May 2007 23:26 GMT

> 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

Reply to this Message

Joshua Cranmer - 01 Jun 2007 03:15 GMT

>> There's more than just new symbols: variable arguments can break a few
>> methods -- Arrays.asList being the most well-known.
[quoted text clipped - 5 lines]
>
> 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.

Reply to this Message

Tom Hawtin - 01 Jun 2007 03:40 GMT

> It compiles, but you might be surprised at the results.
>
[quoted text clipped - 4 lines]
> // 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

Reply to this Message

Oliver Wong - 31 May 2007 15:09 GMT

> 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

Reply to this Message

Mike Schilling - 01 Jun 2007 18:51 GMT

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

Reply to this Message

compatibility java 4 -> 5

Free Magazines