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)
