- For Version 1.0 beans, migrate at least to Version 1.1.
- As stated previously, migration from Version 1.1 to Version 2.x of the EJB specification is not required for redeployment on this version of the product. However, if your application requires the capabilities of Version 2.x, migrate your Version 1.1-compliant code.
Note: The EJB Version 2.0 specification mandates that prior to the EJB container's running a findByMethod query, the state of all enterprise beans enlisted in the current transaction be synchronized with the persistent store. (This is so the query is performed against current data.) If Version 1.1 beans are reassembled into an EJB 2.x-compliant module, the EJB container synchronizes the state of Version 1.1 beans as well as that of Version 2.x beans. As a result, you might notice some change in application behavior even though the application code for the Version 1.1 beans has not been changed.
- Some stub classes for deployed enterprise beans have changed in the Java 2 Software Development Kit, Version 1.4.1.
- The task of generating deployment code for enterprise beans changed significantly for EJB 1.1-compliant modules relative to EJB 1.0-compliant modules.
For detailed information about source and binary compatibility between deployed versions, see Enterprise beans: Resources for learning.
![[Version 6.0.1 and later]](../../v601.gif)
Ensure WebSphere Application Server 32-bit to 64-bit compatibility. For a "pure" Java application this is not an issue. However, if your application code utilizes the Java Native Interface (JNI) code, you should be aware of the following: the JNI allows Java code running in a virtual machine to operate with applications and libraries written in other languages, such as C, C++,
and assembly. So, if your J2EE application uses JNI in a 32-bit environment,
your code must be recompiled in the 64-bit environment. It is possible that the JNI calls could be different after the compilation, as the JNI specifications can change from version to version.