fastutil
fastutil extends the Java Collections Framework by providing type-specific maps, sets, lists, and queues for Java with a small memory footprint and fast access and insertion; it also includes a fast I/O API for binary and text files. The classes implement their standard counterpart interfaces (e.g., Map for maps) and can be plugged into existing code. Besides the usual features, fastutil provides reference-based containers (which do not use equals() to compare objects) and linked structures. Most iterators provided by fastutil classes are bidirectional, or even implement the standard list iterator interface.
| Tags | Software Development Libraries Java Libraries |
|---|---|
| Licenses | LGPL |
| Operating Systems | OS Independent |
| Implementation | Java |
Recent releases
- 12 Jun 2008 12:35
Changes: An issue where the isEmpty() method of ArraySet was actually returning ! isEmpty() was fixed. A new constructor for FasyMultiByteArrayInputStream makes it possible to pass a MeasurableInputStream.
- 16 Apr 2008 08:18
Changes: A pernicious bug in FastByteArrayOutputStream was introduced in the last version, and has been fixed.
- 02 Apr 2008 09:43
Changes: A few bugs have been fixed. There is a new set of type-specific Iterable classes.
- 16 Feb 2008 15:37
Changes: New fast iterators with mutable entries and a whole hierarchy of function interfaces were added.
- 24 Mar 2007 11:48
Changes: New methods for reading bytes use stream bulk-read method, but with a workaround for a Java bug.
- All comments
Recent commentsRe: Library partitioning
> Anything is better than the huge 15.3MB
> jar. Since we'll be using webstart to
> deploy our thin clients the extra 15MB
> is definately not an option ;-P.
However, you should look into AutoJar:
http://www.rrz.uni-hamburg.de/RRZ/B.Eggink/en/javatools/autojar/
which is written exactly to solve your problem!
Re: Library partitioning
> Well, I understand the problem, but it
> is not that easy.
>
> My current plans for 3.0 (beside a
> *fantastic* type-specific ArrayList
> library 8^) include changing the
> namespace to fastutil.int, fastutil.long
> etc. At that point I could make some
> separate jars. The problem is that then
> you must include ALL those jars in your
> path.
>
> Maybe separate jars with an option to
> get a global jar is the best idea.
> Comments are welcome...
Anything is better than the huge 15.3MB jar. Since we'll be using webstart to deploy our thin clients the extra 15MB is definately not an option ;-P.
Good to hear that you plan to add List support too! I had to write one myself since we also need to store loads of longs somewhere and just by using homemade specialized container saves memory + it performs much better. Long object = 12 + 8 bytes, long primitive 8 bytes. Makes big difference with big datas..
If only Sun would have extended the upcoming generics to primitives also!
Re: Library partitioning
> Could you provide partitioned library in
> the future? I benchmarked the
Well, I understand the problem, but it is not that easy.
My current plans for 3.0 (beside a *fantastic* type-specific ArrayList library 8^) include changing the namespace to fastutil.int, fastutil.long etc. At that point I could make some separate jars. The problem is that then you must include ALL those jars in your path.
Maybe separate jars with an option to get a global jar is the best idea. Comments are welcome...
Re: Library partitioning
And BTW:
Thx for the great library!
Library partitioning
Could you provide partitioned library in the future? I benchmarked the implementations for my application and found that the Long2ObjectAVLTreeMap was best for my needs. It took me three hours of testing, zipping and unzipping to extract only those classes that I needed (The original is huge 33MB jar and my modified jar is only 55KB)
Another way is that you could somehow specify the required implementations in the build phase?
Any comments?