JDK 1.4.1 and 1.4.2 differ in compiling

[Arnab Nandi]

public class Test {
static int returnValue() throws Exception {
while (true) {
try {
break;
} finally {
return 1;
}
}
}

public static void main(String args[]) throws Exception {
System.out.println(returnValue());
}
}

When I compile this in JDK 1.4.1_03, I get this error:-

Test.java:xx: missing return statement
protected static int returnValue() throws Exception {
^
1 error

When I compile this in JDK 1.4.2, I get a warning:-

Test.java:xx: warning: finally clause cannot complete normally
}
^
1 warning

JLS 14.14 says,

The preceding descriptions say "attempts to transfer control" rather
than just "transfers control" because if there are any try statements
(ý14.19) within the break target whose try blocks contain the break
statement, then any finally clauses of those try statements are
executed, in order, innermost to outermost, before control is
transferred to the break target. Abrupt completion of a finally clause
can disrupt the transfer of control initiated by a break statement.

My question is then what? Is it left to the compilers how they
interpret disruption of transfer of control? How can 1.4.2 generate a
class file when its an error for 1.4.1?

Thanks.

Arnab

[Doug Pardee]

ar*********@infy.com (Arnab Nandi) wrote [snipped]:

static int returnValue() throws Exception {
while (true) {
try {
break;
} finally {
return 1;
}
}

When I compile this in JDK 1.4.1_03, I get this error:-

Test.java:xx: missing return statement
protected static int returnValue() throws Exception {
^
1 error
This is incorrect.
When I compile this in JDK 1.4.2, I get a warning:-

Test.java:xx: warning: finally clause cannot complete normally
}
^
1 warning
This is correct. Apparently, there was a bug in 1.4.1 that was fixed
in 1.4.2.
JLS 14.14 says,

The preceding descriptions say "attempts to transfer control" rather
than just "transfers control" because if there are any try statements
(ý14.19) within the break target whose try blocks contain the break
statement, then any finally clauses of those try statements are
executed, in order, innermost to outermost, before control is
transferred to the break target. Abrupt completion of a finally clause
can disrupt the transfer of control initiated by a break statement.

My question is then what? Is it left to the compilers how they
interpret disruption of transfer of control?

Not at all. Java2 Language Spec 14.19.2
(http://java.sun.com/docs/books/jls/s...oc.html#236653)
says, for the case illustrated:
"If execution of the try block completes abruptly for any other
reason R [meaning not a throw], then the finally block is executed.
Then there is a choice:
* If the finally block completes normally, then the try statement
completes abruptly for reason R.
* If the finally block completes abruptly for reason S, then the
try statement completes abruptly for reason S (and reason R is
discarded)."

Since the try block completes abruptly with a break (not a throw), and
the finally block completes abruptly with a return, then the try
statement completes abruptly with the return (reason S), and the break
(reason R) is discarded.

By the way, note that since (in the example given) the finally clause
will always be executed and will always execute the return statement,
it is impossible for that method to throw an exception. (In the
example, the return value is not calculated, and thus cannot throw an
exception).

==========
Now my occasional reminder to those on this newsgroup:

comp.lang.java is not an "official" newsgroup. It was replaced by more
specific newsgroups back in May of 1996. Most people don't see
postings on comp.lang.java, because only a few news servers still
carry it. Google Groups carries it for its historical value, and a few
ISPs (mainly cable-Internet providers) seem to carry it out of
ignorance :-)

The current worldwide Java newsgroups are:

comp.lang.java.3d 3D Graphics API's for the Java language
comp.lang.java.advocacy Support for and criticism of the Java System
comp.lang.java.announce Announcements re the Java System (Moderated)
comp.lang.java.beans Java software components (JavaBeans)
comp.lang.java.corba Topics relating to Java and CORBA
comp.lang.java.databases Databases, java.sql, JDBC, ODBC
comp.lang.java.gui GUI toolkits and windowing: AWT, IFC etc
comp.lang.java.help Set-up problems, catch-all first aid
comp.lang.java.machine JVM, native methods, hardware
comp.lang.java.programmer Programming in the Java language
comp.lang.java.security Security issues raised by Java