Académique Documents
Professionnel Documents
Culture Documents
Sponsored by:
http://www.javaworld.com/javaworld/jw-11-2002/jw-1101-collections.html
4/13/13
http://www.javaworld.com/javaworld/jw-11-2002/jw-1101-collections.html
structure support, Doug Lea abandoned his c o l l e c t i o n spackage and started work on a second library of utility classes. This new package was designed to improve concurrent or multithreaded access to various data structures. Released in July 1998, these classes were called u t i l . c o n c u r r e n tand offered locking, pooling, and concurrent access support (see Resources). Along comes the Java Collections Framework J2SE 1.2 was released in December 1998 and included a set of classes called the Java Collections Framework for manipulating data collections. Early comparisons pitted JGL against the Collections Framework (see Resources), even though the two were meant to serve different purposesJGL was an STL replacement, and the Collections Framework was not. Former C++ developers tended to use JGL because JGL's sheer size required a steep learning curve that came more natural to those already familiar with the STL. JGL had approximately 130 classes and interfaces while the Collections Framework was about 20 percent of that size. Another alternative, the Jakarta Commons Collections component, was released in July 2001, which extended J2SE 1.2 APIs with specialized abstract data types and new methods to test set theory. A second version was released in April 2002, adding even more specialized implementations. Not much changed between the initial release of the Collections Framework and J2SE 1.4's release beyond the addition of a few more classes and interfaces. Support for generic types (i.e., templates) was debated with JSR (Java Specification Request) 14 but didn't make it into the J2SE 1.4 release. JSR 14 released a working prototype for generic-types support, but it is only targeted at the developer community and is unsupported (see Resources). JSR 166 was introduced this past January. Led by Doug Lea, this is a community effort to incorporate much of the high-level concepts in his previously mentioned u t i l . c o n c u r r e n tlibrary into the Java core libraries. Little was heard from the folks at ObjectSpace with regard to JGL until the day before J2SE 1.4's release when a company named Recursion Software announced its acquisition of JGL and related ObjectSpace product lines. Then, in July 2002, Recursion Software released JGL 4.0, integrating JGL collections and algorithms with the standard Collections Framework. That brings us to today. Now available are the following pieces: The Collections Framework, a part of the Java core libraries that defines key interfaces to be shared by all data structure implementations The Jakarta Commons Collections component, freely available under the Apache Software License JGL 4.0 Generic-types support, available as a prototype for JSR 14 Two nonstandard libraries from Doug Lea, evolving into a core standard with JSR 166
Let's examine each of these and consider when you might use them.
4/13/13
http://www.javaworld.com/javaworld/jw-11-2002/jw-1101-collections.html
AC o l l e c t i o nis the base interface for sets and lists. It describes a generic group of elements with no particular characteristics. There are no direct implementations of C o l l e c t i o n , only sub-interface implementations. AS e tis a collection of items that do not support duplicates. There are two standard S e timplementations: H a s h S e t and T r e e S e t ;T r e e S e tis sorted and also implements S o r t e d S e t . The L i s tinterfaces are for ordered collections, offering either indexed or sequential access. L i s timplementations include A r r a y L i s tand L i n k e d L i s t ;A r r a y L i s treplaces the original V e c t o rclass.
M a pdescribes collections of key-value pairs,
similar to H a s h t a b l e . Available maps are H a s h M a pand T r e e M a p ; T r e e M a pis sorted and also implements S o r t e d M a p . J2SE 1.4 introduced two new implementations: L i n k e d H a s h S e t and L i n k e d H a s h M a p , for maintaining insertion order while needing constant times for operations like adding, searching, and removing. Another J2SE 1.4 implementation is I d e n t i t y H a s h M a p , which uses = =instead of e q u a l s ( )for equality checking operations. For those interested in weak references, yet another map, W e a k H a s h M a p , is available that uses W e a k R e f e r e n c efor the keys, therefore dropping the key-value pair if the only reference to the value is through the key. These elements form the basic framework. By design, the framework is not thread-safe. Safe simultaneous access from multiple threads requires you to wrap the collection with a thread-safe wrapper. Similar wrappers exist for read-only versions of the collections. While the Collections Framework is relatively small, it is not meant to provide support for every data structure needed. Instead, it is only the framework from which you can build more specialized implementations.
provide key-value pairs based on JavaBean properties; the key is the property name,
3/6
www.javaworld.com/cgi-bin/mailto/x_java.cgi?pagetosend=/export/home/httpd/javaworld/javaworld/jw-11-2002/jw-1101-collections.html&pagename=/javaworld/jw-
4/13/13
http://www.javaworld.com/javaworld/jw-11-2002/jw-1101-collections.html
the j a v a . u t i l . P r o p e r t i e sclass that concatenates multiple values for a single property, instead of overwriting it. L R U M a pis a M a pthat lets you maintain a maximum capacity and uses a least-used (accessed) algorithm to determine which node to remove when full. This capability is already accessible from the standard L i n k e d H a s h M a pclass, but is only available with J2SE 1.4 .
S o f t R e f H a s h M a pworks like W e a k H a s h M a pbut uses S o f t R e f e r e n c einstead
of W e a k R e f e r e n c efor its keys. M u l t i H a s h M a pprovides a multimap, where keys can have multiple associated values. Fetching the value for a key returns a C o l l e c t i o ninstead of the specific value for the key. D o u b l e O r d e r e d M a pis the most interesting of the bunch. It provides a M a pthat supports fast lookup by value and by key. It has one requirement though: both keys and values must be unique. You can do this with two T r e e M a pobjects, but D o u b l e O r d e r e d M a ponly saves each key-value pair once.
Other classes and interfaces serve mostly supporting roles, but some specialized behavior is available. Besides utility methods to work with sets like i s S u b C o l l e c t i o nand u n i o n , the framework includes additional C o m p a r a t o r s and I t e r a t o r s. The C o m p a r a t o r s are used mostly for chaining or changing another C o m p a r a t o r 's behavior. For instance, while j a v a . u t i l . C o l l e c t i o n s . r e v e r s e O r d e r ( )lets you reverse the natural order of elements, the R e v e r s e C o m p a r a t o rclass lets you reverse the order from any C o m p a r a t o r . The I t e r a t o r s support the process of passing each C o l l e c t i o nelement to a function (method) before getting the element back. This is a shared behavior of JGL and STL too.
JGL 4.0
Without any updates since 1997, JGL's new release caught me by surprise. I thought JGL was for all intents and purposes dead. Apparently, Recursion Software is giving it another go. The company claims a user base of more than 250,000, but I haven't heard of anyone using it for some time. The new release has three primary differences from the previous 3.1 version: All the classes and interfaces are integrated into the Collections Framework, and like the Collections Framework, all implementations are unsynchronized by default The package namespace has changed from c o m . o b j e c t s p a c e . j g lto c o m . r e c u r s i o n s w . j g l The Voyager-related capabilities are gone
If you are unfamiliar with JGL, see the JavaWorld article (June 1997) in Resources. Not much has changed with the new release. However, the library now works only with J2SE 1.3.1 and 1.4, and you can mix and match the standard Collections Framework with JGL capabilities. JGL provides several abstract data types and algorithm support as separate pieces. It supports more than 50 algorithms compared to the Collections Framework's 18. I'm not sure why anyone would want to learn two different frameworks from scratch, but one benefit is that those still using JGL can transition their applications to the Collections Framework in pieces, instead of all at once. JGL may still be more familiar to C++ developers learning Java than the Collections Framework, but since JGL is now part of that framework, this shouldn't matter.
www.javaworld.com/cgi-bin/mailto/x_java.cgi?pagetosend=/export/home/httpd/javaworld/javaworld/jw-11-2002/jw-1101-collections.html&pagename=/javaworld/jw- 4/6
4/13/13
http://www.javaworld.com/javaworld/jw-11-2002/jw-1101-collections.html
Generic types
The oldest of the planned changes to the core Collections Framework is support for parameterized data types, also called generics, or templates. Right now, all collections are not type-safe. You can add any object into the collection, and, when you get an element out, you must cast it to the appropriate data type. You don't know until runtime if you are getting out of a collection the type you expect. JSR 14 proposes the ability to provide type-safe collection access. In the simplest case, you just pass the data type along with the class name to make the collection the right type:
p u b l i cs t a t i cv o i dm a i n ( S t r i n ga r g s [ ] ){ L i s t < S t r i n g >l i s t O n e=A r r a y s . a s L i s t ( a r g s ) ; L i s t < S t r i n g >l i s t T w o=n e wA r r a y L i s t < S t r i n g > ( l i s t O n e ) ; }
In a more complicated case, you can pass types into class definitions so a data type internal to the class can be generic:
c l a s sN o d e < T >{ Tv a l u e ; N o d e ( Tv a l u e ){ t h i s . v a l u e=v a l u e ; } Tg e t V a l u e ( ){ r e t u r nv a l u e ; } v o i ds e t V a l u e ( Tv a l u e ){ t h i s . v a l u e=v a l u e ; } }
The exact syntax for generic-types support and whether it will be incorporated into a future J2SE release (perhaps J2SE 1.5) is still to be determined. But you can generate class files today that will work with any J2SE 1.3 runtime environment. You don't have to wait for J2SE 1.5 to try the JSR 14 prototype (see Resources).
Concurrency utilities
I previously mentioned two libraries from Doug Lea: c o l l e c t i o n sand u t i l . c o n c u r r e n t . The latter is a first cut at the new library envisioned by JSR 166. Following internal and external reviews of the proposed concurrent utilities library, JSR 166 is projected to be included in JSR 176 (Java 1.5, dubbed Tiger). For those interested in participating in the library's internal discussion, see Resources. Assuming acceptance of JSR 166 and inclusion with the next Java release, the Java core libraries will offer such capabilities as a nonblocking queue, atomic variables, some specialized locking and timing mechanisms, concurrent collections similar to the Commons Collections' F a s t A r r a y L i s tand related classes, and some interesting mechanisms to install per-thread handlers for uncaught exceptions, instead of relying on the T h r e a d G r o u p . This is not an all-inclusive list, and it's subject to change until JSR 166 is finalized.
Last notes
www.javaworld.com/cgi-bin/mailto/x_java.cgi?pagetosend=/export/home/httpd/javaworld/javaworld/jw-11-2002/jw-1101-collections.html&pagename=/javaworld/jw- 5/6
4/13/13
http://www.javaworld.com/javaworld/jw-11-2002/jw-1101-collections.html
If you want to use abstract data types in your programs, the first thing you must learn is the core Collections Framework. Everything else is built upon it, including the proposed JSRs. Once you learn the basic collections classes, you can branch out to other areas. While you can play with the generictypes support now, you must wait for its final form and the concurrency libraries in J2SE's next version. If you find the Jakarta Commons Collections helpful, by all means, use it. You can avoid creating a commonly used structure like a multimap. While a first-year Computer Science student can handle such a task, the fact that it is already created and debugged is beneficial. The Apache license shouldn't be an issue for most people. At 9.95 per developer, JGL isn't free. And you need to grasp how the entire library works before you can really use the individual pieces. While it's possible to mix and match JGL and the Collections Framework, it might not be the best thing to do. Generally speaking, JGL just offers an alternative to Java's core libraries. I'd go with the optimized code of the main Java classes rather than wrap a third-party library around my collection to do the same tasks. Yes, JGL supports more algorithms, and some may be useful, but many are not. For example, how frequently do you need to negate an entire collection of integers at once? JGL may be helpful for new Java developers transitioning from C++; but for those already programming in Java or those interested in being Java-certified, just stay on top of the standard Collections Framework capabilities. In most cases, you just don't need JGL or the Commons Collections classes.
www.javaworld.com/cgi-bin/mailto/x_java.cgi?pagetosend=/export/home/httpd/javaworld/javaworld/jw-11-2002/jw-1101-collections.html&pagename=/javaworld/jw-
6/6