Newsletter sign-up

Sign up for our technology specific newsletters.

	Enterprise Java
View all newsletters

---

Email Address:

Readers ruffled by JGL vs. Collections API bias

Readers take <em>JavaWorld</em> to task for biased phrasing of poll question

By Jenni Aloi, JavaWorld.com, 08/01/98

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.