Its funny to see two apparently excellent componentware developers
differing on a point and trashing it out in public. My 2c worth.....
your both right yet neither.
I think Cedric is right. You see from Cedric's email address what part
of the componentware market he is in. He essentially works in the
container end, for all intensive purposes, the client code that hosts
the bean. It is his job to trap exceptions and present them or handle
them for his particular application of the binary reused component.
This handling may be to drop and ignore the exception as he has done
in his code, or output to a console, or if in a largely client sided
application, taking the exception and doing somthing in particular
about it. Its elementary Java 1.1 programming, and he does it
according to the book.
Juan it would appear is a component programmer. Anyone who understands
the semantics of componentware development realises that if their code
is to be reusable at the "binary" level, then it needs to be generic.
If a component is to be truely generic, it cannot possibly know about
each and every possible end use of the code, and therefore cannot
handle the exception in a manner in which will suit each and every
implementation that re-uses his code. Therefore it would be wrong of a
component developer to handle an exception that requires application
logic decisions to be made rather than business logic decisions that
are specific the component. Sure he doesnt catch the exception, but he
doesnt drop it either, and therefore the exception will be found at
the container level notifing the end user that there is a problem in
their particular application that needs to be debugged. Its elementary
EJB programming, and he does it according to the book.
I think what is important to bear in mind is the nature of the
exception that is being thrown. It is a runtime error.... and will
primarily crop up due to bad coding of code that would interact with
this class when reusing it at the "binary" level. So if you catch the
exception in the component, the application will not know there is a
problem, the spacecraft will launch with the last mile of directions
uninitialised, and the rocket will miss the moon, its primary target.
If you dont catch the error in the component, the application will
know there is a problem when it exists, and the spacecraft launch can
be stopped thus saving valuable human life and billions in taxpayers
money.
Obviously in a more mission critical application, where the code is
not run until after the point of no return, if the exception is
trapped by the component and dropped as in the example, the spacecraft
suddenly has no more directions for the last mile, therefore must be
at destination, so it stops, or the code crashes, and the spacecraft
gets sucked into Jupiters gravitational pull (bad news.... serious
core dump). If the exception is not trapped in the component, but is
trapped at the application layer, the application can prevent program
execution from ceasing, and load the emergency sequence
directions, put the craft into a safe earth orbit, which saves life
and years of engineering.
So on the issue of what should you do with exceptions in
componentware, it boils down to a simple question of know your
place.....
If you are in the Java 1.1 programming area, and are re-using
components, you need to trap exceptions and handle
them. If they are runtime exceptions, you need to know about them, and
QA until you cant reproduce them. You will find stack trace immensely
useful for this task.
If you are in the EJB programming area, and are developing a component
that can be reused at the "binary" level, you should only catch and
handle exceptions that are relevant to the piece of business logic
that your component handles. If you cant handle it because you dont
know the target application, or if it is a runtime exception, or if
its an exception that is not relevant to the business logic of your
component, then you either catch and re-throw the exception, or in the
case of the runtime exception, you let it pass so it will be detected
on the console of the app-server or at least detectable by the
application programmer who is reusing your component.
So I repeat, two very valid and intellegent comments. Which one is
more valid than the other depends on whether or not you are developing
components or plain old applications. Worth keeping in mind I think.
HTH
-Enda.
----- Original Message -----
From: "Juan Pablo Lorandi" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 25, 2002 7:21 AM
Subject: Re: hashcode and equals method
Great question. Again, looking at things from a diferent perspective
than Cedric(he works for bea, they make Weblogic, I'm just a poor
humble
argentinian coder living in the exile), a good server might take care
of
this for you. It would only need to use introspection mechanisms that
are part of the JRE, I'd like to presume, but again, I don't build app
servers, so I can afford a little ignorance on the subject.
Well, the idea behind J2EE, from a developer point of view, is to take
away complexity from the business logic coder. You should stick to the
spec, not try to make the AppServer programmer life easy. If you can,
well, that's superb. First things first, check out the javadoc for
java.lang.Object; it defines the contract equals() and hashcode()
should
implement. A valid, yet very inefficient hashcode implementation would
be:
public int hashCode() {
return 1;
}
More info on the contract is also available on the javadoc for
java.util.Hashtable.
First thing about equals, as Cedric points out, is to get it right.
Apart from java.lang.Object, you should also keep in mind the extra
requirements made by the Colections framework(java.util.
Collection/Set/List/Map). Nevertheless, the EJB 2.0 spec doesn't
explicitly impose any other requirement on the equals() implementation
within the PK class. Hence, it is a grey area, where no opinion stands
with enough weight by itself. One could argue(but would be pushing
it),
that since the EJB spec doesn't specify any behavior from equals a
container that relies on equals() being correctly implemented is a
very
bad(a.k.a. naughty) container. Of course, this assertion doesn't make
much sense.
To the juicy part.
Links:
Hashtable on equals and hashCode:
http://www.javaworld.com/javaqa/2002-06/01-qa-0621-hashtable.html
Not all equals are equal(brings up Strongly-Typed equals() ):
http://www.cuj.com/java/articles/a19.htm?topic=java
Runtime Exceptions:
http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.h
tm
l
On other note, having repeatedly being asked questions by people that
claim that they don't find any information available on the internet
on
these subjects has me particulary puzzled. I'm truly beginning to
wonder
if one must be of western extraction to master the use of google.
Google Help:
http://www.google.com/help/
My 2c,
Juan Pablo Lorandi
Chief Software Architect
Code Foundry Ltd.
[EMAIL PROTECTED]
Barberstown, Straffan, Co. Kildare, Ireland.
Tel: +353-1-6012050 Fax: +353-1-6012051
Mobile: +353-86-2157900
www.codefoundry.com
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]] On Behalf Of Ashwani Kalra
> Sent: Tuesday, June 25, 2002 6:12 AM
> To: [EMAIL PROTECTED]
> Subject: Re: hashcode and equals method
>
>
> Why dont container just compare the public fields of my
> Primary key class to search for entity. Why it relies on
> equals and hashcode. ??
> ----- Original Message -----
> From: "Cedric Beust" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, June 25, 2002 10:28 AM
> Subject: Re: hashcode and equals method
>
>
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]] On Behalf Of Ashwani Kalra
>
> > hi,
> > I have few questions on overriding the hashcode and equals
> method in
> > primary key class
> >
> > 1. If I dont implement these methods properly then what are the
> > problems I can face.
>
> It depends how bad you implement them :-)
>
> It is very important to get equals() right. It is easy to
> get it right, it is harder to get it efficient. To get it
> right, you simply need to respect the rules given in the Javadoc at
>
> http://java.sun.com/j2se/1.3/docs/api/java/lang/Object.html#eq
> uals(java.
> lang.Object)
>
> If you fail to get it right, your EJB container will probably
> reward you with numerous ObjectNotFoundException as it keeps
> failing to find your Entity beans through their primary keys.
>
> To get it efficient, you can refer to the emails that Juan
> and I just exchanged, or some longer threads that have taken
> place on theserverside.
>
> hashCode() is a little different since it only affects
> performance. Basically, the poorer your hash method is, the
> more collisions will occur when the container is storing the
> primary keys in its internal structure. The end result is
> probably longer cache access and other bad consequences (this
> is implementation-dependent). Same remark as above, there is
> plenty of literature on the subject, both from an EJB
> perspective, or more generally, on perfect hash functions.
>
> A rule of thumb: xoring (^ in Java) the respective
> hashCodes() of your primkey-fields usually yields a decent
> hash function. It doesn't hurt to experiment, though, you
> sometimes get very interesting results when you start
> investigating how your hash maps get filled.
>
> > 2. What is the best way to implement them.
> > 3. Do I always need to be careful or can I be liberal
> > in certain applications
> > 4 I have read that any implementation what ever is not foolproof.
>
> I hope to have given you enough information to answer these
> questions. I would definitely recommend leaving the
> generation of these functions to tools (well, good ones :-)).
>
> --
> C�dric
>
> =========================
> 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".
