Gene,
You are referring to "your" progression which is just one way of doing things.
A lot of people I know do server side
programming through ages and for the EJB is nothing more than a Java TP Monitor.
I would be really surprised
if applets or swing are necessary Servlets or EJBs.
I also remember a super Java expert who tried JNI and would not know SHLIB_PATH
or LD_LIBRARY_PATH .
The point is EJB are supposed to make it easy to make the transition as you dont
have to know lot of things
beyond some language syntax and semantics. Many progammers with object
oriented experience, exposure to
the original products will make the transition much more easily than you think.
And I am sure many of them will
ask questions which may sound stupid for a second or so but are typically FAQ
style questions.
As seems to be your motto, there is a lot to know. Progression is one way ,
anologies are another way and I am sure there
will be several other ways of learning.
--Ashish
Gene Chuang <[EMAIL PROTECTED]> on 09/07/2000 12:13:07 PM
Please respond to A mailing list for Enterprise JavaBeans development
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: (bcc: Ashish Joshi/AmericanRe)
Subject: Re: FatKey Pattern... was: Does it ever make sense to putamulti
-bean-retur ningfindmethodin an entity bean?
Hi Bryan,
Hold on a sec, let me get off of my high horse before I respond to your
post... ;-)
First of all, I stand behind what I said: People who are NEW to JAVA (and
programming in general) should NOT be developing EJBs! This reminds me of a
post I saw on Weblogic's newsgroup. To paraphrase, this person was asking:
"How do I start the Weblogic Server under Win NT? I type 'java
weblogic.Server', but am getting 'weblogic.Server class not found' errors.
I even made sure I'm in the same directory as Server.class file, and still
am getting this error!"
I learned Java by writing simple applet programs; then snazzy Swing
applications; then I dabbled in JDBC, and then Servlets... From these
experiences I feel now at least minimally qualified to understand and code
EJB. And I think path of progressive learning is one that all Java newbies
should follow!
Gene
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Cooper, Bryan
Sent: Thursday, September 07, 2000 6:33 AM
To: [EMAIL PROTECTED]
Subject: Re: FatKey Pattern... was: Does it ever make sense to putamulti
-bean-retur ningfindmethodin an entity bean?
I enjoyed reading through this thread. It had some very good technical
content. I was disturbed by the paragraph I clipped below:
Keep your personal opinions to yourself. Everyone has to learn and that
includes newbies...
>>I find it disturbing that a lot of people who BARELY understand Java try
to write
>> EJB's and use app servers; I find this notion ridiculous!
How do you propose we learn how to do this?
>>EJB and app
>>servers is NOT for beginning Java programmers. Sure a lot of vendors try
to
>>advertise otherwise (the bottom line is to sell as many units as possible,
>>right? :-)) by having snazzy GUI bean designers and deployers, but I
think
>>EJB is a technology that suited for intermediate to advanced developers...
>>hence that's why we're paid the big bucks, right? <<
I think the big bucks have gone to your head!
Regards,
Bryan Cooper
> ----------
> From: Gene Chuang[SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, September 07, 2000 12:45 AM
> Subject: Re: FatKey Pattern... was: Does it ever make sense to
> putamulti-bean-retur ningfindmethodin an entity bean?
>
> Hi Jonathan,
>
> You make many great points, and I really like the feedback; as I have
> previously said in another post, my FatKey pattern is up and running on
> our
> production site (kiko.com). SUPERFICIALLY, I see nothing happening out of
> the ordinary, but like you said, it's most likely because my pattern is
> almost tailored to Weblogic's app server (hence I guess my pattern isn't
> really vendor-neutral) AND my pattern is really tailored to my bean
> architecture (hence my pattern may not be even implementation-neutral!)
> But
> I do want comments like yours to try to poke holes in my little
> experiment... better to have us discover errors through discussion than
> through practice, right?
>
> I wholehearted agree with you that hashCode and equals functions are very
> difficult to implement, and that most java developers THINK they know how
> to
> implement these functions correctly or efficiently. In fact, if you hop
> over to newsgroups.bea.com (don't worry, I won't warn the BEA dudes that
> they've got an Inprise interloper!) you'll find that a large number of
> posts have to do with users not implementing these 2 functions correctly
> (or
> not implementing them at all!)
>
> However, I believe this is something that developers need to learn. If
> one
> has programmed Java, C or C++ long enough, one has come across situations
> where she MUST implement hashCode and equals: the most blatant example
> that
> comes to mind is using a custom key class for HashMap or HashSet. I find
> it
> disturbing that a lot of people who BARELY understand Java try to write
> EJB's and use app servers; I find this notion ridiculous! EJB and app
> servers is NOT for beginning Java programmers. Sure a lot of vendors try
> to
> advertise otherwise (the bottom line is to sell as many units as possible,
> right? :-)) by having snazzy GUI bean designers and deployers, but I
> think
> EJB is a technology that suited for intermediate to advanced developers...
> hence that's why we're paid the big bucks, right? :-)
>
> I can see the merits of Inprise alleviating the burden of Java developers
> having to implement these 2 functions by using the serialized bytes of a
> pk
> object to intrinsically implement hashCode and equals. However, one can
> also argue that you have stripped a power user the ability, even the
> option,
> to define how she wants to do equality and hash comparisons! And I think
> that's what the creators of Java intended: to allow users to implement
> these two functions so they can define the way they want objects to behave
> in a hash container such as HashMaps and HashSets, and in our case, EJB
> Key
> comparisons!
>
> Finally, you do drive a good point with your final observation: a FatKey
> can slip out of a transaction from which it was created without ejbLoad
> being called on it (client can call EJBObject.getPrimaryKey() and
> serialize
> it for later use, but NOT call any business methods that will result in a
> ejbLoad), and this "dirty" FatKey can slip into a subsequent transaction.
> But they way I see it, and correct me if I'm wrong, the only way a Primary
> key can be "reused" in a subsequent transaction is through
> findByPrimaryKey,
> right? So here's how I get around the stale key problem: In my
> findByPrimaryKey implementation (as opposed to my findByXXXX
> implementation), even though I get a FatKey passed in from the method
> argument, I recreate the FatKey again regardless of what's in the argument
> FatKey and return that to the container! Hence I guess the only really
> annoyance with a FatKey across transactions is that FatKey is, well, fat
> (and takes up memory)! But in my architecture I aways invoke business
> methods from the collection of EJBObjects I get from a findByXXX, AND I
> never really store a Primary Key for outside the transaction usage (I
> would
> store the Handle instead), so I managed to avoid this possible "loophole".
>
> Gene
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> To: [EMAIL PROTECTED]
> Sent: 9/6/00 5:19 PM
> Subject: Re: FatKey Pattern... was: Does it ever make sense to
> putamulti-bean-retur ningfindmethodin an entity bean?
>
> Gene,
>
> This is very interesting. I had forgotten that many EJB containers use
> the equals() and hashCode() methods for primary key comparison. We do
> not do this, and thus the difference. So, you may ask, why don't we
> use these methods, and what do we do differently?
>
> We don't use the user's implementation of equals() and hashCode()
> because
> I don't trust developers to write these methods correctly. As is
> evidenced
> by a number of threads on this topic, writing these methods correctly is
> quite hard. In particular, the result of calling hashCode needs to be
> uniformly
> distributed for optimal dictionary lookup. Particularly when dealing
> with
> numbers, it is easy to write a hashCode method which is very much non-
> uniform. For example, simply OR'ing together your numeric fields makes
> for
> a terrible hash, typically.
>
> (Also, as I have pointed out in a previous thread, it is legal in EJB to
> have
> a Entity object reference as a CMP field, and thus it is legal to have
> such
> a reference in a primary key field, and yet it is not possible to write
> the
> hashCode/equals method on a class containing such a field.)
>
> What do we do instead? We serialize the primary key to a chunk of
> bytes,
> and then use internal hashCode/equals functions which runs against that
> chunk of bytes. This is much faster than calling the equals/hashCode
> methods, and results in a truly uniform distribution, resulting in fast
> dictionary lookups, etc.
>
> So, a question arises: which of us is breaking the rules?
>
> I would say that you have broken a rule by writing a primary key class
> which has hashCode/equals methods which are not written according to the
> Java language specification. That is the equals method you have
> implemented does not actually test the equality of the objects, but
> only the equality of a subset of the fields. (And I admit that this
> is a thin argument.)
>
> On the other hand, you might argue that we are not compliant with the
> EJB
> specification, in that we do not use on the user's implementation of
> hashCode
> and equals (bugs and all), but instead use serialization for comparison
> purposes. (I don't see anything in the spec to preclude what we do, of
> course.)
>
> One last point, on the use of FatKeys. What would happen if you called
> the
> multi-object finder in one transaction, and then used the object
> references
> in another transaction. Previously, you said that you need to clear out
> the data fields in your ejbLoad method, so that ejbLoad is only called
> once. This is good. But what about if ejbLoad is never called in the
> finder's transaction, but only in a subsequent transaction. Here, you
> would
> still be loading the (potentially obsolete) state. Sound like the
> design
> pattern is still broken, but for different reasons.
>
> -jkw
>
> Gene Chuang wrote:
> >
> > Hi Jonathan,
> >
> > I see your concern; however I don't think my FatKey will break
> PrimaryKey
> > comparison... the reason why I say that is I believe it comes down to
> how I
> > implement the overloaded functions of PrimaryKey.hashCode() and
> > PrimaryKey.equals()... For my "regular" custom primary key classes,
> these
> > are overloaded to compare or hash the actual field value of the
> internal pk
> > (longs, in my case.) My FatKeys, which extend my CustomPrimaryKey, do
> NOT
> > overload these functions. Hence even if the "values" of my FatKeys
> change,
> > their comparison identity does not change.
> >
> > Based on my logic above, I am assuming that server vendors implement
> > EJBObject.isIdentical the following way:
> >
> > class EJBObject
> > {
> > boolean isIdentical(EJBObject aOtherObject)
> > {
> > return
> this.getPrimaryKey().equals(aOtherObject.getPrimaryKey());
> > }
> > }
> >
> > I think its a pretty logical assumption that most if not all vendors
> > implement isIdentical this way... at least I believe Weblogic does
> because
> > I have implemented the FatKey pattern in my architecture and aside
> from the
> > significant performance boost, I have not witnessed any strange
> > side-effects.
> >
> > Gene Chuang
> > Teach the world. Join Kiko!
> > http://www.kiko.com/profile/join.jsp?refcode=TAF-gchuang
>
> ========================================================================
> ===
> 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".
