Cartoon by profiler: adding RAM to the computer
The JavaPerformanceTuning.com cartoonist provides his graphic description of another performance tuning technique

Linux MIDI: A Brief Survey, Part 2
In part two of this ever-expanding MIDI series, a look at various sequencers, from Rosegarden to seq24.

Product of the Day: MPP - Message Processing Platform
The following information has been provided by the product vendor and does not necessarily reflect the opinion of Linux Journal.

[ 27 Sep ][ Article ]: NetBeans IDE 4.0 Tag Library Tutorial
A guide to learning about the enhanced JSP 2.0 support for tag libraries in NetBeans IDE 4.0. This tutorial lets you use wizards that are new in NetBeans IDE 4.0 to create tag handlers, tag files, and tag library descriptors. Then, you develop your tags either in the Java programming language or in the syntax for the JavaServer Pages technology, or both. This tutorial can be completed in 30 minutes.

JDBC RowSet Implementations Tutorial (PDF)
This tutorial explains how to use the standard JDBC RowSet implementations that are provided as part of J2SE 5.0. Get up to speed with each RowSet definition and benefit from improved scalability and robustness.

Getting Started With the Mobile 3D Graphics API for J2ME
This tutorial introduces the Mobile 3D Graphics API for J2ME, JSR 184. The article presents an overview, potential application areas, the differences between JSR 184 and two related APIs, the classes in the new optional package, the programming model, the reference implementation, and some programming examples.

Five Reasons to Move to the J2SE 5 Platform
Five important reasons to move to the Java 2 Platform, Standard Edition (J2SE platform) 5.0, supported by data and references to prove that the 5.0 release will reduce development and runtime costs.

Refactoring in real life
Throwing stuff away

Swing: Why Does Everyone Want Everything In The "Core"?

Tonight I've been reading way too many forum posts about threading while working on Desktop Java Live's chapter on the subject. A common theme that kept coming up with threading and other related topics was ... "When is this gonna be in the core?"This got me to thinking. Why is putting something in the core JRE such a magical thing? The possible pros I came up with are:

Reduced Application Size
In essence the size costs of an application would be more front loaded to the initial JRE install if components/utilities were moved into the core. This would greatly benefit applications that are deployed with Java Webstart for instance.

Compatibility with Other Core Features
The case I saw presented for this argument was Date Picker components. The argument was that if one was in the core JRE it would match all of the Sun supplied look and feels out of the box.

Eliminate Duplication of Effort
With items in the core, you wouldn't have the same people solving the same issues repeatedly.

Awareness of Components/Features
More people would be introduced to components/utilities if they were a part of the JRE.

Now the cons I see with those pros:

Reduced Application Size
Requiring certain JRE features binds you to a specify JRE version or above. For instance if you use the new java.util.concurrent package you can't use Java 1.3. If you use Doug's original threading utilities you aren't tied to the lastest and greatest Java version.

Compatibility with Other Core Features
I don't buy compatibility at least in the example above as a good argument. What would be really going on is that either Sun would make sure that everything is compatible or that whatever process for migrating code to the core would enforce such compatibility. So you in essence would have a process to facilitate that lazy programmers make sure all their i's are dotted and their t's are crossed.

Eliminate Duplication of Effort
There is some validity to this argument. However, reducing duplication of effort can also be achieved at some levels with the next point of awareness.

Awareness of Components/Features
Again, there is some validity to this point. However, I still find things in the JRE that I didn't know were there. It should also be the responsibility of a good programmer to be as aware as possible of tools that can help them in their day to day activities.

Now tying all of this all back in with Swing ... The comparison I see to all of this is the J2EE Space. There is a certain amount of fighting over specs like JDO/EJB (let's not open up that war anymore here) but no one is screaming for J2EE to be built into the JRE. Stepping a little further away, no one is asking for Struts to be a part of J2EE. Yet people want layout managers and threading solutions as a part of Swing. I wonder how much of this is due to Swing being in the core. What if Swing itself had always been separate?