[jira] [Created] (DIRAPI-318) Schema elements HashCode are not computed at all

["Emmanuel Lecharny (JIRA)" <ji...@apache.org>]

Emmanuel Lecharny created DIRAPI-318:
----------------------------------------

             Summary: Schema elements HashCode are not computed at all
                 Key: DIRAPI-318
                 URL: https://issues.apache.org/jira/browse/DIRAPI-318
             Project: Directory Client API
          Issue Type: Improvement
    Affects Versions: 2.0.0.AM1
            Reporter: Emmanuel Lecharny
             Fix For: 2.0.0.AM2


The {{SchemaObject}} sub-classes hashCode is never computed, unless the {{lock()}} method is called.

The {{lock()}} method is used to compute this value, but them the object isn't mutable anymore. This is ok for the un-mutable flavor, not at all for the mutable one, as any attempt to update them will result in a {{UnsupportedOperationException}} being thrown, like in :

{code:java}
    public void setMayAttributeTypeOids( List<String> mayAttributeTypeOids )
    {
        if ( locked )
        {
            throw new UnsupportedOperationException( I18n.err( I18n.ERR_13700_CANNOT_MODIFY_LOCKED_SCHEMA_OBJECT, getName() ) );
        }

        if ( !isReadOnly )
        {
            this.mayAttributeTypeOids = mayAttributeTypeOids;
        }
    }
{code}

The idea behind not computing teh hashCode on the fly was to speedup the use of this class, which is frequently stored in {{Map}} or {{Set}}. The problem is that the {{lock()}} method must now be called explicitly *outside* the class, which is clearly painful.

The direct consequence if the {{lock()}} method is not called is that *ALL* the {{SchemaElement}} instances will have a hashCode value of {{0}}, making the access from a {{Set}}/{{Map}} quite expensive :/

To add insult to injury, you simply can't call {{lock()}} on a mutable version, as it will forbid you to update the object unless you unlock it before. Beautiful :/



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)