So I guess you are not interested in taking on this particular
task. :-)
Pivot-native collections offer a few advantages:
- Optimized implementation. We use our collections *everywhere* in
Pivot - as a data model for components, as the backing for our UI
hierarchy, in data serialization, etc. As such, any performance
improvement we can provide is likely to be worthwhile.
- Simplified debugging. It is much easier to browse a native Pivot
ArrayList's contents than a wrapped java.util.ArrayList. I expect the
same to be true for maps and sets.
- Code independence. We designed these classes as replacements for the
JDK collections. It seems backwards to require them as a dependency.
Is anyone else interested in picking this up?
G
On Aug 10, 2009, at 7:45 AM, Noel Grandin wrote:
PIVOT-20: Complete collection classes
I have completed the Pivot-native implementations of the list
classes, but
HashMap and HashSet remain outstanding and are still just wrappers
around
their JDK counterparts. Todd was originally assigned to this task,
but if
anyone else is interested and has time, you are welcome to tackle
it. We
imagine that the bulk of the work will be in HashMap, since HashSet
can
internally use a map to maintain its own state. Alternatively, the
implementer may find it easier to share some common code via a
package
private class.
I remain unconvinced that doing a pivot-native implementation will buy
you sufficient performance gain to warrant the extra maintenance
burden.
HashMap's and their related HashSet's are incredibly finicky devices,
with lots of tradeoffs to make to achieve reasonable performance in
odd corner cases.
The cost of some indirection and the extra 16-odd bytes per object is
hardly likely to be worth it, especially given hotspot's ability to
inline method calls.
Regards, Noel.
