Readers ruffled by JGL vs. Collections API bias

Readers take JavaWorld to task for biased phrasing of poll question

No matter what the topic, we at JavaWorld come under fire for our polls: whether it's for biasing the question, daring to mention Microsoft, or asking the wrong question altogether, we take the heat. This particular poll generated more than the usual number of flames -- and most of them were entirely justified.

We deliberately phrased last month's question ("Should Sun scrap its Collections API in favor of the more robust JGL?") to reflect a widely held perspective (okay -- bias) regarding the collections libraries. Unfortunately, our phraseology extended beyond plain, objective facts. Perhaps a stronger question would have asked if Sun should adopt or incorporate some of the more worthwhile JGL features, such as predicates and algorithms.

Of course, hindsight is 20/20, but if we didn't know it before, we know it now: Per our readers, future JavaWorld polls will make an effort to be bias-free (or as nearly-there as we can make them).

With that in mind, a majority of readers did express a desire to see JGL incorporated into Java. Luckily for us, many pro-JGL readers took the time to justify their point of view (beyond "JGL rocks") in the Comments section of the poll. So, while the poll is informal, it does provide meaningful feedback for the Java community -- on both sides of the fence.

Let's take a look at the actual voter break down:

  • 67% said Sun should scrap its Collections API in favor of JGL

  • 17% said Sun should not scrap its Collections API in favor of JGL

  • 15% were unsure, or didn't have a strong opinion

Here's a sampling of reader comments. To see more reader feedback on this topic, check out this month's Letters to the Editor section. Don't forget to voice your opinion in our latest poll.

Sun should scrap its Collections API in favor of JGL (67%):

While I vote for JGL, it does have some confusions added in porting the ideas from STL. The general double-iterator and algorithms scheme of STL/JGL is far superior to the Java Collections scheme.

Why reinvent the wheel? Sun's Collections API looks great. In a couple of small cases, it looks like it might even be an improvement on JGL. (I haven't looked at it that closely; though I'm quite familiar with basic JGL.) JGL is out there and in use, and it works now; why not simply license and expand on JGL where it could use expanding?

I've been following JGL news for over 6 months now, and am impressed with the breadth, quality, and support of JGL. ObjectSpace has done a great job, and Sun could do itself and the rest of us a favor by adopting it. The Collections API has a long way to go before it matches JGL, so why waste the effort on it? Even if it gets completed on time, there will be compatibility problems, and no clear advantage that I can see so far. It's time to adopt JGL.

It would be in Sun's best interest to embrace outside APIs as much as possible, especially when the outside technology has become a de-facto standard. (1) We would get the best technologies for Java and (2) It would help avoid fragmentation.

I have actually e-mailed this very suggestion to Sun in the past. The Java API "standards" have been decided way too early in many cases. These things need time to mature, and a few options should compete in the free market before one is designated as the standard. Sun has done a remarkable job. Swing is a fantastic API (although effectively a second attempt) and RMI was quite well thought out. I'm concerned about the Telephony API and some others that have no real work experience or other work to compare to. The Collections API was clearly inadequate from the beginning and JGL just blows everything else away.

JGL has its roots in C++'s STL. A la STL, JGL's containers and algorithms follow a very logical (orthogonal) definition, which greatly helps in reducing the learning curve. JGL is here, it works very well, and, while there may be potential for a better library, it will inevitably be years more before it's completed and adopted in day-to-day programming. Yes, include JGL as part of the Java language.

I use JGL daily in my work. When first presented with the opportunity, I tried using the Collections API, but I found it didn't have many of the niceties of JGL.

I think JGL is far superior in most respects. However, Sun's API has one advantage over JGL: you have a choice of whether or not you want a thread-safe interface, and can choose whether or not you want the performance hit that such an interface implies. JGL enforces thread safety in all collections by default: all methods are synchronized and you have a performance hit in all cases.

The Collections API is inadequate, and my comments to the developers have been met with ignorance and arrogance. Until Sun is able to do it properly, it would be better off using a third-party package.

The JGL is more comprehensive than Sun's collection classes and since most of JGL's classes are out, users could really start using them as definitive utility library.

JGL is much cleaner, more flexible and more powerful than JavaSoft's Collections API. For starters, where are the function objects in Collections? Function objects (and predicate objects) are 80 percent of the power of JGL.

As the lead developer of JGL, I'd like to mention that JGL was designed from day one to be integrated into the JDK and to complement the existing collections such as Vector and Hashtable. ObjectSpace has been, and will continue to be, very enthusiastic about any move to integrate JGL into the JDK. It has been very enjoyable to see the widespread adoption of JGL by the Java developer community. The only criticism of JGL that I've really seen is that it is too grounded in C++ and not suitable for use with the Java language. I think this is just plain wrong. As one of the developers of ObjectSpace's C++ STL <Toolkit> product, I was very careful to craft JGL to be in the spirit of Java while retaining the powerful philosophical backbone of C++'s STL. As a result, Java programmers have access to a high performance set of easy-to-use containers and algorithms while C++ programmers can migrate their collections and algorithms code to Java with very little effort.

