jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting ...@yukatan.fi>
Subject Re: Checkstyle improvements
Date Wed, 27 Apr 2005 19:38:20 GMT

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;

> 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.


Jukka Zitting

View raw message