On 4/27/05, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Stefan wrote on protected member variables:
> > therefore i suggest to disable the related Checkstyle check.
>
> Sounds fine to me, especially since the protected member variable
> pattern is so common in Jackrabbit.
>
> In fact this pattern reflects the more general design style in
> Jackrabbit and in the JCR API as well. In many places Jackrabbit uses
> classic inheritance for common functionality between classes. Realizing
> this was a major step in getting to understand the Jackrabbit internals.
> Based on this I intend to create and add (sooner or later :-) some class
> inheritance diagrams as a part of the JCR-73 Javadoc improvement task.
>
> > regarding missing hashCode(): i intentionally do never override hashCode()
> > for mutable objects. hashCode() should imo only be implemented for
> > immutable objects.
>
> As Felix already noted:
>
> There's always the catch that you won't be able to use HashSets or
> similar data structures to reliably keep track of such objects (two
> "equal" objects might have different hash codes). Thus, if nothing else,
> I'd suggest using the following placeholder code to implementing the
> hashCode() methods. It certainly isn't fast but satisfies the
> equals/hashCode contract for all equals() implementations.
>
> /**
> * Always returns <code>1</code>. Implemented as a simple
> * placeholder to satisfy the equals/hashCode contract. This
> * method should be properly implemented if instances of
> * this class need to be managed in a hash table.
> *
> * @return always <code>1</code>
> * @see Object#hashCode()
> */
> public int hashCode() {
> return 1;
> }
+1 for overriding hashCode() returning a constant integer
for mutable classes. i don't fully agree with the javadoc though.
if you implement hashCode() 'correctly', i.e. calculate the hashcode
based on the objects fields, you risk losing track of data in a
hash table.
mutable objects should imo never be managed in hash tables.
returning a constant integer is therefore fine with me for mutable
objects.
cheers
stefan
>
> > in general: i think that checkstyle is a good tool that helps to improve the
> > quality and consistency of the code base. but we should use common
> > sense when interpreting the recommendations. blindly following all the
> > recommendations or or trying to achieve 0 reported issues is imo not
> > worthwhile.
>
> Agreed. My goal with JCR-97 is not to blindly follow guidelines but to
> get rid of the simple issues so that the Checkstyle report is actually
> useful in enforcing a common coding style and locating potentially
> troublesome constructs (like the hashCode issue). A newcomer like me can
> also use the report as a list of gotchas to watch out for.
>
> BR,
>
> Jukka Zitting
>
>
