You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by bu...@apache.org on 2003/10/30 06:30:04 UTC
DO NOT REPLY [Bug 24230] -
RFE: Using JDK 1.4 LinkedHashMap instead of commons LRUMap
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24230>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24230
RFE: Using JDK 1.4 LinkedHashMap instead of commons LRUMap
dlr@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Version|1.0-Release |1.5
------- Additional Comments From dlr@apache.org 2003-10-30 05:30 -------
$ egrep -r '^import org\.apache\.commons\.collections' velocity/src/java/ | perl
-pe 's/.*collections\.(.+);/$1/g' | sort | uniq
ExtendedProperties
LRUMap
Doug, we also use ExtendedProperties extensively (it's part of the
RuntimeServices API). That makes it impossible to remove a dependency upon
Jakarta Commons Collections in the 1.x release train. Commons Collections has
demonstrated solid release policy, and does a good job of deprecation and
backwards compatibility. I'm quite happy with it.
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
Re: DO NOT REPLY [Bug 24230] - RFE: Using JDK 1.4 LinkedHashMap instead of commons LRUMap
Posted by Will Glass-Husain <wg...@forio.com>.
Hi,
I think Velocity should avoid dependency on JDK 1.4 as long as possible.
It's really not the role of a third party tool to dictate the JVM used by
the developer. For example, the developer may be using other libraries that
haven't been tested on JDK 1.4. Or he may deploy to a server that runs JDK
1.3. The need for the JDK 1.4 libraries seems really trivial in this
instance and easily avoided.
Just my two cents.
WILL
----- Original Message -----
From: "Charles Oliver Nutter" <he...@headius.com>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
Sent: Thursday, October 30, 2003 7:03 AM
Subject: Re: DO NOT REPLY [Bug 24230] - RFE: Using JDK 1.4 LinkedHashMap
instead of commons LRUMap
> 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.
>
> 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.
>
> - 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
>
---------------------------------------------------------------------
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
Re: DO NOT REPLY [Bug 24230] - RFE: Using JDK 1.4 LinkedHashMap instead of commons LRUMap
Posted by Chris Miller <ch...@hotmail.com>.
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 Charles Oliver Nutter <he...@headius.com>.
re 1.2: I believe it, even though it's frightening. When I think of
performance improvements from 1.2 to 1.3/4 ALONE it's no wonder Java
still has a bad rep--so many systems running the dreadfully slow (in
comparison) 1.2.
re dumping c-c: I'm all for eliminating dependencies. I understand that
a lot of these APIs were created for just this reason, but it becomes
simple issue if numbers. If we're adding a dependency on 50 classes in
order to use only one, and that one could be implemented quickly and
easily, eliminating that dependency, then we become far more agile and
adaptable. Also (although this is not the case here) a single, miniscule
dependency on one small part of an API can balloon into a dependency on
other APIs, other projects, and in some cases, other licenses that may
or may not be incompatible.
The balloon effect is perhaps the biggest one to consider here; even if
an API manages versions, deprecation, and backward-compatibility well,
it could still introduce other external APIs that don't do such a good
job. If A depends on B 1.1 and C 1.5, and B depends on incompatible C
1.6, then A suffers, no matter how well encapsulated is B's dependency on C.
Reducing these cross-API dependencies doesn't produce as much benefit
when there are multiple reasons to use an API, but in this case, perhaps
it's something to consider. Bottom line: Does including the whole API
add more value to the project than its extra bulk, dependencies, and
compatibility concerns would detract? Does duplicating the few classes
used from the API result in more duplication than it would be worth?
Maybe the answer is no on both counts.
- Charlie
Geir Magnusson Jr. wrote:
>
> There's no belief that 1.4 will be pervasive any time soon. People
> are still running 1.2 in production systems. Really.
> <SNIP>
> 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
>>
>>
---------------------------------------------------------------------
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 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 Charles Oliver Nutter <he...@headius.com>.
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.
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.
- 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