[
https://issues.apache.org/jira/browse/WICKET-5550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13969270#comment-13969270
]
Martin Grigorov commented on WICKET-5550:
-----------------------------------------
Hi,
Thanks for your comments!
Standard Java classes (collections included) are not always the best solution
for a given problem. Many libraries out there provide their own impls because
the ones coming with the JDK are optimal for the general case but sub-optimal
for some specific cases. For example: Trove, Guava, Apache commons-xyz, etc.
MetaData(Key|Entry) classes are in Wicket since 1.0 or 1.1 and are well tested
in production.
I agree that at that time the standard JDK collections may have had some
problems and that's why another Wicket developer invented MetaData(Key|Entry)
classes. Maybe these problems in the standard classes are solved now but
without knowing what were these problems it is hard to say whether this is true.
The problem that I see with this ticket is that we are going to replace well
tested code with something new.
This may lead to:
1) newly introduced bugs
2) API breaks
p.1) is the smaller issue. But p.2) is something we cannot afford unless it is
really required.
Please provide a patch and we will discuss 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)
