[
https://issues.apache.org/jira/browse/WICKET-5550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13969144#comment-13969144
]
Mattias Eliasson commented on WICKET-5550:
------------------------------------------
Well I am new to Wicket so my main issue are to learn how it works, which
practically makes everything I am curious about a main issue. I also have an
issue with code duplication unless it have a good reason, it makes code harder
to learn not only for me but for the next guy that intend to learn it.
Code duplication also means you introduce a risk for performance regression or
bugs compared to code as mature as the standard java classpath. I do not see
any bug or regression in these two classes, but that doesn't mean there aren't
any.
Well I do not think that a redundant interface can be harmful, unless of course
other code or entire classes are made or preserved because someone think that
they need it.
> 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
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> 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)
