On Mon, 2005-06-13 at 13:08 +1000, Brett Porter wrote:
> Hi Hans,
>
> This is exactly what I meant. Thanks for confirming that it has worked
> this time on JDK 1.3. The question I'm still uncertain of is whether it
> is possible that JDK 1.5, with -target 1.3 but it's own rt.jar, would
> ever generate bytecode that won't work on 1.3, even if the source itself
> would have compiled as is on 1.3. I can't think of such a case, but
> Stephen raised it as a potential issue and I'm hoping he can clarify if
> that's what he meant with an example.
Here's one theoretical problem.
java 1.3:
class String {...}
class PrintStream {
public void println(String s) {...}
}
java 1.5:
class String implements CharSequence {...}
class PrintStream {
public void println(String s) {...}
// nb: this method doesn't actually exist
public void println(CharSequence s) {...}
}
User Code:
class HelloWorld {
....
String s = new String("Hello, world");
System.out.println(s);
}
When compiling under 1.3, the HelloWorld.class file will definitely have
a call to PrintStream.println(String).
When compiling under 1.5, the HelloWorld.class file might end up
containing a call to PrintStream.println(CharSequence).
Thus the source compiles and runs under 1.3. But when compiled under 1.5
it fails to run under 1.3 because "PrintStream.println(CharSequence)"
doesn't exist.
I think it's fairly unlikely. However it's possible as resolving calls
to overloaded methods is done at compile time; the .class file contains
a reference to a method with a specific signature so that the linking
process doesn't need to go around computing the best signature match
etc.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
