Skip to main content

Fooling Yourself (The Angry Young Man)

Posted by editor on February 27, 2009 at 9:11 AM PST

Questioning the value of a "Swing 2"

Background: with parts of the Swing community concluding that Sun's emphasis on JavaFX implied a de facto abandonment of Swing, Jonathan Giles posted ideas last month for a Swing 2.0, a cleanup that would modernize the code-base to at least Java 5 standards: generics for collections, enums for enumerated constants, etc., without taking on the additional work of delivering significant new functionality. Danny Coward's reply focused instead on the improvements to the SE platform that will be of critical importance to Swing developers: graphic performance improvements, robust deployment, etc.

Elliott Hughes follows up to the "Swing 2" blog by writing:

Danny Coward responded but appears to have been too polite to get the point across.

That's where I come in.

His blog Swing 2: P-----g in the Wind [title redacted] is a thorough denunciation of Jonathan's proposal as off-the-mark and pedantic:

I've written and worked on numerous Swing applications now, and can honestly say that none of the ideas mentioned so far for the third-party "Swing 2" would have helped in any way.

The gist of Elliot's argument is that the proposed clean-up is of solely academic interest: it wouldn't make Swing code easier to write, work better, or enable developers to do things they can't do already. On the latter point, he clearly implies that Swing is crippled by lacking "functionality that was old hat even in the days of Windows 95", naming about boxes, font dialogs, and an embeddable browser component as glaring and obvious deficiencies of Swing's feature set.

There's a lot of tough love in here, and it comes from someone who actually uses Swing. In a sense, it reminds me of a comment on the O'Reilly Editors' list a few weeks back, that the Linux community should be grateful for the Linux Hater's Blog, as it's written by someone who knows Linux and cares enough to see its flaws for what they are, rather than a fanboy who pretends Linux is perfect, or fanboys of other platforms hurling insults with no basis in fact.

Swing people know best what Swing needs. Do they get a say?

In Java Today,
The Aquarium points out a New JCP JSR Status: Inactive, which the JCP has applied to "non-final JSRs that have not posted a milestone within the last 18 months." Eduardo Pelegri-Llopart notes, "The JCP pages have already been updated; check out the JSRs by Stage and the full list of Inactive JSRs. The list includes JSRs led by large and small companies, Sun and non-Sun. Some of the JSRs are very old, some just break the 18-month boundary."

For playing around with JavaFX, A. Sundararajan points out the availability of a JavaFX interactive shell: "JavaFX compiler has a built-in script shell - Per Bothner has implemented a read-eval-print loop facility for JavaFX. The script shell class is
Note:This is in the openjfx-compiler repository and not in the JavaFX 1.0 binary."

In today's Weblogs, Rama Pulavarthi updates the
JAX-WS RI 2.2 Status. "Its been a long time I blogged. You might be wondering what we are up to with JAX-WS RI lately. We are busy implementing the JAX-WS 2.2 RI."

In Atmosphere: state of the union, Jean-Francois Arcand writes, "The goal of Project Atmosphere is to bring Comet to everyone, everywhere. What the status of the project? Read on..."

Finishing up his series on game board modeling, Sergey Malenkov shows the math behind the Hexagonal tile map. "To supplement the posts about the triangular and square tilings, let's consider the third type - the hexagonal tiling. This is my favorite one. Each hexagon has more non-diagonal neighbors than a square. It simplifies calculating distance between two tiles. The main disadvantage of this tiling is that the axes are not orthogonal."

Inspired by a forum post on ME behavior on real-world devices, the latest Poll asks "are complaints about ME fragmentation overblown?" Cast your vote on the front page, then visit the results page for current tallies and discussion.

In today's Forums, Potociar Marek uses the followup Re: Architecture: WSIT Integration into Metro to explain what Metro is and isn't reponsible for. "The Metro processing tubeline is based on the chain of filters/ interceptors design pattern. Still, it is orthogonal to the notion of JAX-WS SOAPHandler. Metro processing tubeline is the heart of "streamlined" SOAP message processing concept in Metro. As such it is a Metro-specific implementation detail and has no connection to JAX-WS API or specification. To dive a little deeper, one of the tubes which is a part of the Metro tubeline is a HandlerTube which is responsible for invoking registered JAX-WS SOAPHandlers. So basically all JAX-WS handler processing takes place at one single predefined place in the whole Metro tubeline. You can view JAXWS handlers as a high-level and portable API for processing SOAP messages, while Metro tubes are non- portable, low-level (but very flexible and powerful) SOAP message handlers/processors."

