EJB Programming Restrictions

1. Using static, nonfinal fields. Declaring all static fields in the EJB component as final is recommended. That ensures consistent runtime semantics so that EJB containers have the flexibility to distribute instances across multiple JVMs.
2. Using thread synchronization primitives to synchronize multiple instance execution. By avoiding that feature, you allow the EJB container flexibility to distribute instances across multiple JVMs.
3. Using AWT functionality for keyboard input/display output. That restriction exists because server-side business components are meant to provide business functionality that excludes user interface and keyboard I/O functionality.
4. Using file access/java.io operations. EJB business components are meant to use resource managers such as JDBC to store and retrieve application data rather than the file system APIs. Also, deployment tools provide the facility for storing environment entry elements (env-entry) into the deployment descriptor, so that EJB components can perform environment entry lookups in a standardized manner via the environment-naming context. Thus, the need to use file system-based property files is mostly eliminated.
5. Listening to or accepting socket connections, or using a socket for multicast. EJB components are not meant to provide network socket server functionality; however, the architecture lets EJB components act as a socket client or RMI clients and thus communicate with code outside the container's managed environment.
6. Using the Reflection API to query classes that are not otherwise accessible to the EJB component due to Java's security rules. That restriction enforces Java platform security.
7. Attempting to create or obtain a class loader, set or create a new security manager, stop the JVM, change the input, output, and error streams. That restriction enforces security and maintains the EJB container's ability to manage the runtime environment.
8. Setting the socket factory used by the URL's ServerSocket, Socket, or stream handler. By avoiding that feature, you also enforce security and maintain the EJB container's ability to manage the runtime environment.
9. Starting, stopping, or managing threads in any way. That restriction eliminates the possibility of conflicts with the EJB container's responsibilities of managing locking, threading, and concurrency issues.
10. By restricting your use of features 10-16, you aim to plug potential security holes:
11. Reading or writing a file descriptor directly.
12. Obtaining security policy information for a particular code source.
13. Loading native libraries.
14. Accessing packages and classes that the usual rules of Java make unavailable.
15. Defining a class in a package.
16. Accessing or modifying security configuration objects (Policy, Security, Provider, Signer, and Identity).
17. Using the subclass and object substitution features of the Java Serialization protocol.
18. Passing the this reference as an argument or returning the this reference as a result. Instead, you must use the result of the getEJBObject() available in SessionContext or EntityContext.