You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Chris Miller <ch...@hotmail.com> on 2003/11/06 02:29:33 UTC
Re: DO NOT REPLY [Bug 24230] - RFE: Using JDK 1.4 LinkedHashMap instead of commons LRUMap
I'm not familiar with the Velocity source so apologies if this suggestion is
a little off base, however this discussion seems to be covering some very
similar ground to some code I recently wrote for OSCache. It attempts to use
a LinkedHashSet (JDK 1.4), then falls back to SequencedHashMap
(commons-collections), or if that's not available it finally drops back to a
LinkedList.
Of course this introduces a *compile time* dependency on JDK 1.4.x. I don't
think that is too big a problem since most users will download a prebuilt
jar anyway, or will at least be able to build against 1.4 even if in
production they use 1.3.x or lower.
Take a look at the code here:
https://oscache.dev.java.net/source/browse/oscache/src/core/java/com/opensymphony/oscache/base/algorithm/LRUCache.java?rev=1.2&content-type=text/vnd.viewcvs-markup
Admittedly it does add complexity to the code, but I think the performance
and compatibility benefits outweigh that (in this particular case at least).
"Geir Magnusson Jr." <ge...@optonline.net> wrote in message
news:907CDD2A-0AF3-11D8-B45B-000A95A01192@optonline.net...
>
> On Thursday, October 30, 2003, at 10:03 AM, Charles Oliver Nutter wrote:
>
> > LinkedHashMap (which extends HashMap) does not have the complexity of
> > TreeMap. TreeMap is actually O(log n) complexity for inserts and
> > retrievals, while HashMap (with an efficient load factor) approaches
> > O(1). The benefit of LinkedHashMap, as in SequencedHashMap, is O(1)
> > iteration time and predictable ordering at the cost of higher memory
> > requirements.
> >
> > If avoiding dependence on J2SE 1.4 is the primary concern, then the
> > SequencedHashMap should be used. If, by the time this code is
> > released, there's a reasonable understanding that 1.4 should be
> > pervasive, then one could stick to J2SE-provided classes.
>
> There's no belief that 1.4 will be pervasive any time soon. People are
> still running 1.2 in production systems. Really.
>
> >
> > A good recommendation for SequencedHashMap might be to defer to
> > LinkedHashMap wherever possible, by performing a one-time
> > Class.forName("java.util.LinkedHashMap") and acting appropriately.
> > When 3rd-party code is included in almost identical form as part of
> > new 1st-party APIs, it would be good practice to defer. Ideally, this
> > should be the goal of any Commons API that seeks to wrap and extend
> > with a mind for future compatibility.
>
> Isn't this a discussion for commons-collections? Because we are using
> the LRUMap for the LRU feature, not performance considerations. (Not
> that they aren't important...)
>
> Or are you advocating we punt ont he c-c impl, and do our own using SHM
> or LHM as appropos? (I think that wouldn't be a bad idea, as I want to
> get rid of the c-c dep anyway :)
>
> geir
>
> >
> > - Charlie
> >
> > bugzilla@apache.org wrote:
> >
> >> ------- Additional Comments From dlr@apache.org 2003-10-30 05:30
> >> -------
> >> <SNIP>
> >> Do you know how LinkedHashMap's TreeMap-like -- log(n)? --
> >> performance compares
> >> to that of LRUMap? The latter sub-classes Commons Collections's
> >> SequencedHashMap, which has fast O(1) search time, deletion time, and
> >> insertion
> >> time.
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >
> >
> --
> Geir Magnusson Jr 203-247-1713(m)
> geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DO NOT REPLY [Bug 24230] - RFE: Using JDK 1.4 LinkedHashMap instead of commons LRUMap
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Tuesday, November 11, 2003, at 01:53 PM, Daniel L. Rall wrote:
> Chris Miller wrote:
>>> Has anyone heard of any problems with a 1.4.x-compiled jar in a 1.3.x
>>> environment?
>>>
>>> geir
>> No, this should work fine as long as there are no dependencies on JDK
>> 1.4
>> code encountered at runtime. Also, compiling with javac -target 1.4
>> will I
>> think cause problems, but there should be no reason to compile with
>> that
>> flag anyway.
>
> I've seen badness which was unrelated to the compiled bytecodes. For
> instance, JDK 1.4.2 embeds Xalan, which at runtime masks a Xalan used
> at compile-time.
But that's tripping over the classpath. You would just be compiling in
the class name - the late-binding of java means that the JVM can pull
it from the classloader, no matter how it got there.
That one hung me up for a long time when switching to jdk 1.4 on the
mac....
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DO NOT REPLY [Bug 24230] - RFE: Using JDK 1.4 LinkedHashMap
instead of commons LRUMap
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Chris Miller wrote:
>>Has anyone heard of any problems with a 1.4.x-compiled jar in a 1.3.x
>>environment?
>>
>>geir
>
>
> No, this should work fine as long as there are no dependencies on JDK 1.4
> code encountered at runtime. Also, compiling with javac -target 1.4 will I
> think cause problems, but there should be no reason to compile with that
> flag anyway.
I've seen badness which was unrelated to the compiled bytecodes. For
instance, JDK 1.4.2 embeds Xalan, which at runtime masks a Xalan used at
compile-time.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DO NOT REPLY [Bug 24230] - RFE: Using JDK 1.4 LinkedHashMap instead of commons LRUMap
Posted by Chris Miller <ch...@hotmail.com>.
> Has anyone heard of any problems with a 1.4.x-compiled jar in a 1.3.x
> environment?
>
> geir
No, this should work fine as long as there are no dependencies on JDK 1.4
code encountered at runtime. Also, compiling with javac -target 1.4 will I
think cause problems, but there should be no reason to compile with that
flag anyway.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: DO NOT REPLY [Bug 24230] - RFE: Using JDK 1.4 LinkedHashMap instead of commons LRUMap
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Wednesday, November 5, 2003, at 08:29 PM, Chris Miller wrote:
> I'm not familiar with the Velocity source so apologies if this
> suggestion is
> a little off base, however this discussion seems to be covering some
> very
> similar ground to some code I recently wrote for OSCache. It attempts
> to use
> a LinkedHashSet (JDK 1.4), then falls back to SequencedHashMap
> (commons-collections), or if that's not available it finally drops
> back to a
> LinkedList.
>
> Of course this introduces a *compile time* dependency on JDK 1.4.x. I
> don't
> think that is too big a problem since most users will download a
> prebuilt
> jar anyway, or will at least be able to build against 1.4 even if in
> production they use 1.3.x or lower.
>
> Take a look at the code here:
>
> https://oscache.dev.java.net/source/browse/oscache/src/core/java/com/
> opensymphony/oscache/base/algorithm/LRUCache.java?rev=1.2&content-
> type=text/vnd.viewcvs-markup
>
> Admittedly it does add complexity to the code, but I think the
> performance
> and compatibility benefits outweigh that (in this particular case at
> least).
What it would do for us is unhook one dependency on
commons-collections, which is IMO totally worth doing if we can unhook
from commons-collections via the ExtendedProperties class. If we can't
escape the grasp of ExtendedProperties, then maybe we fix
commmons-collections with the technique you outlined, and then let them
worry about it :)
Has anyone heard of any problems with a 1.4.x-compiled jar in a 1.3.x
environment?
geir
>
>
>
> "Geir Magnusson Jr." <ge...@optonline.net> wrote in message
> news:907CDD2A-0AF3-11D8-B45B-000A95A01192@optonline.net...
>>
>> On Thursday, October 30, 2003, at 10:03 AM, Charles Oliver Nutter
>> wrote:
>>
>>> LinkedHashMap (which extends HashMap) does not have the complexity of
>>> TreeMap. TreeMap is actually O(log n) complexity for inserts and
>>> retrievals, while HashMap (with an efficient load factor) approaches
>>> O(1). The benefit of LinkedHashMap, as in SequencedHashMap, is O(1)
>>> iteration time and predictable ordering at the cost of higher memory
>>> requirements.
>>>
>>> If avoiding dependence on J2SE 1.4 is the primary concern, then the
>>> SequencedHashMap should be used. If, by the time this code is
>>> released, there's a reasonable understanding that 1.4 should be
>>> pervasive, then one could stick to J2SE-provided classes.
>>
>> There's no belief that 1.4 will be pervasive any time soon. People
>> are
>> still running 1.2 in production systems. Really.
>>
>>>
>>> A good recommendation for SequencedHashMap might be to defer to
>>> LinkedHashMap wherever possible, by performing a one-time
>>> Class.forName("java.util.LinkedHashMap") and acting appropriately.
>>> When 3rd-party code is included in almost identical form as part of
>>> new 1st-party APIs, it would be good practice to defer. Ideally, this
>>> should be the goal of any Commons API that seeks to wrap and extend
>>> with a mind for future compatibility.
>>
>> Isn't this a discussion for commons-collections? Because we are using
>> the LRUMap for the LRU feature, not performance considerations. (Not
>> that they aren't important...)
>>
>> Or are you advocating we punt ont he c-c impl, and do our own using
>> SHM
>> or LHM as appropos? (I think that wouldn't be a bad idea, as I want to
>> get rid of the c-c dep anyway :)
>>
>> geir
>>
>>>
>>> - Charlie
>>>
>>> bugzilla@apache.org wrote:
>>>
>>>> ------- Additional Comments From dlr@apache.org 2003-10-30 05:30
>>>> -------
>>>> <SNIP>
>>>> Do you know how LinkedHashMap's TreeMap-like -- log(n)? --
>>>> performance compares
>>>> to that of LRUMap? The latter sub-classes Commons Collections's
>>>> SequencedHashMap, which has fast O(1) search time, deletion time,
>>>> and
>>>> insertion
>>>> time.
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>>
>>>
>> --
>> Geir Magnusson Jr 203-247-1713(m)
>> geirm@optonline.net
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org