Ivan Ross is currently an independent consultant working with mobile projects. Previously worked as lead developer at DevExpress making .NET components for data mining. I'm lazy to do the same task repeatedly so I write scripts to do that task for me. I'm impatient to wait for my code to run so I rewrite the code to improve performance. I always answer Yes! when someone asks if I can do something. Then go find out how to do it;-) Ivan has posted 2 posts at DZone. You can read more from them at their website. View Full User Profile

Java+Swing in 2013. Is it worth it?

06.07.2013
| 63742 views |
  • submit to reddit

Java Swing was created quite a while ago. If you try searching by the keywords "Swing”, you won't get many articles. But, you'll discover that some people really hate Swing:

  • "10 Things I Never Want to See a Java Developer Do Again... 2. Write/debug or even use a Swing application"
  • "Unlike Swing ... which was ugly by itself"

In my opinion, that’s unfair. I am not saying that Swing is perfect. That’s certainly not true. But I’ll try to describe present Swing’s strong and weak points that I have encountered in my practice.

Why using Swing?

I’ve been using Swing for a couple of years, mainly in the evenings. I am developing Visual Watermark, an application for protecting multiple photos from copyright infringement. In 2011, I made a Java version. I wanted to port my application for the Mac and polish the user interface, but developing a separate application for each platform was out of the question. In early 2011, the following UI libraries were available for cross-platform development:

  • QML was totally bug ridden: The menu appeared below the components, the demo version constantly crashed, and QML was not supported by QtCreator. Accelerated image rendering was implemented only last fall, in Qt5.
  • Qt didn’t suit my needs because QML was half-baked at that time, so I would have to write some code in C++. Surely C++ is a magnificent language used by many smart people. However, taking into account my lack of experience and the complexity of the task at hand, using C++ would be an overkill. Moreover, I found out that Xcode couldn’t refactor C++ code.
  • Juce’s functional capabilities suited my needs just fine. It wasn’t glitchy and didn’t crash. It was affordable, and open source too! Juce deprecated the use of the new/delete operators, allowing the programmer only to create objects on the stack. In theory, that was supposed to reduce the number of pointer-related bugs. I don’t know if that is so, because I stopped short of coding in C++.
  • In Adobe Air, the support for multi-threading is too complicated. You have to create a separate SWF project for each thread, and it’s difficult to exchange data between threads. In the simplest integer calculation performance test, ActionScript falls far behind Java, C#, and C++ implementations.
  • Seemingly, the Mono+GTK combination could have solved my problems. But at that time, I decided not to use it because of the obvious bug: Hot keys didn’t work in GTK when a non-English layout was used. Judging by MonoDevelop, that bug has not been fixed yet. Possibly there are other major shortcomings, too.
  • JavaFX was not available for the Mac.
  • SWT is much easier to use than Swing. All in all, SWT is pretty good. I didn’t use that library simply because it was the last one that I considered using. I had already spent a lot of time, so I just stopped my experiments as soon as I found a bug (buttons slightly “floated” up and down on the tool bar).

At that time, Java was part of Mac OS X and had an excellent native look & feel. And the size of the JRE distribution package for Windows was only 12 megabytes. I was under the illusion that I would surely succeed. As a result, after two or three months of work, I had the first version of my application based on Java Swing. 

The bugs that I mentioned have already been fixed in QML and JavaFX. So if you are ready to work with a scenic graph, you might want to try them out.Qt is now managed by Digia, which released a beta version for iPhone and Android. So hopefully the library has a future.

JavaFX was open sourced this February. In JDK 9, it is expected to become compatible with OpenJDK. It’s hard to say yet when JDK 9 will be released. The release of JDK 8 is planned for early 2014.

Good things

I’ll start with some good things, so don’t think I’m just another Swing hater. 

All rendering is hardware accelerated. Each Swing application is rendered on the GPU, without any efforts by the programmer. So you can use animations in your application, even if it’s going to run in full screen mode or be maximized on a Full HD screen. 

MVC. Swing is criticized for being “heavy”: Any component consists of a representation, controller, and model. However, this approach lets you easily add a new feature to an existing component. Everything is very flexible. 

Java is managed code. You can get rid of tons of bugs “available exlusively” for C++ developers. The risk of Access Violation is minimized. But it doesn’t mean there won’t be other bugs (such as memory leaks) in your program. 

It’s an excellent development environment. Use Eclipse, Intellij IDEA, or NetBeans — whatever better suits your needs. Each of these IDEs offers you refactoring, code formatting, autocomplete, support for unit tests, and tons of libraries. Layout managers, support for native objects, strings, and the Web — you name it. All these things make Java a great platform. 

