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.
Imre Kifor
Valto Systems
-----Original Message-----
From: Richard Monson-Haefel <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Thursday, February 25, 1999 2:13 PM
Subject: Re: Primary key
>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.
>
>-----Original Message-----
>From: Imre Kifor
>To: [EMAIL PROTECTED]
>Sent: 2/25/99 12:38 PM
>Subject: Re: Primary key
>
>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.
>
>Imre Kifor
>Valto Systems
>
>-----Original Message-----
>From: Malcolm Sparks <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>Date: Thursday, February 25, 1999 1:20 PM
>Subject: Re: Primary key
>
>
>>On Thu, Feb 25, 1999 at 08:59:56AM -0800, Mike Chu wrote:
>>> A primary key is based on fields which can be updated. Does this
>>> mean the pk could change once these fields change?
>>> This is a problem with container managed beans only, IMHO - because
>>> primarily due to implementation.
>>> Here in Hong Kong we don't have too many implementations. Would
>>> appreciate a reply from more knowledeable American (yankee!!)
>>> friends.
>>> -mc
>>>
>>
>>[Hi folks, good to be back.]
>>
>>Well I'm not an American, but I do have something to add.
>>
>>Primary key fields are public so that the container can set them after
>>ejbCreate has finished. It needs access to them during updates as
>>well. However, you would certainly never want to change the values in
>>the PK yourself. It's difficult to see how the specification could
>>enforce this, and yet still allow containers access. It's difficult,
>>but I'm sure not impossible.
>>
>>Until then, you just have to try to avoid changing pk fields in your
>>code.
>>
>>This one's up for discussion.
>>
>>Malcolm
>>
>>=======================================================================
>====
>>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".
>>
>
>========================================================================
>===
>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".
>
>===========================================================================
>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".
>
===========================================================================
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".
