|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 4 of 4
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:
com.objectspace.jgl to com.recursionsw.jglIf 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.
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:
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 (see Resources).
I previously mentioned two libraries from Doug Lea: collections and util.concurrent. 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' FastArrayList and related classes, and some interesting mechanisms to install per-thread handlers for uncaught exceptions, instead of relying
on the ThreadGroup. This is not an all-inclusive list, and it's subject to change until JSR 166 is finalized.
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 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 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.