I agree with the == comment, but even if you wanted to go hashCode, you could
use System.identityHashCode( obj );
Quoting Paul Speed <[EMAIL PROTECTED]>:
> I'd just like to point out that the only valid way to tell if two
> objects are the same instance if to use ==. Any other approach will not
> work.
>
> Comparing the toString() method results as you do is only really
> comparing the hashcodes... which are not unique by a long shot (I never
> assume people know this). Besides, == is even faster. What cases do
> you find that you've had to use .toString().equals(...) where you
> couldn't just do an == check?
>
> -Paul
>
> [EMAIL PROTECTED] wrote:
>
> > Hi, Frank.
> >
> > I do not agree. While in most cases it is desireable to see inside a bean
> (hence I created my
> > public static String toString(Object bean)
> > method), there are times when I just have to make sure a bean is not just
> equal but the same instance.
> > The java.lang.Object.toString() methods allows me to that quite quickly as
> the memory address is printed.
> >
> > Unless you have another way to provide that information, I'd rather stick
> with the default toString() plus some utility toString(Object) method. The
> impact for you is not too much. What you code so far is:
> > log.debug("mybean="+mybean);
> > and you'd have to change that to
> > log.debug("mybean="+BeanUtil.toString(mybean));
> > which will allow you to either see the memory address or the contents,
> whatever you prefer.
> >
> > Hiran
> >
> > -----------------------------------------
> > Hiran Chaudhuri
> > SAG Systemhaus GmbH
> > Elsenheimer Straße 11
> > 80867 München
> > Phone +49-89-54 74 21 34
> > Fax +49-89-54 74 21 99
> >
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
> >>Sent: Donnerstag, 7. Oktober 2004 13:43
> >>To: Struts Developers List
> >>Subject: Re: Proposed Action base class change
> >>
> >>Hi Niall,
> >>
> >>I certainly agree it would not be possible to satisfy
> >>everyone, but seeing as the intrinsic toString() is all but
> >>useless (and people do generally expect that to be the case
> >>with many classes), why not give an implementation that is of
> >>at least some use to some people? Surely it would be better
> >>than what you get now? Obviously it's something many people
> >>will override, and that's of course the whole point of
> >>inheritance. But providing even a slightly more useful
> >>default implementation (and maybe telling people it's a basic
> >>default implementation so as to try and keep the flood of
> >>bugzilla requests to a
> >>minimum) seems to me like a good idea.
> >>
> >>I can't address your point about dynabeans because I haven't
> >>used them enough to be able to intelligently comment (which
> >>is to say I haven't used them at all! :) )... I wouodn't
> >>imagine some basic implementation would be too tough for them as well.
> >>
> >>In any case, I will look at the toString builders you
> >>mentioned... I've come to really like using the commons
> >>packages and I try to whenever I can. This would be a good
> >>case I think, if it doesn't get added as I proposed. I
> >>already have an ActionHelpers class with a bunch of
> >>similarly-themed static methods for use from Actions, so
> >>maybe it's time to do so for forms as well.
> >>
> >>--
> >>Frank W. Zammetti
> >>Founder and Chief Software Architect
> >>Omnytex Technologies
> >>http://www.omnytex.com
> >>
> >>Niall Pemberton wrote:
> >>
> >>>Frank,
> >>>
> >>>For me it wouldn't be any use unless it also handled
> >>
> >>DynaBeans. Even
> >>
> >>>then I'd end up overriding it because I have some formatting utils
> >>>which do dates, arrays and collections. Seems to me if we put it in
> >>>then we would end up with a monster trying to satisy
> >>
> >>everyones needs
> >>
> >>>and forever dealing with bugzilla requests for enhacements (someone
> >>>would want an i18n version!) - all just for debugging.
> >>>
> >>>The easiest thing is to just put all that code into a
> >>
> >>utility method -
> >>
> >>>that way its only a one liner in the toString() - even
> >>
> >>better if you
> >>
> >>>have your own "base" ActionForm that all you others derive
> >>
> >>from, then
> >>
> >>>its only in one place.
> >>>
> >>>Also, there are a set of "toString" builders in commons
> >>
> >>lang which you
> >>
> >>>might like to use - including a reflection one like yours:
> >>>
> >>>
> >>
> >>http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/bui
> >>
> >>>lder/package-summary.html
> >>>
> >>
> >>http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/bui
> >>
> >>>lder/ReflectionToStringBuilder.html
> >>>
> >>>Niall
> >>>
> >>>----- Original Message -----
> >>>From: "Frank W. Zammetti" <[EMAIL PROTECTED]>
> >>>To: "Struts Developer" <[EMAIL PROTECTED]>
> >>>Sent: Thursday, October 07, 2004 4:29 AM
> >>>Subject: Re: Proposed Action base class change
> >>>
> >>>
> >>>
> >>>
> >>>>Obviously I made a typo in the subject... this applies to the
> >>>>ActionForm base class.
> >>>>
> >>>>Did anyone have any comment on this? I've noticed a lack
> >>
> >>of activity
> >>
> >>>>on the list lately...
> >>>>
> >>>>
> >>>>
> >>>>>Hello all...
> >>>>>
> >>>>>I find myself all the time overloading toString() of my
> >>
> >>ActionForms
> >>
> >>>>>for
> >>>
> >>>debugging
> >>>
> >>>
> >>>>>purposes, so I can easily dump the current state of the object. I
> >>>>>had
> >>>
> >>>been doing
> >>>
> >>>
> >>>>>this for each ActionForm class, specifically for it, but
> >>
> >>it ocurrs to
> >>
> >>>>>me
> >>>
> >>>that a
> >>>
> >>>
> >>>>>general-purpose reflection-based approach would be better.
> >>>>>
> >>>>>I'd like to propose adding this functionality to the
> >>
> >>ActionForm base
> >>
> >>>class. Here's
> >>>
> >>>
> >>>>>the code I propose adding:
> >>>>>
> >>>>>import java.lang.reflect.Field;
> >>>>>public static final AVERAGE_FIELD_SIZE = 25; public String
> >>
> >>toString()
> >>
> >>>>>{
> >>>>> String str = "";
> >>>>> StringBuffer sb = null;
> >>>>> try {
> >>>>> Field[] fields = this.getClass().getDeclaredFields();
> >>>>> sb = new StringBuffer(fields.length * AVERAGE_FIELD_SIZE);
> >>>>> for (int i = 0; i < fields.length; i++) {
> >>>>> if (sb.length() > 0) { sb.append(", "); }
> >>>>> sb.append(fields[i].getName() + "=" + fields[i].get(this));
> >>>>> }
> >>>>> str = sb.toString().trim();
> >>>>> } catch (Exception e) {
> >>>>> str = "Exception in ActionForm.toString() : " + e;
> >>>>> }
> >>>>> return str;
> >>>>>}
> >>>>>
> >>>>>The value of AVERAGE_FIELD_SIZE is a matter of debate, and it's of
> >>>
> >>>course impossible
> >>>
> >>>
> >>>>>to come up with a real value, so something reasonable is
> >>
> >>the answer.
> >>
> >>>>>25
> >>>
> >>>struck me
> >>>
> >>>
> >>>>>as a decent starting point.
> >>>>>
> >>>>>What does everyone think? I find this functionality to be very
> >>>>>useful
> >>>
> >>>in my work,
> >>>
> >>>
> >>>>>and I suspect others may as well. The code doesn't add any
> >>>>>dependencies
> >>>
> >>>outside
> >>>
> >>>
> >>>>>J2SE, and it's certainly simple enough as to not be
> >>
> >>particularly risky.
> >>
> >>>>>Thanks all!
> >>>>>
> >>>>>Frank W. Zammetti
> >>>>>Founder and Chief Software Architect
> >>>>>Omnytex Technologies
> >>>>>http://www.omnytex.com
> >>>>>
> >>>>
> >>>>
> >>>>------------------------------------------------------------
> >>
> >>---------
> >>
> >>>>To unsubscribe, e-mail: [EMAIL PROTECTED] For
> >>>>additional commands, e-mail: [EMAIL PROTECTED]
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>---------------------------------------------------------------------
> >>
> >>>To unsubscribe, e-mail: [EMAIL PROTECTED] For
> >>>additional commands, e-mail: [EMAIL PROTECTED]
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: [EMAIL PROTECTED] For
> >>additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