A lot of answers to questions. For example, take a look at StackOverflow questions on each UI library. One in a hundred questions of so is about Swing. In practice, it means that most of the problems have already been solved. Most likely you won’t have to fight a problem on your own.

Bad things

The previous part sounded like a sweet press release, but I can fix that. :-) Here’s what you may encounter in practice. 

Critical bugs are not fixed. File.exists doesn’t work from the moment when JDK7 was released, and there is no fix yet. Even if a bug is critical, you may have to wait for a fix literally for years. The situation may become even worse if you are going to use native code. I found out the hard way that using modal windows (e.g. opening an OpenFileDialog) can freeze my application on some computers. That happens even if you use Java Native Foundation just like shown in the examples in its documentation. Offering a bounty for solving my problem on StackOverflow didn’t help me either. :-) Actually, you can evade the File.exists bug by using java.nio classes. Java.nio is a new API, whose purpose initially was to solve performance problems when handling huge folders. What you should do:

  1. Launch the application with the parameter
    –Dfile.encoding=UTF-8
  2. Instead of File.exists, use
    Files.exists(Paths.get(fileName))
  3. Instead of File.listFiles, use 
    try (DirectoryStream ds = Files.newDirectoryStream(folder)) {
            for (Path file : ds) {
            // do something
            }
    } catch (IOException e) {
            e.printStackTrace();
    }

Or you can try fixing the bug, and then pushing your fix through a series of reviews. 

Swing is hardware accelerated only (Mac-only!). It means that your application won’t run in VMware or Parallels, and a remote desktop won’t do either. If these limitations are not acceptable, SWT might be your choice. 

There are no 32-bit builds for the Mac. The official build is 64 bit only. Alas, I don’t know what’s the reason for that choice. I can only guess that some bugs may be the case. Henri Gomez used to support 32-bit and universal builds for some time. You could download ready-made builds from his page on code.google.com. Unfortunately, the lack of time and new job forced Henri to stop supporting his project. He said goodbye to everybody and uploaded his build scripts to GitHub: https://github.com/hgomez/obuildfactory You can use them to make OpenJDK for the Mac or Linux. That’s good but not awesome. You cannot use the scripts to make a 32-bit build for the Mac. The JDK contains tons of configuration files that only let you make a 64-bit build for the Mac. If you change a key in the main file, the build won’t work at all. I don’t know how Henri Gomez managed to make 32-bit builds. 

Include JRE in your distribution package. The Oracle management thinks that a standalone self-contained installer with a bundled JRE for the target platform is a better model for application distribution. The most probable reason for that approach is that Java applets contain tons of vulnerabilities. Flash used to be the bad boy, but now Java has taken its place. Apple seems to be the strongest supporter of Oracle’s approach. It even removed Java in Mac OS 10.7 Lion. Apple also forcibly switches off Java when installing system updates. The size of JRE 7 is some 100 megabytes, or about 50 megabytes when archived. Unfortunately, the size of JRE grows with each update, and that’s not good. 

Not all BufferedImage objects use hardware acceleration. Hardware acceleration is only used for BufferedImage.TYPE_INT_*. So starting with JDK7, it is not worthwhile to use TYPE_4BYTE* or TYPE_3BYTE. 

When BufferedImage raster data is accessed, the image is no longer rendered on the GPU. The reason for that approach is clear: If the user modifies the data, you don’t know when to reupload it to the video memory as there is no “modification is over” method. At least, that’s logical. When developing Visual Watermark, I used a C++ library for loading images, and I needed to convert the resulting pixels into a BufferedImage object. Working pixel by pixel was too slow, so I had to write the image directly to the raster buffer. As soon as I called getData() for the raster, hardware acceleration stopped working with all my pictures. I looked into the DataBufferInt code and found a solution for this problem, using reflection. Here’s my little helper class:

import java.awt.*;
import java.awt.image.*;
import java.lang.reflect.Field;

import sun.awt.image.SunWritableRaster;
import sun.java2d.StateTrackableDelegate;

// Standard library prevents image acceleration once getData() method is called
// This class provides a workaround to modify data quickly and still get hw-accel graphics
public class AcceleratedImage {
    // Returns data object not preventing hardware image acceleration
    public static int[] getDataBuffer(DataBufferInt dataBuffer) {
        try {
            Field field = DataBufferInt.class.getDeclaredField("data");		
            field.setAccessible(true);
            int[] data = (int[])field.get(dataBuffer);
            return data;
        } catch (Exception e) {
            return null;
        }
    }
    
