jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: Checkstyle improvements
Date Thu, 28 Apr 2005 08:43:52 GMT
On 4/27/05, Jukka Zitting <jz@yukatan.fi> 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
> 
>

Mime
View raw message