commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <ggreg...@seagullsw.com>
Subject [lang] What's left for 2.0 (WAS: [collections] Primitive collecti ons (was Entities and LGPL))
Date Thu, 05 Jun 2003 02:13:40 GMT
Good news on Entities and supporting code.

We have over the last couple of weeks started "what's left for 2.0" message
threads a couple of times, do people here want a 2.0 (or a 2.0 beta first)?

Should we consider:

(1) IntHashMap as a non-public member of [lang]

In for 2.0, or defer to discuss (2)?

(2) "all his other utility code"

Does not affect [lang] per se but it is becoming clear that keeping [lang]
and [collections] not inter-dependent will introduce duplication of
functionality or odd placement of functionality (IntHashMap in lang, not
collection). Duplicating code is something I am really not fond of.

Would it make sense to layer [collections] on top of [lang], in the same
manner that Xalan is layered on and includes Xerces in it's distribution?
The most basic of collection-like things could be in [lang] for example; I
am not fond of this either but what are our options? Don't throw ripe fruit
at me if you consider this heresy s.v.p. ;-)

Gary

-----Original Message-----
From: Alex Chaffee / Purple Technology [mailto:guru@stinky.com] 
Sent: Wednesday, June 04, 2003 17:56
To: Jakarta Commons Developers List
Subject: [lang] [collections] Primitive collections (was Entities and LGPL)

I heard back from Justin Couch of j3d.org about the IntHashMap
implementation I used to speed up Entities.  He's willing to rerelease
it under an Apache license so I'll be checking that in (as a
non-public member of [lang]) soon.

He's also graciously offered to donate all his other utility code,
including some primitive-based collections classes.  I think it might
make a good addition to commons.  Does anyone working on [collections]
want to take a look at the classes referenced below?  Or barring that,
would anyone mind if I try incorporating some of them into the
collections code base?  (Of course, any work from me would have to
wait until I rejoin the leisure class...)

 - A

----- Forwarded message from Justin Couch <justin@vlc.com.au> -----

Delivered-To: guru@localhost
Delivered-To: stinky-guru@stinky.com
Date: Wed, 04 Jun 2003 15:49:33 -0700
From: Justin Couch <justin@vlc.com.au>
Organization: The Virtual Light Company
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4)
Gecko/20030529
X-Accept-Language: en-us, en
To: Alex Chaffee / Purple Technology <guru@stinky.com>
Subject: Re: IntHashMap source code
In-Reply-To: <20030604153045.T27339@stinky.com>

G'day Alex,

> I don't think this would entail any effort on your part other than a
> "make it so;" I can just paste in the Apache license and check it in
> on my own (with appropriate credit in the JavaDoc and source).

<voice type="Captain Picard">Make It So</voice>

:)

Sure I'm quite happy to have code reused wherever possible. IntHashMap 
is much simpler than most HashMap implementations and is missing some of 
the more complex methods, but it seems to fit the bill for you nicely. 
The reason I wrote it was for pretty much the same reason that you 
needed it - lots of high-speed string parsing/tokenisation.

We actually found that a lot of the garbage/time was not inside the 
Integer creation, but the actually hash lookups. If you have a dig 
inside the source code of the Sun utils, you'll see that any time you do 
a get() or containsKey() it creates a new instance of the Entry inner 
class object. In the end, we found that we didn't need 80% of the 
functionality of the java.util classes, so wrote specific ones for our 
use that were optimised for performance over features or thread-safeness.

Note that java.util.HashSet is exactly the same with the amount of 
garbage it generates on contains() calls as the HashMap. I can't 
remember if I have that in the j3d.org codebase or if it's only in the 
Xj3D codebase. If you'd like to grab that as well, you'll find some good 
performance benefits there too. If it's not in the j3d.org code, let me 
know and I'll send you a copy from Xj3D (which we also maintain/develop).

There's plenty of other code in the org.j3d.util package that may be of 
use to you too. Feel free to acquire anything out of there that you 
need. Xj3D is the far bigger of the two codebases (~350K LoC). Here's an 
almost complete listing of the utils directory there. Let me know if 
there's anything of use for you.

BlockingQueue
BooleanArray
BooleanStack
ColorUtils
DefaultErrorReporter
DoubleArray
FloatArray
HashSet
IconLoader
IntArray
IntHashMap
IntStack
LongArray
ObjectArray
Queue
SequenceReader
ShortHashMap
SimpleStack
StringArray


-- 
Justin Couch                         http://www.vlc.com.au/~justin/
Java Architect & Bit Twiddler              http://www.yumetech.com/
Author, Java 3D FAQ Maintainer                  http://www.j3d.org/
-------------------------------------------------------------------
"Humanism is dead. Animals think, feel; so do machines now.
Neither man nor woman is the measure of all things. Every organism
processes data according to its domain, its environment; you, with
all your brains, would be useless in a mouse's universe..."
                                               - Greg Bear, Slant
-------------------------------------------------------------------


----- End forwarded message -----

-- 
Alex Chaffee                               mailto:alex@jguru.com
Purple Technology - Code and Consulting    http://www.purpletech.com/
jGuru - Java News and FAQs                 http://www.jguru.com/alex/
Gamelan - the Original Java site           http://www.gamelan.com/
Stinky - Art and Angst                     http://www.stinky.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message