    // Marks the buffer dirty. You should call this method after changing the data buffer
    public static void markDirty(DataBufferInt dataBuffer) {
        try {
            Field field = DataBuffer.class.getDeclaredField("theTrackable");		
            field.setAccessible(true);
            StateTrackableDelegate theTrackable = (StateTrackableDelegate)field.get(dataBuffer);
            theTrackable.markDirty();
        } catch (Exception e) {
        }
    }
    
    // Checks whether current image is in acceleratable state
    public static boolean isAcceleratableImage(BufferedImage img) {
        try {
            Field field = DataBuffer.class.getDeclaredField("theTrackable");
            field.setAccessible(true);
            StateTrackableDelegate trackable = (StateTrackableDelegate)field.get(img.getRaster().getDataBuffer());
            if (trackable.getState() == sun.java2d.StateTrackable.State.UNTRACKABLE)
            	return false;
            field = SunWritableRaster.class.getDeclaredField("theTrackable");
            field.setAccessible(true);
            trackable = (StateTrackableDelegate)field.get(img.getRaster());
            return trackable.getState() != sun.java2d.StateTrackable.State.UNTRACKABLE;
        } catch(Exception e) {
            return false;
        }
    }
        
    public static BufferedImage convertToAcceleratedImage(Graphics _g, BufferedImage img) {
        if(!(_g instanceof Graphics2D))
            return img;	// We cannot obtain required information from Graphics object
        Graphics2D g = (Graphics2D)_g;
        GraphicsConfiguration gc = g.getDeviceConfiguration();
        if (img.getColorModel().equals(gc.getColorModel()) && isAcceleratableImage(img))
            return img;
        BufferedImage tmp = gc.createCompatibleImage(img.getWidth(), img.getHeight(), img.getTransparency());
        Graphics2D tmpGraphics = tmp.createGraphics();
        tmpGraphics.drawImage(img, 0, 0, null);
        tmpGraphics.dispose();
        img.flush();
        return tmp;
    }
}

Use my helper class as follows:

DataBufferInt dataBuffer = (DataBufferInt)bufferedImage.getRaster().getDataBuffer();
int[] data = AcceleratedImage.getDataBuffer(dataBuffer);
// Modifying the data
AcceleratedImage.markDirty(dataBuffer);

I didn’t test the above code on any displayed images.

There is no built-in support for animation or semi-transparency. The javax.swing.Timer object is good for two things:

  1. You can use it to add animation to your components.
  2. The class is very simple, so doing that takes a lot of time.

The Timing Framework library offers an easier way to create animations. You can create an animation as follows:

Animator viewAnimator = new Animator.Builder()
        .setDuration(duration, TimeUnit.MILLISECONDS)
        .setStartDirection(Direction.FORWARD)
        .setInterpolator(new AccelerationInterpolator(0.3, 0.7))
        .setRepeatCount(1).addTarget(new TimingTargetAdapter() {
            @Override
            public void timingEvent(Animator source, double fraction) {
                // Changing state here
                repaint();
            }
            @Override
            public void end(Animator source) {
                // Do something when animation completes
            }
        }).build();
viewAnimator.start();

Most often position or semi-transparency animation is used. Swing lets you control the position just fine, but its standard components do not support semi-transparency. The problem is not limitations of the graphic engine but a lack of the getAlpha/setAlpha property in components.

Java applications won’t run in Mountain Lion because of GateKeeper. To solve the problem, you have to sign up for the Mac Developer Program, which will cost you $99 a year. Apple will give you a certificate for signing your code, and the problem will be over. You can sign your application bundle as follows: codesign –s "Developer ID" –f "path-to-my-app.app"

Bottom line

In my opinion, Swing’s major drawback is that you can never be sure about its future because of some critical bugs. Only browser plugin vulnerabilities are fixed from time to time. It almost looks like the library is no longer supported. All other problems seem insignificant in comparison. 

It makes me sad to think that Swing may be gone any time soon. You see, Swing lets you develop desktop applications quickly and easily, and there are tons of ready-made, free code that you can reuse. 

I still hope that Oracle developers will find some time and fix the problems in their platform.

Published at DZone with permission of its author, Ivan Ross.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Lund Wolfe replied on Fri, 2013/06/07 - 2:25am

A lot of people hate ORM, too.  Swing is very hard (apparently), but the alternatives are Swing and SWT.  GWT may be a good web RIA choice but I don't think it holds a candle to Swing on the desktop.  Swing is definitely not for everyone, though.

