Generic types
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. The oldest of the planned changes to the core Collections Framework is support for parameterized data types, also called generics, or templates. 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:
public static void main(String args[]) {
List<String> listOne = Arrays.asList(args);
List<String> listTwo = new ArrayList<String>(listOne);
}
In a more complicated case, you can pass types into class definitions so a data type internal to the class can be generic:
class Node<T> {
T value;
Node (T value) {
this.value = value;
}
T getValue() {
return value;
}
void setValue(T value) {
this.value = value;
}
}
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.
JGL 4.0
It is JGL's new release. It seems that, Recursion Software is giving it another set out. The company claims a user base of more than 250,000.The new release has three primary differences from the previous 3.1 version:
1. All the interfaces and classes are integrated into the Collections Framework, and like the Collections Framework, all implementations are unsynchronized by default.
2. The package namespace has changed from com.objectspace.jgl to com.recursionsw.jgl.
3. The Voyager-related capabilities are gone.
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. It is not a serious thing since JGL is now part of that framework.
Concurrency utilities
Following internal and external reviews of the proposed concurrent utilities library, JSR 166 is projected to be included in JSR 176 i.e. Java 1.5, dubbed Tiger for those interested in participating in the library's inner debate.
The Java core libraries will offer such capabilities as a non blocking queue, atomic variables, some specialized locking and timing mechanisms, concurrent collections similar to the Commons Collections' Fast Array List and related classes, and some interesting mechanisms to install per-thread handlers for uncaught exceptions, instead of relying on the Thread Group by assuming acceptance of JSR 166 and inclusion with the next Java release. This is not an all-inclusive list, and it's subject to change until JSR 166 is concluded.
Conclusion
The core Collections Framework is the first thing you have to learn if you want to use abstract data types in your programs. Everything else is built upon it, even the proposed JSRs.
You can branch out to other areas once you learn the basic collections classes. While you can play with the generic-types 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 multi map. 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 the majority group.
JGL isn't free at 9.95 per developer. 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. In most cases, you just don't need JGL or the Commons Collections classes. It is so much and enables us to do a lot.
