I am afraid that I am not following this discussion. I would appreciate
some clarifiaction, if you don't mind. It appears to me that Imre is
claiming that the Java 2 Platform security model allows you to violate
the encapsulation features that are specified in the Java Language
Specification.
Are you saying that you can take a class like this:
public class Foo
{
private String id;
public String somethingElse;
public void setSomethingElse( String s )
{
somethingElse = s;
}
...
}
and through some security policy setting be able to manipulate the "id"
String? I'm either grossly misunderstanding your point or else you'll
have to show me where this mechanism is described.
I also do not understand what "abstraction features that EJB effectively
disables." How is abstraction affected by EJB? You might argue that
encapsulation is affected, but I would argue against that stance as
well. Once an EJB in instanciated, there is no valid way of getting a
direct reference to that object. All access is through the EJBObject
which acts as the EJB's interface. THe only other class type that has
access to the class members is a subclass of the EJB class. In the case of
the subclass, there is a loss of encapsulation in that the superclass
cannot hide its persistent data from the sunclass.
Please let me know where I've misunderstood.
Imre Kifor wrote:
>
> That is absolutely true. The problem is that you are also using Java that
> provides very important abstraction features that EJB effectively disables.
> As soon as your project becomes more than trivial, these abstraction
> features become crucial in software maintenance. Think about the second wave
> of developers that come into a project and have to figure out how to
> fix/extend already existing code. That is the time when hiding details is
> not just necessary but absolutely required. EJB will not be widely adopted
> if these features that have become a very important characteristic of all
> object-oriented languages are disabled. This is not a question of
> compatibility. IMHO, having non-final public fields in your PKs is a
> disaster waiting to happen. And that is not good for EJB.
>
> From: Richard Monson-Haefel <[EMAIL PROTECTED]>
>
> >If you are going to build Enterprise JavaBeans and have not settled on a
> EJB
> >server, you better stick to using public fields for both primary keys and
> >the bean classes themselves. Not all EJB servers support the Java 2
> >platform.
> >
> >From: Imre Kifor
> >
> >Actually, on the Java 2 platform, the requirement for public PK fields
> >can
> >(and should) be relaxed. Having enough security privileges, a server can
> >inspect/set private fields. The same applies to CMP beans. Exposing
> >fields
> >that otherwise should be private will just cause confusion, errors and
> >misuse.
--
Michael S. Jenkins | Abstract Data Types in Java
Jenkins Consulting Services, Inc | Michael S Jenkins / McGraw Hill
[EMAIL PROTECTED] | ISBN 0-07-913270-7
[EMAIL PROTECTED] | Get the book through my web site
http://www.wwa.com/~mjenkins <<<<-- in association with Amazon.com
===========================================================================
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".