Walter Laan replied on Fri, 2013/06/07 - 2:38am

Nice to see none of the bad things is actually about Swing :).

A note about the 'good' thing of being hardware accelerated: on Windows with a bad video driver or cheap/integrated cart and dual monitors it is better to turn it off, or Swing can become pretty slow (-Dsun.java2d.d3d=false).

You also have to use -Djava.util.Arrays.useLegacyMergeSort=true if you use the clipboard, since a Sun DataFlavor comparator can cause the new sort to throw an IllegalArgumentException.

The main benefit over JavaFx is indeed the tons of libraries.

Felipe Talvik replied on Fri, 2013/06/07 - 5:45am

It was really uniformed/biased decision about Qt. If QML was still imature, there is still the standard cross-platform Qt widgets and this should have been your first choice when building crossplatform desktop app.

I'm a Java developer with years of experience with Swing(I still use it most of the time), have no experience with C++ and I've picked up Qt/C++ in no time for a project. Qt is as easy for a Java developer as for a C++. For a Java developer Qt/C++ feels really familiar(go look at the core APIs), and Qt UI is much much better than Swing.

If you are doing a cross-platfform desktop application for end-user. Just use Qt, there really is no other alternative.

Felipe Talvik replied on Fri, 2013/06/07 - 6:20am in response to: Felipe Talvik

 You forgot to list some of the problems with desktop/swing Java:

  • The worst APIs and all the bugs that I've found on the JDK are in the Swing package, and nobody gives a f**k about it.
  • The further you stray from the core components, the more bugs and mind blowing cheaty APIs you'll find.
  • A lot of years old "wontfix" bugs in the bug tracker.
  • Feels like working on abandon-ware. And recently officially declared as legacy.
  • Working with even more marginal things like sound, expect things to Simply Not Work.
  • When searching solutions in the internet, it feels like going back in a time machine.
  • Finding the best rendering backend and options for every system and JRE version is...
  • Half-baked, underperforment piece of cheat.

I'm not saying there are no cases to use Swing, but yours isn't one of them. I work a lot with Swing daily, and I wouldn't move to another platform/toolkit.

Ivan Ross replied on Fri, 2013/06/07 - 6:58am in response to: Walter Laan

I believe, the point about cheap cards are a bit outdated. After 2010 even the cheapest card is pretty decent and is more than enough for most desktop apps (but not for CAD, 3D modelling and games).

Thank you for the suggestion about clipboard. Still working on Windows version and it's important  to include this.

Walter Laan replied on Fri, 2013/06/07 - 7:37am in response to: Ivan Ross

 Nope, we've seen this multiple time with Java 7 on Windows recently, especially with dual monitors. It would take a second for popups to show and you can see the components being repainted when d3d is enabled. Disable it and everything runs smoothly. IIRC this still uses accelerated images, just disables the Direct3D pipeline.

Ivan Ross replied on Fri, 2013/06/07 - 7:39am in response to: Felipe Talvik

>If you are doing a cross-platfform desktop application for end-user. Just use Qt, there really is no other alternative.

QT is cool, no question asked. My biggest complaint was C++ it's written in. I worked with C++ in the past and I cannot say I'm happy with the experience. I can remember two memory-related bugs that costed a month each to find the cause and fix it.

One of them appeared as an incorrect type in a customer record. Which was impossible since the code setting this variable was small and there was no possibilities to get a value we saw. After about 3 weeks of attempts to fix this stuff, another guy noticed that our random function may not work correctly and return bigger values than expected. This random value was used to write to an array. C++ doesn't have built-in range and pointer checking and it allowed the program to write outside array's memory.

I believe, this was completely our fault since we didn't use types for arrays with strong boundaries checking. However, if even we used good arrays, we used a lot of 3rd party code as well. And there was no guarantee their authors used safe arrays too.

This is a kind of problem that is almost impossible to face writing managed-code.

Ivan Ross replied on Fri, 2013/06/07 - 7:42am in response to: Lund Wolfe

>A lot of people hate ORM, too.

There are different. You may write a comparison - I will definitely read it.

Mason Mann replied on Fri, 2013/06/07 - 8:07am

swt rocks

Fabrizio Giudici replied on Fri, 2013/06/07 - 8:22am

