Sun Java System Application Server Platform Edition 8.1 2005Q2 Update 2 Upgrade and Migration Guide

- Previous: Source Compatibility
- Next: JAXP and SAX Incompatibilities

# Incompatibilities in the J2EE 1.4 Platform (since the J2EE 1.3 release)

The Sun Java System Application Server 8.1 release is based on the Java 2 Platform, Enterprise Edition, version 1.4. The Sun Java System Application Server 7 release is based on the Java 2 Platform, Enterprise Edition, version 1.3.

The Sun Java System Application Server 8.1 release is strongly compatible with previous versions of the J2EE platform. Almost all existing programs should run on the Sun Java System Application Server 8.1 release without modification. However, there are some minor potential incompatibilities that involve rare circumstances and corner cases that we are documenting here for completeness.

- Java Servlet Specification Version 2.4 ships with the Sun Java System Application Server 8.1 release, and can be downloaded from the following URL:

  http://java.sun.com/products/servlet/

  Version 2.3 of the specification shipped with the J2EE 1.3 SDK. The following items discuss compatibility issues between these releases.

  - `HttpSessionListener` sessionDestroyed method was previously used to notify that a session was invalidated. As of this release, this method is used to notify that a session is about to be invalidated so that it notifies before the session invalidation. If the code assumed the previous behavior, it must be modified to match the new behavior.

  - `ServletRequest` methods `getRemotePort`, `getLocalName`, `getLocalAddr`, `getLocalPort`

    The following methods are added in the `ServletRequest` interface in this version of the specification. Be aware that this addition causes source incompatibility in some cases, such as when a developer implements the `ServletRequest` interface. In this case, ensure that all the new methods are implemented:

    - public int getRemotePort() returns the Internet Protocol (IP) source port of the client or last proxy that sent the request.

    - public java.lang.String getLocalName() returns the host name of the Internet Protocol (IP) interface on which the request was received.

    - public java.lang.String getLocalAddr() returns the Internet Protocol (IP) address of the interface on which the request was received.

    - public int getLocalPort() returns the Internet Protocol (IP) port number of the interface on which the request was received.

    JavaServer Pages Specification 2.0 ships with the Sun Java System Application Server 8.1 release and is downloadable from the following URL:

    http://java.sun.com/products/jsp/

    JSP Specification 1.2 shipped with the J2EE 1.3 SDK. Where possible, the JSP 2.0 Specification attempts to be fully backward compatible with the JSP 1.2 Specification. In some cases, there are ambiguities in the JSP 1.2 specification that have been clarified in the JSP 2.0 Specification. Because some JSP 1.2 containers behave differently, some applications that rely on container-specific behavior may need to be adjusted to work correctly in a JSP 2.0 environment.

    The following is a list of known backward compatibility issues of which developers who use JSP technology should be aware:

  - Tag Library validators that are not namespace aware and that rely solely on the prefix parameter might not correctly validate some JSP 2.0 pages. This is because the XML view might contain tag library declarations in elements other than `jsp:root`, and might contain the same tag library declaration more than once, using different prefixes. The uri parameter should always be used by tag library validators instead. Existing JSP pages with existing tag libraries do not create any problems.

  - Users may observe differences in I18N behavior on some containers due primarily to ambiguity in the JSP 1.2 specification. Where possible, steps were taken to minimize the impact on backward compatibility and overall, the I18N abilities of technology have been greatly improved.

    In JSP specification versions previous to JSP 2.0, JSP pages in XML syntax (“JSP documents”) and those in standard syntax determined their page encoding in the same fashion, by examining the `pageEncoding` or `contentType` attributes of their page directive, defaulting to ISO-8859-1 if neither was present.

    As of the JSP Specification v2.0, the page encoding for JSP documents is determined as described in section 4.3.3 and appendix F.1 of the XML specification, and the pageEncoding attribute of those pages is only checked to make sure it is consistent with the page encoding determined as per the XML specification.

    As a result of this change, JSP documents that rely on their page encoding to be determined from their pageEncoding attribute will no longer be decoded correctly. These JSP documents must be changed to include an appropriate XML encoding declaration.

    Additionally, in the JSP 1.2 Specification, page encodings are determined on a per translation unit basis whereas in the JSP 2.0 Specification, page encodings are determined on a per-file basis. Therefore, if a.jsp statically includes b.jsp, and a page encoding is specified in a.jsp but not in b.jsp, in the JSP 1.2 Specification a.jsp’s encoding is used for b.jsp, but in the JSP 2.0 Specification, the default encoding is used for b.jsp.

  - The type coercion rules (shown in Table JSP.1-11 in the JSP 2.0 Specification) have been reconciled with the EL coercion rules. There are some exceptional conditions that no longer result in an exception in the JSP 2.0 Specification. In particular, when passing an empty String to an attribute of a numeric type, a translation error or a `NumberFormatException` used to occur, whereas in the JSP 2.0 Specification, a 0 is passed in instead. See Table JSP.1-11 in the JSP 2.0 Specification for details. In general, this is not expected to cause any problems because these would have been exceptional conditions in the JSP 1.2 Specification and the specification allowed for these exceptions to occur at either translation time or request time.

  - The JSP container uses the version of web.xml to determine the default behavior of various container features. The following is a list of items of which JSP developers should be aware when upgrading their `web.xml` file from Servlet version 2.3 Specification to Servlet version 2.4 Specification.

    - EL expressions are ignored by default in applications created with JSP 1.2 technology. When upgrading a Web application to the JSP 2.0 Specification, EL expressions are interpreted by default. The escape sequence \\$ can be used to escape EL expressions that should not be interpreted by the container. Alternatively, the isELIgnored page directive attribute, or the el-ignored configuration element can deactivate EL for entire translation units. Users of JSTL 1.0 need to either upgrade their taglib/ imports to the JSTL 1.1 URIs, or they need to use the _rt versions of the tags (for example c_rt instead of c, or fmt_rt instead of fmt).

    - Files with an extension of .jspx are interpreted as JSP documents by default. Use the JSP configuration element is-xml to treat .jspx files as regular JSP pages. There is no way to disassociate .jspx from the JSP container.

    - The escape sequence \\$ was not reserved in the JSP 1.2 Specification. Any template text or attribute value that appeared as \\$ in the JSP 1.2 Specification used to output \\$ but now outputs just $.

- Previous: Source Compatibility
- Next: JAXP and SAX Incompatibilities

- © 2010, Oracle Corporation and/or its affiliates