Skip to main content

What should be the primary focus of future Swing development?

On making Swing a better stand-alone GUI library
81% (667 votes)
On supporting JavaFX
13% (103 votes)
Something else (please explain)
2% (17 votes)
Swing shouldn't be developed further
4% (33 votes)
Total votes: 820


javaFX use Swing and java2D libraries

What a stupid argument. You had the same situation with AWT and Swing, Swing being build on top of AWT. And Sun didn't improve AWT at all, but instead spent a lot of time to decouple Swing from AWT. And AWT was left at the roadside, dying a slow death.

In particular many Swing components now directly talk to the hardware without using AWT, which was exactly not the idea of lightweight components.

Another great example: MS-DOS underneath Windows. Did it help DOS in any way that some piece of even worse rubbish was running on top of it? No, it didn't. The top rubbish was developed forward (rewritten from scratch), the layer below abandoned, and a mockup of it reimplemented.

I think Sun is lying when they say that Swing benefits from JavaFX. Sun let JDCI die. And as we have just learned, Sun silently stopped funding SwingX already in July - they didn't even have the balls to tell people. Hint: July was also the month when Sun released the first public preview of the JavaFX SDK. Coincidence? I don't think so. Sun bet the farm on JavaFX in July.

And don't give me that scenegraph crap. How many people need scenegraphs compared to how many people would need a working file chooser, a working table, or treetable?

BTW, voting here won't change a iota. Even in the very unlikely event that a Sun decision maker would get the results, they couldn't care less. They never listen to desktop developers on principle.

javaFX use Swing and java2D libraries

Sorry ewin, it doesn't work like that at all. On some platforms, JME for example, AWT is all you get. It is the lowest-common-denominator, a hardware abstraction layer, if you will. Swing is built on top of AWT.

javaFX use Swing and java2D libraries

- In particular many Swing components now directly talk to the
- hardware without using AWT, which was exactly not the idea of
- lightweight components.
Where did you that catch up? AWT is still the abstraction layer between Swing and the underlaying toolkits, nothing has changed in this regard.

On Unix some widget-functionality was replaced with Swing itself, but AWT still does all the low-level interaction.

After all, nobody talks directly "to the hardware", whatever that means.

javaFX use Swing and java2D libraries

He's confusing Graphics2D with Swing. Swing widgets use Graphics2D to draw themselves, and sometime in 1.6 (I think) Graphics2D started using hardware acceleration for some of its drawing/transforming functions.

But Graphics2D is still AWT, in fact many things you use with Swing, Layout Managers, Events, Colors, etc, are all still part of AWT. When he says Sun abandoned AWT, he's more likely referring to them abandoning the so-called "heavy-weight" AWT widgets, which I think they were absolutely right to do, you just couldn't make an app look good using native widgets on multiple platforms.

javaFX use Swing and java2D libraries

Are you confusing this with some platform-specific look and feels that use the window manager of the operating system to render "native" components?

javaFX use Swing and java2D libraries

You seem to forget the number of improvements they added for Swing in Java6: performance improvements for Java and Swing, better platform L&F support, JOGL interoperability, table sorting and filtering, integration of SwingWorker in the API, true double-buffering, system tray, improvements of synth skinnable L&F, new layout that is easy to use with the then new Netbeans GUI designer, etc... You must also be aware that Java6 Update 10 makes Java easier and faster to deploy. So I don't now why you are saying that "They never listen to desktop developers on principle". You must also be aware that its tough times now for Sun, so maybe we should not wine when they carefully choose where they have to spend their money. They can't do everything at the same time now.

"something else": desktop integration

Then and now I still hope for Swing to one day provide a real seamless desktop integration, including all the features that eventually might apply here (most dearly missed at the moment is the ability to allow for cross-platform hotkeys to make the window of a SystemTray application pop-up and do something on demand).

Swing + Java EE x

Why does Sun not do work on making it easier and or natural to create Swing based RIA Applications with a Java EE backend? It's so silly of them to not see this big gaping disconnect of the technologies. Swing needs to be evolved to allow for the creation of the Internet based applications of the 21'st century. More applications are being run off of the net (Webstart helps out a lot here), and hence the vast jungle of HTML based web frameworks out there struggling to get developers to be more productive in trying to handle the common items that pop up in trying to do RIA with HTML + JavaScript. Why doesn't Sun do the same with Swing which inherently is a desktop technology but without any soul for meeting the needs of developers wanting to use Swing as an easy to develop desktop front end technology for a Java EE back-end application? There is a framework out there called OpenSwing that's trying to fill this gap, but I still think it's too complex. The best I've seen out of the blocks recently so far is Wicket. Wicket is Swing done in Html + JavaScript. It's a beautiful easy to use web framework for Java Developers used to doing good OOD work or developers used used to working with Swing. I think it will do well for it to have a cousin that does desktop on the web natively though. That is where Swing comes in.

No Contest!

Java Web Start, Swing, and JOGL are some of your biggest assets. Make them even stronger! Your contenders are not Adobe AIR (LOL) or Microsoft SilverLight (even more LOL) but QT and GTK+. Did you realize people do real-world applications with Java? Here's some of the cool stuff: Quaqua, Freemind, yEd Graph Editor, Photo Tourism, not to speak of IDEs. Did you know MS still does VS with MFC? Did you see their poor attempt at bringing Outlook to the web (OWA)? Only works in their own anachronistic browser! Adobe's flashy player is popular because of some video codecs that they don't even own. You can pull that stunt, too: Make OGG Vorbis and Theora work! Some media sites are already using Vorbis. Give them a player and a snazzy encoder! JavaFX? At the time you have a working product, all "constrained devices" will be running Swing + SVG + OpenGL! Did you know Nokia already has OpenGL Games on some of their handsets? Don't alienate your existing developer base! We are still legion.

No Contest!

-1 for OGG Vorbis and Theora. Why go with codecs that are sub-par (Theora) and unsupported by anyone in the industry other than linux nerds (Vorbis)? That would be silly. There is one video codec now that is THE industry standard: H.264 also known as AVC. Flash supports it, it's the common codec for Blu-ray, hi-def video cameras record directly to it, etc. Just as MPEG2 was THE codec for the previous generation. That;s the media that needs to be supported. We don't need built-in support for tons of uncommon formats - support the core formats that are widely in use. Improved support for Beans Binding and the Application Framework are essential as well to support desktop application development.

Not Competetion!

+1 for Theora. The VP3 codec is on par with FLV, which is what Flash uses in most instances. VP3/Theora can easily replace FLV for those uses, and on low-resolution hardware like phones.

That is not to say that Java doesn't also need a high-def format comparable to H.264, but we shouldn't discount a readily available, open source codec because it doesn't compete with H.264.

Also remember that this would just provide a guaranteed format on all platforms, it won't be the only format Java can use. The new Java Media Components are supposed to also support anything the underlying platform supports, that means DirectShow on Windows, Quicktime on OSX and GStreamer/Phonon on Linux.

No Contest!

+1 for OGG and Theora. They both are virtually unsupported at the moment exactly because everyone says that "nobody's actually using them", even if everyone eventually could without any problem (especially talking about preferring OGG to MP3). The "industry" won't care less as long as there's no significant user demand.

No Contest!

+1 -- very well said Will!

More common parts

Swing the GUI toolkit is the common part for all languages e.g. scala, groovy, java understand Swing because swing is make with the Java language and the bytecode generated for java is understand for all others languages this is not the case with the bytecode generated with JavaFx, because this bytecode is only understand with JavaFx. Interoperability between languages is need and JavaFx do not produce this.