The truth in 2013 is that Swing is still usable and absolutely needed in some context, such as the industry, where you need a local UI used by "administered" client workstations. It's advisable to use some enhancements on the top of Swing, such as the NetBeans Rich Client Platform and SwingX: the former will save time, and give lots of consistency, modularity and pluggability to your application, while the latter will fill some missing components. In any case, Swing should be considered "half-legacy" today: JavaFX2 should be considered as "Swing NG". Now that it has been open sourced and is available on all the platforms, there are no needs to ignore it. Sure, it still lacks some "business" components, but in the meantime it can be mixed with Swing. It still uses hardware acceleration and shares most of the advantages of Swing, offering in the meantime supports for new stuff such as gestures, advanced graphics effects, animations and so on. I think that there will be still need of rich client desktop applications in next years, and they will be more and more based on JavaFX + enhancements, with Swing slowly go away.

Philippe Lhoste replied on Fri, 2013/06/07 - 8:28am

I coded Swing for years (currently working on GWT), mostly for maintenance.

I agree with this article : it is an OK technology, with good sides (powerful, flexible, battle-tested) and down sides (complex, frozen API, some bugs).

I will just add a fact: yes, bugs are still fixed. And sometime, these fixes can break your application! We develop workarounds, or use the bugs as features, and when they decide to fix them, we have to code around these fixes!

Latest one: displayed text was automatically wrapped, it was deemed as abnormal, so I had to do complex things to break the text ourselves were we wanted...

Mark Bernard replied on Fri, 2013/06/07 - 2:42pm

I've coded dozens of GUIs with Swing and have never had a problem getting it to do what I want. I have recently tried JavaFX and, maybe it is my Swing mindset, but I find it harder to make it do what I want. The biggest problem I have had is with heavyweight look and feels can slow it down considerably. Also have of your complaints don't have anything to do with Swing. The big thing I do agree with is that people pass judgment without even giving it a try.

Carl Antaki replied on Sat, 2013/06/08 - 8:09am in response to: Fabrizio Giudici

I agree with Fabrizio. What happened to Bluemarine? I currently use Swing and JavaFX on a my Facebook photo uploader Bloom. http://bloomuploader.com

Swing still offers more components and is much more mature than JavaFX, JavaFX 8 to be released in Q1 2014 is supposed to bring many improvements to JavaFX.

There are still some companies with internal Swing desktop applications which I think are here to stay, they might use JavaFX features but that will take some time. Also what about Netbeans that uses Swing, is there a project of integrating JavaFX in Netbeans?

Ramesh Kapa replied on Sat, 2013/06/08 - 8:20am

The direct answer to your question: No, it's not worth it.

What is the alternative then : JavaFx 2, this is just java based GUI tool kit which tries to address some of the so called deficiencies in swing and try to adopt some of latest inventions and innovations in modern graphic cards and UI landscpae, similar to android GUI and IOS GUI where it runs. With Java 8 Closures it would be much better.

  Swing was cool and that was the only GUI technology available for java at that time (If you are not contending it with html/css/javascript even with html 5, I don't still buy it as true UI tool kit along with myriad frameworks of Java and other to abastract that away). I think people are confusing the challenge of UI programming in general with Swing's api complexity. Swing is the one technology which tried to address that challenge as effectively as possible. Remember the competitors of swing were likes of MS Windows SDK.

SWT was the GUI tool kit used in Eclipse later made as general purpose GUI tool kit for java, but it is not designed as java api for UI from ground up. You see that when you try to use it. I think it is only suitable for such kind of apps like with central text editor along with supporting views with simple controls. You are good until you try your app fit in to that set up. The weight of   baggage it carries is not simply worth it.

Lund Wolfe replied on Sat, 2013/06/08 - 3:25pm in response to: Ivan Ross

I'm just saying that "hate" doesn't equal "bad".  Some people hate all ORM's, including MyBatis/iBATIS 3, not just Hibernate and commercial versions and smaller or older ones that don't reuse prepared statements.

Ricardo Malikoski replied on Tue, 2013/06/11 - 9:41am

 Thanks for a goode article.

Fabrizio Giudici replied on Tue, 2013/06/11 - 10:06am in response to: Ricardo Malikoski

@Carl Antaki "What happened to Bluemarine?

A few years ago it was my first attempt to mavenize a project. I did it badly (learning the lesson for other things), and I was stupid enough to try also other things during the process; add Oracle stepping in, saying that java.net and kenai.com were going away, then changing idea, etc… so I also moved three times in the meantime; and having scarce time, I also was to upgrade various libraries. I did very bad, in a few words, and for a long time the project was not compilable outside my computer. It seems that the snapshots are now mostly compilable in my Hudson, so I should close to a decent state. Of course, compilable doesn't mean working :-) but chances are that by August the project is back. I'll have to change a lots of things that in the meantime I decided to do in a different way…

"Also what about Netbeans that uses Swing, is there a project of integrating JavaFX in Netbeans?"

I've started integrating JavaFX in smaller NetBeans projects - if you correctly did presentation separation, it's not hard. For a few time you'll have to use both Swing-derived components from the Platform and your own JavaFX stuff. I don't think there's an official plan, but I know of some people in the community working to provide JavaFX components fitting with the Platform model objects. I have still to catch up with that. 

Martin Wildam replied on Tue, 2013/06/11 - 4:24pm

As a developer there are two things that really raise my blood pressure in an instant nowadays:

a) How fast people embrace new stuff (aligned to the saying "learn a new language every year" - which I find bullshit) often still full of bugs and incomplete and on the other hand bashing established stuff that works well.