Graham Glass, Chief Technology Officer, ObjectSpace Inc.

Sun should not scrap its Collections API in favor JGL (17%):

We've received many, many unsolicited testimonials as to the power and ease of use of this [Collections] API, from programmers and educators worldwide, including many leading practitioners in the field.

Josh Bloch, Collections Architect, Sun Microsystems, Java Software Division.

The JGL library is an important piece of work in the Java community. However, there are some fundamental differences between JGL libraries and the Java built-in classes -- i.e., the ability to test for object equality and method naming conventions -- which I think would make JGL's integration in the core libraries clumsy. JGL evolved from C++'s STL classes, which is probably not the approach pure-Java developers would prefer. I would love to see ObjectSpace and Sun collaborate in some way to use JGL technology inside of the Collections API, but I believe that Sun should continue on its course of developing the API specifically for the Java platform.

JGL is a fine package, but not perfect. Neither is the Collections interface. ObjectSpace should work with Sun to improve the Collections interface and provide an excellent implementation.

There aren't all that many comprehensive collections libraries for Java on the market, so it shouldn't be surprising that JGL has a relatively large share of users. Variety and competition is what promotes quality -- JGL proponents should quit whining over a collection that is hardly best-of-breed. JGL is more suitable for former C++ programmers and an alternative collection library is quite desirable.

Sun's Collections API will not go away, so it's futile to put up a fight. But a JGL conforming to the Collections API would make everyone happy. This option should really have been a possible answer in the poll!

I've been using the JGL to address certain specific common needs (my 90 percent cases are a Set type and a generic sorting algorithm), but I find it to be bloated and messy. The JDK collections API, in contrast, is a pleasure to use. It has interfaces for each common collection type (set, list, map, etc.), which the JGL has only partially; it has an explicit (if rather weak) concept of immutability, which the JGL lacks entirely; the Comparable and Comparator interfaces allow the developer to express object equality for sorting purposes, which JGL's BinaryPredicate, annoyingly, does not; and the whole API is much smaller and more manageable than the JGL. JGL will continue to be very useful as a generic-algorithms library, going well beyond what the JDK should provide, but as a core collections library I think the JDK is clearly preferable.

I try to restrict myself to Sun's classes and my own classes, so I want Sun to finish the Collections API.

The primary reason for not using JGL is that the oldest de-facto collections, Vector and Hashtable, are not transparently compatible with JGL. However, JavaSoft should add the algorithms and predicates concepts to the standard Collections API.

I think the Java Collections model is appropriately lightweight, doesn't carry JGL's STL baggage, and just seems a better fit for general purpose collection management. JGL is great, but seems like overkill for many projects, and should continue to evolve separately as a more full-featured heavyweight traditional solution.

While JGL is a very useful and well-engineered collection of collection classes, Sun's collections API is a lightweight set of interfaces. So they have different purposes and I think both have their place.

JGL is a very powerful collection of data storage and manipulation classes, but this is also its weakness; it is overkill for simple tasks. I once wanted to sort an ordinary java.util.Vector -- I needed to include nearly twenty JGL classes to do this! My conclusion is: JDK collections are perfect for everyday use, while JGL is good for special operations. Moreover, ObjectSpace promises to build its new JGL 4.0 around JDK 1.2 and make the two interoperate smoothly.

Don't know/No Opinion (15%):

I haven't tried JGL, but I do have some concerns about the Sun Collections API

JGL has a lot going for it, but I'm concerned at the level of support given by ObjectSpace lately. Until this year, there was an active mailing list with timely and useful ObjectSpace participation; now the list has apparently died. There was also a promised JDK 1.2 integration that has yet to appear. Several ill-fitting JGL changes were made to the API in an effort to push the Voyager product. Voyager seems to dominate ObjectSpace these days, to the detriment of its other products. I like a lot of the JGL features better than the JDK equivalents, but leaving it in the hands of ObjectSpace concerns me.

Why not take the best of both worlds?

This largely depends on the ability to implement persistent and other "database-oriented" implementations of the JGL collections. Performance and robustness is important, but it's also important that collections can be used for things other than strict "in-memory" data structures.

I don't know, but I do have an opinion. Simplicity is the goal of the new JDK 1.2 Collections API, so people can understand and use it. I assume that the JGL is less simple, but I presume there are a few simple work-horse classes that can be used regularly. If not, the 1.2 collection is needed. If so, making JGL part of base Java makes sense.