You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Mattias Eliasson (JIRA)" <ji...@apache.org> on 2014/04/02 16:33:14 UTC

[jira] [Created] (WICKET-5550) MetaDataKey/MetaDataEntry redundancy.

Mattias Eliasson created WICKET-5550:
----------------------------------------

             Summary: MetaDataKey/MetaDataEntry redundancy.
                 Key: WICKET-5550
                 URL: https://issues.apache.org/jira/browse/WICKET-5550
             Project: Wicket
          Issue Type: Improvement
          Components: wicket
            Reporter: Mattias Eliasson
            Priority: Trivial


Let me start with the fact that I am ready to create a full patch for this, but I want feedback from other developers first.

My first reflection when reading the MetaDataKey source where that the array should be replaced by an ArrayList which would decrease code complexity and increase HotSpot optimization, as the array logic does practically the same thing as ArrayList.

However after more consideration why are these two classes (MetaDataKey) not based on the java.util.Map class. The only thing MetaDataKey would actually need are the hashCode (and possibly equals) functions. Using for instance HashMap, the result would be identical. 

The MetaDataEntry should be dropped and replaced with Map.Entry. The only difference between them are that MetaDataEntry are IClusterable.

I suggests creating a ClusterableHashMap class that extends HashMap and implements IClusterable. Then I would use a MetaDataKey which contains nothing but hashCode and possibly equals. That are clean, slim and reusable. 

In fact it would feel better to have a @Clusterable attribute that can just be attached to a HashMap instance variable, creating a new class just to add IClusterable to a build feels excessive.

Also this will allow for some code cleanup where MetaDataKey/Entry are used, which are why I estimate this to one day instead of an hour.



--
This message was sent by Atlassian JIRA
(v6.2#6252)