b) That people forget about the tooling around.


I cannot see the big learning curve with Swing that others told before. I had a lot more troubles to get started with JavaFX and felt very tied to that scenery-stuff that somehow does not represent how users and me thing about GUI.

Reasons why I don't like SWT is:

1. it's widgets offerings is tied to the set of widgets that is available on all platforms as SWT uses the native widgets. I already had troubles finding a date-picker which I do consider as an essantial thing in GUI.

2. There are two possible strategies: Either you want you app look like native app on each OS or you want your application look the same on each OS - and I prefer the latter.

3. The GUI builder in Eclipse was awkward and super-buggy last time I tried it (and after about an hour to get it to work). On NetBeans even worse the situation (and I prefer NetBeans).

The Matisse GUI builder in NetBeans is the best GUI builder I have seen for Java GUI applications so far and a good GUI builder is essential for me. I had GUI builders even as a 10-12 year old kid in MS DOS times. I don't accept being pushed back to stone age.

Everything else I tried besides Swing was even more complicated or lacked regarding tools. I like Swing a lot - even NetBeans is written in Swing. And I can write my own Swing widgets in Swing - without breaking language or technology-borders.

Fabrizio Giudici replied on Tue, 2013/06/11 - 4:47pm in response to: Martin Wildam

Martin, your point (a) is very true. But here nobody is saying that starting from tomorrow you're not going to use Swing any longer, only JavaFX. You can mix the two things, and it makes sense to start using JavaFX for all the things it can already deal, and use Swing as legacy.

For what concerns tooling, I like a lot Matisse. The problem of Matisse is that it's going to lock you in NetBeans. For me it's not big deal, but for some customer it can be. One might like NetBeans, but then be forced to migrate to Eclipse because of corporate decision. At that point, if you've got tons of UI generated by Matisse, you have a problem. Now, JavaFX has got SceneBuilder, which works on FXML files, which are a defined standards. This means that UIs designed in JavaFX are IDE-independent and their layout is a resource file, not a piece of locked code, and they can be easily styled by means of CSS - definitely steps forward, and in this area Java has been behind for years. Not counting that JavaFX has got a working web browser pane based on WebKit, while all the previous attempts in Swing, both pure Java and with native libraries, have been a pain.  

SceneBuilder is 1.0, so it's not as proven as Matisse, still it looks it's usable for many things. In any case, there will be further progress steps with JavaFX, while only major bugfixing for Swing in years to come.

Martin Wildam replied on Tue, 2013/06/11 - 5:21pm in response to: Fabrizio Giudici

 Yes, Matisse is a lock-in to NetBeans. Of course such dependencies are bad, but my experience is, that even the widest open standard could end up abandoned. Just the fact that I could in theory write it on my own because everything is open, will not guarantee that there are enough usable alternatives out there. And I don't see much difference from the dependency point of view if I use a SceneBuilder or Matisse - anyway both comes from Oracle. And JavaFX brings additional dependencies that BTW are not very likely to be already installed at the user PC.

I don't understand, why Swing is so abandoned as I cannot see a real substitute.

Jeroen Wenting replied on Wed, 2013/06/12 - 2:15am in response to: Lund Wolfe

 yes, there's a lot of people who "hate" everything that's not exactly the same as what they've been used to for years.

And there's a lot of people who "hate" everything that's not shiny and new.

Strangely, a lot of these people are the same people, they're just consistently and persistently negative about everything at all, even to the point of promoting A over B in discussions about the merits of B, while at the same time promoting B over A in discussions about the merits of A for exactly the same scenario!