ksak explains what happens when your EJB throws an exception in
Re: GlassFish Cannot Find SFSBs After a RuntimeException. "This is the spec-defined behavior for stateful session beans. Each injection of a stateful session bean reference results in a new stateful session bean identity. Here, the "client" is the servlet instance itself, of which there is typically only one per web application. If the bean instance throws a runtime exception the container must destroy it, which means any other invocations on its reference will result in NoSuchEjbException. This is one reason it's not recommended to inject a stateful session bean into a servlet instance."

Finally, Vince Kraemer offers GlassFish tooling advice in
v3 and NetBeans 6.7 M2. "Folks may know that the NetBeans project just published version 6.7 Milestone 2 which is available here: Folks may not know that it is easy to start doing Java EE 5 development against recent v3 promoted builds by using the information that you can find here: Please give it a try."

Current and upcoming Java

Registered users can submit event listings for the href=""> Events Page using our href="">events submission form.
All submissions go through an editorial review before being posted to the

Archives and Subscriptions: This blog is delivered weekdays as
the Java
Today RSS feed
. Also, once this page is no longer featured as the
front page of it will be
archived along with other past issues in the href=""> Archive.

Questioning the value of a "Swing 2"


Swingx is the only project i can see that even HAS a unified vision of the problems with swing. Varargs, generics ... that is the small stuff, especially if you don't care about compatibility (like swingx tries to).

"Swing is one of the widest used desktop toolkits" That my friend is precisely why Swing is irrelevant... "Desktop" is no longer of interest to 99% of the programmers on the planet.

Yes Swing needs to be updated to new language features! I see this s a first step to build a community working on Swing and bringing all the features Elliot misses. If Sun has no interest in going on with Swing any longer this is for sure the best solution: Swing is already quite good and the bad parts will be fixed by the community, so Swing will be living on. I am not interested in using a special language just for UI programming and I do not believe that Flex or any imitator is useful for serious desktop programing. If I want to do sophisticated web interfaces I use GWT. I really can not see what Java FX could be good for. But look at the price: Swing and Java3D, used by thousands of developers where cancelled. Swing is one of the widest used desktop toolkits and as compared to other toolkits I think it is quite good, why cancel that? Just because some scripting kiddies say it is too complicated? A Swing without bugs and the features Elliot talks about would have been way more easy to achieve and useful than yet another toolkit and even one you need a special language for. Maybe someone at Sun will understand someday that designers are not interested in using a programming language, even if it is its in part declarative. They'll use Flex, because of the Adobe software available for its creation. I think a Swing fork is the only solution to what Sun is now doing (or using SWT would be another possibility) and an updated API is the first step to it. And I also hope that there are enough community developers to overtake Java3D, while Sun goes on to waste its constrained developer power for something else. And by the way there is one final point where I fundamentally disagree with Elliot: I like the Nimbus LAF. Just some bugs are annoying.

I am also a proponent for Swing to be updated to current language features. It does get quite frustrating mixing 'old school' code in with the current. What is so wrong about updating the API so that it becomes more cohesive to the way we code? Forget about distribution for a new Swing 2.0 jar file (complaints of more bits to downlaod), isn't that what the new Java Kernel is for? But forget about that. Just create a new project and call it swing 2.0. It doesn't have to replace the old swing code (yet). But, I for one am getting tired of technology being stifled due to the outrageous demands of 'forever forward compatibility'. We don't need to replace swing; just create a new one and call it a day. Another thought... If java has really gone the route of open source, why can't we as developers just do it? We really don't need Sun to provide this for us. Aren't there a few java peeps out there willing to pick up some packages an roll with it? Of course there has to be some sort of limited process (so this doesn't take 3 years) so that we can agree on the changes, but does anyone think we should start with those darned lists and table models? Anyway, those are just my thoughts.

Agreed the only way I can see them not being "at all useful" is if you've refused to use collections, generics, enums and vargs in all your Java code. I'm sticking with Vector thank-you-very-much. In any case this 'refactoring' was mostly put forward as a starting point everybody could agree on.

no broken windows. someone who cares about swing fixes also the little things. bringing swing up to date to jdk5 standards is a good idea. you start out with a branch anyways so no harm's done. swing at present has zero momentum. anything to help improve the momentum, like making small refactoring improvements is the road towards reviving swing. evolution happens a little at a time. it's in the process of fixing and twidling with the little things that the bigger picture reveals itself, and uncovers the need and motivation for making larger changes.

Worth noting that the problems Elliot does have (at no point does he say Swing 1.0 is perfect) won't be addressed by Danny Cowards JDK7 graphic performance improvements, robust deployment.. nor the unhelpful bundling of JXLayer & (draft) appframework nor by JavaFX either. Also that's one negative voice (well two if we count Danny/Sun) against the 174 comments to Jonathans original Swing 2.0 proposal. You do the math.