[DIRAPI-318] Schema elements HashCode are not computed at all

• Type: Improvement
• Status: Resolved
• Priority: Critical
• Resolution: Fixed
• Affects Version/s: 2.0.0.AM1
• Fix Version/s: 2.0.0.AM2
• Assignee: Unassigned
• Reporter: Emmanuel Lécharny
• Created: 27/Aug/18 09:45
• Updated: 28/Aug/18 05:33
• Resolved: 27/Aug/18 22:26

Description

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 :

    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;
        }
    }

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 :/