Why EJB Needs Such a Restriction?

[Alec Lee]

Section 24.1.2 of the ejb spec says:
****
The enterprise bean must not attempt to query a class to obtain info about the declared members that are not otherwise accessible to the ejb because of the security rules of java lang. The ejb must not attempt to use the Reflection API to access info that the security rules of the java prog
lang make unavailable.
****
Does the above implies that ejb's environment do allow the above to be done and the spec need to explicitly prohibit it? I suppose ejb is not able to do what a normal java program already not able to do.
Anyone can clarify?

[Keith Rosenfield]

Hey Alec,
I suppose in order to be valid, an EJB container must not permit anything that is prohibited in the spec even if it is possible in a non-ejb environment.

[Alec Lee]

Just take the 2nd sentence as an example:
The ejb must not attempt to use the Reflection API to access info that the security rules of the java programming language make unavailable.
If the security rules of java language already make access unavailable, attempt by EJB will already be unavailable too. There is no need to make is an explicit rule in the specification to disallow it. Just like we wont specify "the EJB should have no logical error that violate the user requirement and crash the server".
So I wondering if the sentences imply the ejb environment is different from the normal non-ejb environment which makes an explicit rule necessary.
Appreciate any comment, thx
Alec
(SCJP1.4)

[Reid M. Pinchback]

I haven't seen anywhere in the spec that required a security manager to be installed (at least, not yet... still reading). I have seen containers that optionally allow you to configure a security manager. I'd bet that the spec is just trying to make it clear what a bean provider can depend upon. If a bean provider used reflection to get access to stuff he/she shouldn't, the bean may not be portable (or the deployer/sys admin might not be able to do their job). The interfaces remote/local declare what you are allowed to have access to, using reflection on anything except what you are allowed to have access to isn't wise (in EJB, or in applets, or in any other Java code where security restrictions an apply).