Java is striving to be backward compatible. (It is to such an extent that it crippled its generics for that).
But are there situations when old code would not compile on newer versions (more importantly Java 5, and the forthcoming Java 7)
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Java is striving to be backward compatible. (It is to such an extent that it crippled its generics for that).
But are there situations when old code would not compile on newer versions (more importantly Java 5, and the forthcoming Java 7)
There seem to be quite a few of them actually – well, not all of them result in a compilation error but this is the official word from sun: http://java.sun.com/j2se/JM_White_Paper_R6A.pdf
I typically use these checks:
Prior to 1.4, URLConnection.getInputStream threw a FileNotFoundException if the file type was known and the response code was greater than or equal to 400. Otherwise no exception would be thrown
HttpURLConnection.getErrorStream can be used to read the error page returned from the server.Prior to 1.4, getErrorStream() always returned null.
New methods have been added to the DOM interfaces, so some existing applications will not be able to compile with the new interfaces.
ErrorHandler, EntityResolver, ContentHandler, and DTDHandler can now be set to null by applications. SAX 2.0 required the XML processor to throw java.lang.NullPointerException in this case. (The JAXP parser implemented in 5.0, like most implementations, reacts to null by using the default settings.)
The resolveEntity method in DefaultHandler and the EntityResolver subclass throws IOException and SAXException. Previously it threw only SAXException.
In SAX 2.0.1, an application can set ErrorHandler, EntityResolver, ContentHandler, or DTDHandler to null. This is a relaxation of the previous restriction in SAX 2.0, which generated a NullPointerException (NPE) in such circumstances.
As of 5.0, XSLTC is the default transformer, XSLTC does not support all the extensions that Xalan does. These extensions are beyond the definition of the JAXP and XSLT specifications.
In 5.0, the org.apache classes, have moved in 5.0 to com.sun.org.apache.package.internal so that they won’t clash with more recent, developer-downloaded versions of the classes.
A BigDecimal method changed its behavior between 1.4 and 5.0, causing JDBC drivers to malfunction.
As of 5.0, comparing a java.sql.Timestamp to a java.util.Date by invoking compareTo on the Timestamp results in a ClassCastException.
The java.net.Proxy class was added in 5.0, making two classes named Proxy:
(java.lang.reflect.Proxy,java.net.Proxy)
The following words were added to the Java language between 1.3 and 5.0, so they are no longer available for use as field or method identifiers:[assert (added in 1.4),enum]