Taken from the "Enterprise JavaBeans TM Specification, Version 2.1"
In section 25.1.2 it has the following. -------------------------------------------- � The enterprise bean must not attempt to load a native library. This function is reserved for the EJB Container. Allowing the enterprise bean to load native code would create a security hole. -------------------------------------------- This is my take on this. 1. An EJB must not load a native library. 2. An EJB Container can load a native library. 3. Code in a JVM which is not part of the Container and is not referenced by an EJB can load a native library. 4. An EJB can call a JNI method. The last point is the specific point of my question. My opinion is that, from reading the spec, that it specifically allows for the use of JNI in an EJB or at least does not dis-allow it. =================================== The following is a summation of the most common arguments which refute the above. +++ A. You shouldn't use JNI in an EJB because it is non-portable. Response. This has nothing to do with this discussion. The point is not whether it is portable but where it is allowed. (This argument is redundant as well since by definition using JNI is already non-portable.) +++ B. You shouldn't use JNI because Corba/RMI/Something is better. Response. That has nothing to do with this discussion. The point is not whether there is a better way but whether it is allowed. +++ C. You shouldn't use JNI because it is dangerous/ill-advised/etc. Response. That has nothing to do with this discussion. The point is not whether there are pitfalls but whether it is allowed. +++ D. Neither the JVM nor the container is allowed to load a native library. (This argument is refuting points 2 and 3 above.) And since there is no other way to load a library, that implicitly means that JNI can not be used. Response. That isn't what the spec says. It specifically mentions that the container can load a native library. And is says nothing about anything outside the container. +++ E. You can't use JNI in an EJB because you can't load the native library in the EJB. (That is the whole argument.) Response. EJBs don't exist by themselves. There are other places to load the library. +++ F. The spec doesn't say that the container will allow you to load a library. Response. That has nothing to do with this discussion. The point is not what a specific container does but whether it is allowed. =================================== Inferences from the spec. Given that it specifically allows the container to load a library it certainly seems that something is allowed to use JNI. If the rule had said "The enterprise bean must not attempt to use JNI" it would have made it perfectly clear that an EJB could not use JNI. It does not say that. The inference is that it can use JNI. =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