I've even seen people bash features included in products that they themselves demanded as being required "for the product to be functional" after those were implemented to the exact specifications those people had demanded as being "the death of the product".

Jeroen Wenting replied on Wed, 2013/06/12 - 2:29am in response to: Martin Wildam

 a) agreed, there's a lot of "oooh shiny" and instantly everything else looks dull, tarnished, dead and burried in the developer community. Maybe it's my training as a physicist and my first work experience using Cobol that makes me skeptical of new stuff, but I am "conservative" myself.

b) big NYH thing, people tend to ignore things made by others still. That and a lot of license trouble (mostly with GPL and GPL like licenses preventing people from using the library or tool without risking losing ownership of their own creations).

3) yes, GUI builders for Java are mostly clunky and always have been. Borland made a pretty good one for JBuilder and I think it survives under Embarcadero's stewardship, but that's now one expensive product. The one in IntelliJ is pretty good as well, though not as intuitive.
 The ones in Eclipse (terrible) and Netbeans (not much better) have their purchase price as their only redeeming quality.

"I cannot see the big learning curve with Swing that others told before"
Mostly people coming from other GUI design paradigms have trouble adepting to the idea that they can't set things to exact coordinates by laying them out on a grid (which they'd do in Visual Studio and most other GUI builders). That and the event handling system which is too different for a Visual BASIC coder to get used to in 5 minutes while learning Java at the same time.

Mark Unknown replied on Wed, 2013/06/12 - 5:23pm in response to: Ramesh Kapa

" I think it is only suitable for such kind of apps like with central text editor along with supporting views with simple controls"

I have multiple apps that use SWT and Eclipse RCP. They do almost no text editing (in the sense of editing code). It works much better than typically "web" technologies (sans JS client code). With binding, etc, it is pretty powerful. Not perfect by any means.


Mark Unknown replied on Wed, 2013/06/12 - 5:24pm

If you have Swing (or such) experience, doing mobile native and JS client (such as Sencha) are much easier.

Sure, Swing has its warts and things are moving towards JavaFX it seems. But if you want to create a local UI without any extra dependencies, it is hard to beat Swing.


Ramesh Kapa replied on Wed, 2013/06/12 - 9:45pm

  I think there are lot of misconceptions about JavaFx 2. It is not like some brand new frame work just popped up yesterday, the effort has been under way since 2007 and api is reasonably matured. It is not some third party java based framework like numerous other java frameworks. It is core java UI library which is going to be the part of JDK like java nio, jaxb e.t.c. It is progressive enhancement to swing, like swing to AWT. The API weight is drastically cut down, using recent language enhancement, like Generics, Collections and new Concurrency frameworks. You don't have numerous addXXXListeners any more. Take look at here 

   I am not that fan boy who excites about every new technology that shows up day in and day out. I am just a conservative java guy. For me JavaFx 2 is just a language enhancement in UI area like any other new language features viz enhanced for loop, new collections framework, new concurrency framework, NIO etc. I think newly starting Java projects/Applications should take advantage of new features available in the language.

    About ExtJs, yes it tries to make browser based UI techs. like some api based toolkit. But I think my fundametal question is about using browser as an application platform, why? you got your users with these powerful hardware like multi-cores, ram sizes in the order of GBs and modern GPU's and you still wants to be in that one browser window making rounds and rounds (of inventions or re-inventions?) within that, seriously. Just think out of that window (Box!), you experience whole lot of new freedom and power. The price you pay in the name of installation (that those browser apps claimed to be takes off) is worth it. The new mobile app development  is one example of that. And finally there is this classic called JAVA that runs almost everywhere.

Richard Conway replied on Wed, 2013/08/14 - 7:39am

I've had a great experience using Swing.  Yes, there is a bit of a learning curve, especially with extending components and with threading.  However, now that Google has open sourced/made free Instantiations excellent Swing Designer (Drag and drop designer), it is really easy to create nice Swing forms quickly.  Add to that JGoodies FormLayout for doing layouts and you have a really nice toolkit.  And since the UI and code is all in Java, it's really easy to test and debug.  I'm looking forward to integrating some Java FX 2 into future apps - now that its real Java and not Java FX script.  If you need to develop WebStart apps, also take a look at InsiTech's XTT which automagically binds Swing components to your remote database and handles all the data transfer and persistence for you in the background.  Great for corporate apps.  Finally, I hear that the roadmap for Java includes replacing Java ME with a future version of Java SE so you can really use one API for mobile, desktop and server. 

Developer Dude replied on Fri, 2013/10/11 - 1:29pm

