commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [Collections] [SUBMIT] Trie
Date Fri, 06 Dec 2002 13:08:38 GMT
Thanks Craig. With  two possible Jakarta users, we seem to have a justification for inclusion.

So, it is now about practical issues. How does the submitted Trie cope for design and performance.
Do we need a String only Trie, a URL Trie, or does the abstracted Trie submitted work OK?

The big question is to get the Trie interface correct. In my naive view, it would be nice
if there was no 'Trie' interface, but instead just a Map implementation and a TrieUtils. TrieUtils
would then only use the Map interface to determine the suffix/prefix/longest cases.

However, this may not be practical. Can I ask all concerned to think about the interface,
and whether the current one is suitable for all the needs we can think of.


public interface Trie extends Map {
// Gets all the entries that have keys which start with
// a given prefix.
public Set prefixEntrySet(Object keyPrefix);

// Get the entry with the longest key that is a prefix of
// the given value.
public Map.Entry getLongest(Object key);

>  from:    "Craig R. McClanahan" <>
> FWIW, there are at least two Jakarta products that I'm involved in (Tomcat
> and Struts) that have exactly the path-mapping use case that was described
> for the Trie class.  And, conveniently, they both already dependd on
> [collections] so it would be very convenient to have Trie added here.
> It will be very interesting to experiment with the relative speed of using
> a Trie in these cases versus the current algorithms (which clearly need
> some optimizations).
> So, an inactive-committer (to collections)  1 from me for including this.
> Craig McClanahan
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message