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?
Previous Topic