About 80 to 90% of my development work is in Swing. Been working with Java and Swing since about 1999 - at first with shrink wrap software (for the publishing industry), then later business apps.

Swing definitely has its warts - along with many of the other Java libs in the JDK. 

The two main issues I have with Swing are:

a) The design/architecture of the libs and API are at times clunky. Looking at the actual code shows that quite a number of different people wrote parts of it with different coding styles and different conventions for how things should work. I would not be surprised that interns and/or very junior devs worked on major parts of Swing. 

It can be annoying at times trying to put the different parts of Swing components together - it often does not feel cohesive.

b) The lack of support by Sun and then by Oracle. Face it, about 99% of Java code out there does not use Swing at all, most of it is server side code with a web service layer and/or a web client front end (usually some form of DHTML). So Sun/Oracle really has little incentive to modernize Swing, and when they do, they approach it like the rest of Java - they leave the bad stuff alone, at most deprecate it but still leave it in place (for years) and work around it - often with yet another layer on top of something else.

Swing is mostly used in legacy business apps that business mostly only expose to internal users or maybe to a very small client base (the latter is the case for the app I work on now).

That said, I still prefer it - it is what I know and for the most part I can make it do what I need it to do.

When you see someone complaining about using a Java desktop app it is usually because it is poorly written. With the exception of startup time and deployment size, a Java desktop app can be made almost indistinguishable from a native desktop app - if properly designed and written. 

Edwin Buck replied on Mon, 2013/10/28 - 11:59am in response to: Felipe Talvik

 Felipe,

Sounds like you have a bone to pick.  It's ok to not like something; however, there's not much fact to support your points.  In fact, there's a lot of assumption that we'll take your statements undefended.

I've worked with a few toolkits, and the Swing API is not a shallow learning curve, but it's not hard either.  It is very internally consistent, which helps a great deal.  However, I'm not going to argue the merits of Swing, it stands on it's own merits.

What I will point out is that this response is exactly what the author is talking about.  There is a lot of Swing hate out there.  "Half-baked, underperforment piece of cheat." is a point that sounds like "a lot of Swing hate".  "feels like going back in time", "feels like abandon-ware", "recently declared as legacy", "more bugs and mind blowing cheaty APIs", and "nobody gives a f**k about it." statements are all more indicators of hate without reason, instead of rational points where something could be better.

Now the article the author cited was just about as bad.  It covers a lot more ground, but there are appropriate times to do nearly everything that referenced author mentioned.  Even outside of the Swing comment made, the author complained about writing their own linked lists (why?  there's a Java API class already?), dealing with logging frameworks (really? try developing without logging), the inevitability of business logic moving into PL/SQL (come on, not inevitable at all), etc.

Seems like it's easy to take a stand of frustration, with no real purpose.  Our whole industry is prone to it; but, it is entirely non-constructive. 

Swing is a decent fully fledged toolkit, and is as powerful as the only other decent fully fledged toolkit in my estimation.  What is baffling is why so much hate.  I'll take Swing over many toolkits any day; I know there's not going to be a corner I can't back out of with it.  It is mature, relatively bug-free, well documented, supported, and stable.  The rest of onus of using it is up to me.

Oliver Watkins replied on Thu, 2013/12/05 - 4:47am

I think Swing is better than SWT. SWT looks and feels the same no matter what you develop. The Eclipse Platform is great, but you always feel like you are getting an IDE. I think Netbeans Platform is going to ensure Swings survival in the next 10 years. Its just like Eclipse RCP, but you have more flexibility in look and feel (which SWT lacks).

I tried JavaFX for a bit, but got greatly concerned when it didn't understand what a dialog was. It seemed to think it was the same as a Frame, and rendered it in a browser Window. Maximise/Minimise buttons seemed to create confusion for JavaFX. If JavaFX has such problems with GUI fundamentals it would be worth waiting 5 or 10 years before having another look at it. It is just too high risk for client projects of mine. It has some cute stuff with animations. I would recommend popping in the odd JavaFX component in your Swing app like charts etc., rather than let JavaFX supply the application skeleton.

As for the RIAs out there : GWT, JSF, Vaaidn, Air,... and the 100s of other frameworks out there. They ALL look very pretty. But they aren't a patch on Java Swing when it comes to desktop. 

Swings here to stay baby. It ain't what it used to be 15 years ago.



Walter Dogg replied on Wed, 2014/04/02 - 1:52pm

 I think Swing should be supported more. If they could implement Swing on Android, it would once again be 'write once run anywhere' like it was supposed to be.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.