EJB Programming Restrictions

The EJB specification imposes some restrictions on the Bean Provider (Application programmer) to ensure portability. Although these restrictions do not affect the programmer in most cases, it has some implications in certain situations such as when using the Singleton pattern. Hence, it is advised that the EJB programmer be aware of these programming restrictions while coding EJBs. The following is a list of the restrictions (an excerpt from the EJB Specification), and the implications on the singleton pattern implementation under the EJB environment will be described in the next post. These restrictions are consistent between EJB 2.1 and EJB 3.0 specifications.

On usage of Static fields
1. An enterprise bean must not use read/write static fields. Using read-only static fields is allowed. Therefore, it is recommended that all static fields in the enterprise bean class be declared as final.
   
On using Threads
2. An enterprise bean must not use thread synchronization primitives to synchronize execution of multiple instances.
   
3. The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread, or to change a thread’s priority or name. The enterprise bean must not attempt to manage thread groups.
Java Standard API
4. An enterprise bean must not use the AWT functionality to attempt to output information to a display, or to input information from a keyboard.
5. An enterprise bean must not use the java.io package to attempt to access files and directories in the file system.
6. An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or use a socket for multicast.
On Security
7. The enterprise bean must not attempt to query a class to obtain information about the declared members that are not otherwise accessible to the enterprise bean because of the security rules of the Java language. The enterprise bean must not attempt to use the Reflection API to access information that the security rules of the Java programming language make unavailable.
8. The enterprise bean must not attempt to create a class loader; obtain the current class loader; set the context class loader; set security manager; create a new security manager; stop the JVM; or change the input, output, and error streams.
9. The enterprise bean must not attempt to set the socket factory used by ServerSocket, Socket, or the stream handler factory used by URL.
10. The enterprise bean must not attempt to directly read or write a file descriptor.
11. The enterprise bean must not attempt to obtain the security policy information for a particular code source.
    
12. The enterprise bean must not attempt to load a native library.
    
13. The enterprise bean must not attempt to gain access to packages and classes that the usual rules of the Java programming language make unavailable to the enterprise bean.
14. The enterprise bean must not attempt to define a class in a package.
15. The enterprise bean must not attempt to access or modify the security configuration objects (Policy, Security, Provider, Signer, and Identity).
16. The enterprise bean must not attempt to use the subclass and object substitution features of the Java Serialization Protocol.
17. The enterprise bean must not attempt to pass this as an argument or method result. The enterprise bean must pass the result of SessionContext.getEJBObject, Session- Context.getEJBLocalObject, EntityContext.getEJBObject, or Entity- Context.getEJBLocalObject instead.