Joshua Marinacci's Blog

Swing has failed. What can we do?

I've been writing Swing apps for a long time and despite the speed and API improvements I don't think it's gotten better. After reading Chris's latest blog about it I decided that I really need to chime in. Most Swing apps, and there are sadly few, suck. I mean really suck. They are the suckiest bunch of sucks that ever sucked! And here's why:

Swing apps are slow to build. Building a Swing GUI takes time because you have to do it programmatically. No GUI builder can do it reliably. While the extra day you spend writing layout code may not be much in the life of a six month project, it still matters. The GUI needs to go through many iterations, preferably as early in the project as possible. If it takes hours to make changes then the project probably will not slip behind due to the extra development time. Instead the extra iterations just won't be made, resulting in an inferior product.

Swing layout managers suck. GridBagLayout is particularly bad, though it's better than all the others. Layout is an inherently visual task that needs visual tools. I wouldn't layout a magazine with a text file, I'd use Quark. Why shouldn't I have a quality visual builder for my Swing app?

Swing apps are hard to maintain. Since there's no standard place to put everything a maintenance coder will have to make heavy use of the search function to figure out how the app goes together and where to fix things.

Swing is too powerful. In terms of extensibility it's very powerful, but the complex API gets in the way of simple tasks, something that turns off new or infrequent programmers. Swing is great as a theoretical toolkit, taking advantage of modern UI theory: factories, renderers, MVC, event handling, and internationalization. (though I wish the rendering and event handling was more virtualized). But this is really overkill for many day to day tasks.

No native features. Each platform has interesting native features that may or may not have analogues on other platforms. Java was originally designed with cross-platform wrappers around everything for two reasons: to ease the life of developers (you don't have to code something twice) and to stop people from writing Windows only Java apps. I agreed at the time but I now thing this reasoning is flawed. Given a choice between more coding to conditionally use a native features versus not having access to the feature at all, I'll take the extra work. (note: Apple has done a pretty good job here, but we need more.)

Swing apps have a bad history. The early applications gave Swing a bad reputation that still lives on today. So what can we do about it? How do we counteract all of Swing's current and historical flaws?

From Sun I only want two things:

• Fix the bugs. There are some longstanding Swing bugs that Sun seems to refuse to fix. When working on some code to print out Swing components I ran across a bug that has be documented on the Java forums and Sun's buglist since 1.2!!! These simply have to be fixed. Good apps need a stable platform. This also means fixing the issues with the native look and feels that Sun is responsible for. I understand that 1.5 will help a lot

• Make something better than Metal. Suck it up. Pay a graphic designer for one year to develop a better default L&F. Something innovative and comprehensive. Something that will wow everyone when you release Java 1.6. You'll make it back just in free press.

From the community we need more:

• One single open source and extremely well documented package of reusable Swing components. They should each work independently and must be documented clearly enough that someone can drop in a jar and init a class after 60 seconds of reading. The package should include all of the common extensions that people keep reimplementing. Something like the Jakarta-commons for Swing. Something to handle the boring stuff so that we can all move on to more interesting things
• A structured way of building Swing apps. Something like Struts where each concern (aspect?) has it's own special place to be stored and manipulated. How do you organize your layout, workflow, validation, intz'ed text, and hooks to the BL? Should you subclass to make frames or use factory code? We need a set of best practices and then a framework to implement them.
• a standard cross-tool representation of a GUI that is not Java code. Something that can be moved in and out of different IDEs and build tools. Probably an XML representation or maybe serialized Swing objects.
• A really good visual screen builder. All it does is layout out widgets and ensure that you never ever have to deal with layout managers at the code level again. This builds on top of the previous request.
• VB for Swing. An integrated IDE for prototyping and developing throwaway scripts. It's for non-pros and for pros when they want something quick and dirty. An editor for the little things. Throw up some widgets and pop out an EXE. It's really more like Visio than a real IDE, but completely invaluable for building mockups ASAP. This builds on top of the previous request.
• An intermediate API. Maybe we need a simpler API on top of Swing? A new set of wrapper components which hide a lot of the complexity. Hell, half of the work could be done by just conditionally hiding 3/4 of the API from the Javadocs.
• More articles and one good book. More articles on writing polished GUIs and better components. Stuff on actual UI design and usability. And maybe just one really good O'Reilly book on everything it takes to make a Swing app shippable.
• Competition Sun should sponsor a well publicized competition at least once a year. The only requirement is that each application uses Swing and has a free downloadable demo.

I believe in Swing. I really think it's the best toolkit for writing robust cross-platform applications. However, if we don't do something to jumpstart it's growth then it'll die along with the dinosaurs: big, powerful, and unable to keep up.

Comments

• Here we go again
  Amazing how may people complain about Swing GUIs sucking and how it must be the fault of Swing and not the fault of the programmers.

  There are good Swing GUIs out there. Yes writing in Swing is NOT something that every junior programmer can do. Yes Swing is powerful. But if you know what you are doing Swing can be fast as well. Why must a GUI API be easy to use to be classified by developers as good? Swing is extremely powerful and lets you do some amazing things with it. But you need some experience to be good with it. You need to truly UNDERSTAND the APIs for your applications to work well.

  Take a look at jGoodies.com, intelliJ, and Moneydance. These are three prime examples of GUIs that work well and use Swing. In fact intelliJ is faster on a smaller CPU than Eclipse and SWT. Why? I would hazard a guess and say that the developers of these know what they are doing and understand the APIs.

  I have often said before that the bar for entry in the Swing arena is high and it SHOULD BE. Setting the bar too low and you see applications that truly suck because everyone and their grandmother thinks they are a coder.

  It is high time that we separate the wheat from the shaft when it comes to Java developers. Swing is one API that does that.

  Posted by: mzarra on November 10, 2003 at 09:30 AM

• Swing failed??
  Swing has failed? Thats a pretty arrogant thing to say!
  I work at a company that has been doing Swing for their applications for years now and we have major success with them!

  But naturally I don't think its very good to answer with a flame; you are basically the first to put forward these points in a well articulated manner, which I feel are pretty darn accurate!

  Luckely you are not the first to see these problems (just the first to say them here :) and there are solutions to the problems you describe.

  I'd really like you to download and try an open source solution called http://uic.sf.net Please comment on it, and give feedback we can use. We are pretty tough skinned, so don't hold back :-)
  Points 1, 2, 3 and 4 are solved in this project by using a very very good UI designer and providing (forcing even) a workflow that make these problems almost go away.

  The problem of 'no native features' is not really relevant in my opinion; I write applications on Linux that customers use on Windows. I don't want to ask support to learn to use all platforms because our application can look slightly different, which is what you get with these native features.
  So what we do is take the good ideas from all platforms and provide them in the UICompiler widgetset, we recently added undo/redo support in each textfield, for example.

  There are some really good widgets and general features, which solve problems most developers don't even think about.

  Sorry, I'm getting a bit too enthusiastic here; its just that I feel that too many people are cursing Sun while good solutions _are_ available.

  Hope to see some reaction on the toolkit from you!

  Posted by: zander on November 10, 2003 at 09:33 AM

• Re: Here we go again
  Hi,

  in short; who died and made you god? Making it hard to create something so people you deem incapable won't do it really is something you have to think about. Think HARD about.

  There are real problems in Swing and these have little to do with how good the programmer is, Joshua points out a nice series above.

  Maybe you can comment on those issues instead of just going for the elite-only ideas?

  Posted by: zander on November 10, 2003 at 09:39 AM

• Re: Here we go again
  I'm guessing that you didn't actually read through the entire article. I think that Swing is a very powerful API, and as such takes a lot of study to write good applications. I don't take issue with this. You'll note that in my solutions section I didn't say that we should remove any of the power of Swing by dumbing it down. On the contrary, I think we should have a simpler API build *on top of Swing* that handles all of the easy day-to-day tasks. It needn't even be an API (ie. a set of classes and functions) but perhaps an XML screen description file. Either way the true power of Swing will always be there when we need it.

  - Joshua

  Posted by: joshy on November 10, 2003 at 09:41 AM

• Re: Here we go again
  I never claimed to be God nor elite. What I have said before is that if you want to be a good GUI programmer in Java it takes effort and has a steep learning curve. What is wrong with that?

  People want to code in Swing, good for them, please take the time to learn the APIs instead of complaining that it is too hard. The APIs are extremely powerful. The layout managers can do pretty much anything you want in a cross platform manner. Why must the default SDK include a way to write GUI code that fits you exactly. Don't like it? Do like jgoodies.com did and write your own.

  Swing works. Period. I know I am in the minority when I say that the bar for entry should be set high. Take a look over in the VB camp or the .net camp to see what happens when you set the bar too low. I have had to repair some god-aweful code in .net because the bar for entry is set way way too low.

  In my opinion making things just a bit difficult will narrow the field and remove the people who want to be coders but refused to put in the effort that SHOULD required.

  Look at other fields. Imagine a building architect. If that job was easy enough a lot more people would be doing it. Now look at some of the code you have seen pumped out in recent years. Would you really want someone with that lack of attention to detail designing your house? Why must a programming job be any more lax? Now take that to the extreme and imagine a brain surgeon. Scary thought.

  Programmers should be professionals. Coding is not something that everyone with a WYSIWYG editor should be pumping out. If we set the bar that low and Java is simply not going to gain widespread acceptance on the Desktop.

  These are naturally my opinions on the matter and I am sure you have your own. Please do not flame me by calling me elitist that does not really support your position now does it.

  Posted by: mzarra on November 10, 2003 at 09:57 AM

• Re: Here we go again
  I did read the article. I disagree as stated in my other two posts that we should make it "easier." The easier we make it the more wanna-be coders are going to produce crappy code.

  Please read my response to Zander on this issue.

  Posted by: mzarra on November 10, 2003 at 09:59 AM

• Swing failed??
  Thanks. I'll take a look at it in the next couple of days. I'm working on my own GUI builder with some interesting ideas, but I've decided that the only real solution is a vendor/tool neutral representation of the GUI that will work with multiple builders.

  - Joshua

  Posted by: joshy on November 10, 2003 at 10:13 AM

• Re: Here we go again
  There is a place for complex and powerful APIs and for streamlined and simple ones. And they are not mutually exclusive. That's the beauty of programming languages. We can have both and the only per unit cost is a little bit of memory.

  Let's take your example of an Architect. Certainly no one would argue that laymen should be designing buildings and that the age of the architect is over now that we have computers. However there are cases were simplifying architecture is a good thing. For laymen, creating a building is pretty much impossible, even with advanced easy to use tools, but what about designing a toolshed. It's a simple and common task that requires a subset of the architects skills. What if I bought premade plans for a house and then customized them. Or what if I want to create a model of a house to give to an architect to flesh out. These are all examples of where I, as a layman, could use a subset of an architect's skills in a constructive manner, even though I would never be trusted to design and entire building. And all three of these cases have good analogies in GUI programming.

  Saying that "Coding is not something that everyone with a WYSIWYG editor should be pumping out" does not recognize the world we live in. One where there is lots of coding that can and should be done by non-professional coders.

  - Joshua

  Posted by: joshy on November 10, 2003 at 10:20 AM

• Here we go again
  If Sun removed Swing's warts and made it easier to use, we'd see better, not worse, desktop GUI applications written in Java.

  As it stands, developers either have to spend inordinate amounts of time laying out an interface, or they simply lose patience and throw an unattractive and awkward interface together. In the former case, this means less time is available for focusing on the actual functionality of the program. In the latter case, all the functionality in the world is for naught if it is difficult to access. In either case, quality is the victim.

  A much better way to separate the wheat from the chaff is to evaluate the code a developer writes. The elitist chaff may pride themselves on writing overly complex code and APIs that only those in their "inner cirlce" can comprehend. Meanwhile, the elegant wheat will write code which might seem slightly less powerful when counting function-points, but is in fact much more powerful because it can actually be used to build powerful applications that can be understand and maintained by all.

  As both software users and software developers, the most important thing to use should be how efficiently we and our customers can get our work done.

  Posted by: jimothy on November 10, 2003 at 10:31 AM

• Re: Here we go again
  There are a lot of APIs out there that the non-professional coder can use.

  I disagree that JFC should be made easier to allow anyone and everyone to utilize it. If a programmer cannot understand JFC let them use AWT. It is VERY simple to use and can be ported by a professional coder to JFC easily.

  The coding world that we currently live in has a flaw. Programmers are not treated like engineers when they should be. Not just everyone can walk in off the street and re-wire a building or design a building for that matter. There are standards set in stone that determine whether or not a person is qualified to do these tasks. I feel that coding should be no different. No I am not suggesting that everyone must have x number of college years, etc. College is not a quantifier of good coding skills. However there are tests that exist that can quantify a coder's skills. And I feel that is a direction we need to head in.

  Posted by: mzarra on November 10, 2003 at 10:40 AM

• Re: Here we go again
  Swing does, as you acknowledge, have a steep learning curve. By your argument, then, GUIs developed in Java should be superior to those developed in more accessible GUI frameworks. Legions of Java developers and webloggers would disagree. And legions of ordinary Joes would have no idea, because they've never used a Java GUI desktop application. Perhaps there's some truth that Swing isn't quite ready for primetime.

  Both criticism and defense of Swing should be withheld until you've had experience with other GUI frameworks (whether native or cross platform). I might grant you that the low barrier of entry to the Java language as a whole has attracted developers with little experience in other languages and environments. These developers often adamantly insist that the Java way is the only correct way. I gently suggest you ask yourself if you might not fit in that camp.

  In contrast, Apple, for instance, provides an exceptional tool (Interface Builder) for laying out user interfaces, and a framework (Cocoa) for wiring everything together. This has lead to the release of a great many attractive, intuitive, and genuinely useful applications. Sun, the vendors, and (dare I say) you could likely learn a great deal by taking a look how things are done outside the world of Java and Swing.

  Posted by: jimothy on November 10, 2003 at 11:09 AM

• Re: Here we go again
  It seems you really lack the social skills to see the mistakes you make in your assertions, since the 'elite' title is seemingly misunderstood. I'm not going to pretend to have all the answers; but I really would like to explain a couple of things.

  First of all; it is not your place to decide who gets to program Swing applications. Not any less then I can stop you building your own house. If you want ,please go ahead. This kind of decision making is the basis of freedom, and you saying that you don't want others to try really hits a nerve. Ask your local political person to explain this to you.

  Moreover; the solutions of a difficult API is not causing the effect you claim it has. Your guesses will benefit from some real-world experience.
  The effect of hard-to-learn APIs is that the majority of the time spent using it will be finding out things that should be obious. The people you think are really good still spend too much time working around the API and the end-result is that the product is of less value then it could have been.

  Your pointer to JGoodies is quite funny; many of the points the blog posted as being a problem have been solved in the framework. It has its own layout-manager for instance. The end result is that newbees go over to Karsten and learn how to create good looking UIs in very little time using that framework. So, in your logical JGoodies should not exist...

  Please talk to more people and basically make sure you have proven your points to yourself before making a fool of yourself.

  Joshua; I'm sorry to have used your blog for this; but when I see this blatent ignorance being expressed on a public forum I really feel it should be corrected.

  Posted by: zander on November 10, 2003 at 11:22 AM

• Re: Here we go again
  Java is not my first language and I am currently writing this on a 12" powerbook.

  Yes Apple makes a great Interface Builder. It is a wonderful tool. However the GUIs that IB makes are quite a bit different than the current state of GUIs in Java. As you well know, IB creates instances of objects that make up the GUI that are then "freeze dried". Java's approach is quite different.

  If Sun or anyone else were to come out with a way to produce GUIs for Java the same way that Apple does then GREAT!!! But until that time comes, my arguments for Swing stand.

  I would also point out that there are quite a few people in the world who are using Java Applications on their desktop and are not even aware of it. Granted they are not nearly as proliferate as C programs or even C++ programs but they do exist. They are being used and the true "lay person" has no clue they are using Java.

  That is a sign of a good Java JFC application. The user should not have to be concerned with the language that their program is written in, the program should just fit their needs.

  Posted by: mzarra on November 10, 2003 at 11:25 AM

• Swing failed??
  Hihi :-)

  our solution uses a designer that runs on all platforms, and is not a java application, making it easier to roll-out. (just one executable!)

  The file it saves can currently be used to create either Swing or AWT Guis, so you can use one code-base for your PDA and your desktop application.
  We have plans to generate SWT code as well; and we would like to see other platforms to be added as well, in an open source mannar.

  Posted by: zander on November 10, 2003 at 11:30 AM

• Re: Here we go again
  I agree completely that a good Java JFC application should not be distingishable from a native app. In fact I'm working on an article about just this thing. However we aren't there yet. This is one of my complaints above.

  I love the way Apple freeze dries the components and I wish Swing had such a capability. (as I also mentioned above with the XML representation thing). I don't know if it's Sun responsibility to provide it, though I would think that it's certainly in their interest.

  - Joshua

  Posted by: joshy on November 10, 2003 at 11:50 AM

• It is definitely feasible !!

  I'm not sure I agree that Swing has failed, but I do agree that it does have
  limitations in and of itself especially if you want to build thin client GUI
  interfaces using it.
  To effectively and efficiently build distributed Swing-based Java applications
  you need a framework that can do the following:
  
  - Deliver a Java Swing-based application in a thin client footprint.
  - Provide a visual RAD environment - to support rapid prototyping and development.
  
  - Provide simple unified APIs to manipulate data in the model of each control.
  
  - Interoperate with Web Services.
  - Provide record locking.
  - Utilize a full-featured event model that allows the developer to intercept
  all client events.

  XML Tunneling Technology (XTT) version 3.0 - a leading edge tool and framework
  for developing ultra-thin, rich GUI, distributed Java applications solves these
  problems and in doing so is changing the existing server side Java development
  paradigm.
  XTT delivers a pure Java Swing thin-client application that uses XML to marshal
  data back and forth from the app server to the client. Unlike other tools that
  use a Java server-side programming model, XTT allows you to distribute your
  business logic on the client or app server. XTT even allows you to run the application
  while not connected to the Internet.
  Out of the box, XTT provides the components necessary to handle most business
  problems. In fact, key features include pessimistic record locking, strong event
  processing, data streaming, built-in verifiers and formatters, as well as a
  very intuitive VB-like RAD environment. The XTT Framework is targeted at building
  enterprise-class applications with complex transaction-oriented user interfaces,
  required in vertical markets such as health care, financial services, insurance,
  and manufacturing. XTT integrates with Sun ONE Studio, NetBeans and JBuilder
  IDEs, for integrated development and deployment of J2EE and rich GUI J2SE applications.

  Why not download the Free Community Edition of XTT and try it for yourself.

  http://www.insitechgroup.com/download
  
  

  Posted by: jvillano on November 10, 2003 at 11:56 AM

• Re: Here we go again
  Zander,

  Flaming everyone into seeing your point of view is not the answer. I am going to end trying to debate with you on this issue at this time since clearly you cannot debate in a polite manner.

  You may not like my opinion and I may not like yours. However I am not interested in slinging mud with you. I posted my opinion and people have disagreed with me. Great, differences of opinion are what make the world great. Constantly insulting me in every post you make is a waste of energy.

  Good day to you.

  Posted by: mzarra on November 10, 2003 at 12:25 PM

• Re: Here we go again
  I would agree that the "common" app is not there yet. I also agree that Swing is not perfect. But there are quite a few very good applications out there written in Java and written in Swing.

  If there was a way to create applications in a "freeze dried" manner for Java that worked cross platform and wrote good code underneath to hook into it then that would solve a lot of the problems we face today with people trying to shoe-horn stuff into guis and settling for just making it work.

  I do feel that creating good applications in Swing can be done but it takes effort. Just like the Unix CLI is harder to use than the Windows CLI it is also more powerful, so is true with the JFC.

  Posted by: mzarra on November 10, 2003 at 12:29 PM

• Re: Here we go again
  The first step to getting there (a "freeze dried" GUI framework/tool for Java) is stop stop having the tool generate code. Both the layout and the bindings can and should be "freeze dried" to XML or otherwise.

  Swing's complexity does not come from its power. I'd argue that Swing is both less "powerful" than and more difficult to use than the native toolkits I have worked with.

  (I'd also disagree that the Unix CLI is more difficult than the Windows CLI. Part of what makes the Windows CLI so difficult is how much power it lacks. This is offtopic, but is another illustration that power need not be proportional to complexity).

  Posted by: jimothy on November 10, 2003 at 01:28 PM

• Re: Here we go again
  I Indeed am not know to be subtle, but be sure my posts were not meant to 'sling mud'.

  I may have not expressed the point I got upset over very well. Your attitude towards 'inapt' programmers is an insult to all those that have worked to become good programmers.
  Remember that you were a beginner some day as well, and without experience you can't get to be one of the good coders.

  A good night to you, and I wish for a fresh awakening tomorrow.

  Posted by: zander on November 10, 2003 at 02:41 PM

• Total Misunderstanding of Swing
  I'm really disappointed in this article. I really expected much more from the "expert" bloggers they let post on java.net. There are plenty of valid reasons to criticize Swing but "Swing is not VB" is not one of them. Swing is **not an application framework**. This should be obvious to anybody who's spent even just a little bit of time with Swing. There is no javax.swing.Application class and there's nothing about 'applications' in the Swing codebase. All Swing does is provide an extremely powerful, flexible, and robust foundation for building *complex* rich clients. In my opinion, it's the best tool out there for creating slick desktop applications. (WinForms is pretty good but as it's not cross platform is a dead end. The various open source frameworks like wxWindows all, IMO, either have serious architectural issues (using native peers) or are just very buggy and poorly documented).

  Having said that, there's still so much wrong with this article that I don't even know where to begin. Try asking the Delphi people if having a Visual "RAD" tool really lets you quickly build complex applications. Or ask all the poor schmucks out there who spend their days maintaining VB code if VB is a real foundation for client development.

  And as for the need for an "intermediate API"--well this should be obvious. Many such intermediate APIs have been built. I've been working on an Swing application frameworks for quite some time (I'd rather not call it "Struts for Swing" as Struts isn't very good but the comparison is valid) called "skip" which I'll probably open source sometime in the future. Still, IMO, anybody who's taken the time to learn Swing shouldn't have too much trouble writing highly reusable components. I know it's certainly not been a problem for me. I'd also like to suggest the fact that Swing doesn't force you into a single application model is actually a very good thing and one of the reasons Java's been so successful in general. Like many other Java APIs, Swing gives you a solid foundation and then leaves you *free* to choose how you're going to build on that foundation.

  BTW, the metal L&F is a really cheesy L&F that has no place in the 21st century. But it's been said many times, if you read the javadesktop forums, that the Metal is getting a big update real soon. Even so, there are so many really nice, open source L&Fs out there and Swing makes switching L&Fs so incredibly trivial that complaining Metal is just dumb.

  Anyways, hopefully in the future a little more thought will be put into these rants. Calling Swing a failure, particularly when you don't understand what it is Swing does, is just silly. In the future, I'd suggest you approach the problem the other way around. Rather than starting with Swing and being disappointed in what it doesn't do, start with the problem you want to solve (e.g. build rich clients that interact with web services) and consider what Swing offers you.

  Posted by: ocean on November 10, 2003 at 02:51 PM

• How about a micro-Swing + SWT
  Although this goes against everything philosophically imposed by Swing, I think we need to separate different aspects of GUI building:

  1. standard GUI controls (listboxes, buttons, etc.) - for these it is best to use native controls for the fastest speed and most up-to-date features, like SWT in java, or wxPython in python (there is a wx4j being started for java too).

  2. Internationalization & Portability - these are imposed on us before we even start a GUI, and force everyone to use complicated layout managers. If we separate these goals, we could let programmers more quickly make prototypes, and then later add code to handle internationalization and cross-platform issues.

  3. Custom controls - the "canvas." This is one of the strongest parts of Swing & AWT, making custom controls. You don't have to worry about Windows-specific DC objects, etc. Maybe someone at Sun could make a "micro-Swing" that only keeps the part of Swing useful for making custom controls that could be plugged into a SWT or other native interface. Also, even though Swing is strongest at this, doesn't mean it is great. The JComponent could be broken into parts too, so that for example, we could more easily create lightweight subcomponents that share the graphics of a container control. In the "Java Custom UI Components" book they had to do this, for example.

  4. Programming hooks to the GUI and event handling. - There's no way around this - the java language is not easy or quick to use. I find it much more enjoyable to do the programming in jython/python or you could use other java-compatible scripting languages like javascript (Rhino).

  5. C extensions for GUI apps. JNI sucks. There are much more SWIG/Boost extensions to Python than JNI extensions to Java. Take for example two things I can do in a desktop Python (or C) app that cannot be done in a java app: I can embed Internet Explorer (and soon, Mozilla) in my app, and I can interface with force feedback joysticks.

  6. Multimedia support - movie playing, mp3 playing are a strong point in Java using JMF or QTjava..Media editing/recording though is weak in most all of the free or open source GUI toolkits.
  

  Posted by: dug on November 10, 2003 at 09:28 PM

• Make it Open Source
  We know there is to much homework in Sun, I prefer to make Java SDK including the Swing, com.sun.compiler become Open Source,and make it become java.compiler, rather use com.sun

  I dont think Sun can win the Desktop market for Java System (Desktop). So, be focus on Java.

  Posted by: fthamura on November 10, 2003 at 10:07 PM

• try NetBeans form editor
  try NetBeans form editor, and you'll never will be doing any GridBagLayout'ing by hand. It's visual editor is _perfect_, I mean it.

  Posted by: mihmax on November 11, 2003 at 02:04 AM

• Re: Total Misunderstanding of Swing
  I agree that Swing is not a framework. It is a GUI toolkit and nothing more. However, in order to build good GUI apps we *need* more. I'm not saying that we need to modify Swing to provide all of these things, but these do need to be invented and popularised as additions to Swing in order for Java to have any real future on the desktop.

  VB is not Visual C++ and MFC, but if you want to whip up a quick application for Windows Microsoft provides a tool to do this: VB. VB is a simplified programming environment wrapped around MFC and C++ controls. If you want to whip up a quick Java app, how do you do it? Sun doesn't provide a way. It's Swing or nothing. I'm not saying that Swing should become VB. I'm saying that we need a VB style editor on top of Swing. Also note that I'm not advocating VB as a language but as an IDE and component model. Javascript or Python would be much better choices for the language of our Swing VB.

  Swing does need an intermediate API. Some exist already but aren't popular. Why? That's the discussion I want to have. There are solutions, many already existing, to the problems listed above. How can we make them more widespread? That's what I want to talk about..

  I am very aware of what Swing does. I've used it for many years and worked on some of it's predecessors. I am very familiar with it's strengths and weaknesses. It has great potential, much of it underused. I want to critique Swing so that we can address the real problems and start to make some real headway.
  

  Posted by: joshy on November 11, 2003 at 06:14 AM

• try NetBeans form editor
  I couldn't agree more on the comment on the Netbeans gridbag layout tools. They are truly excellent.

  Having said that I agree with the notion that Swing is not trivial to learn in general and that there is not much in the way of documentation for standard approaches to development using Swing. Maybe a framework would help but I also fear that adding layers may end up complicating things more.

  I believe the idea for a improved standard L&F is great but it will not address the problem of your apps not having a native L&F.

  Unfortunately I have limited experience in bulding GUI's in other languages with other tools so I can't really compare with them.

  Posted by: jmelchio on November 11, 2003 at 06:57 AM

• Component repository
  As far as a Swing component repository goes, our company (eInnovation, Inc.) has a bunch of open-source, reusable Swing components, among other things, in the following project:

  http://www.einnovation.com/projects/eiicommons/

  It's constantly evolving, but we've used many of these components in various projects that we've done. Included are masked edit controls, a sortable JTable, a wizard framework, and an Eclipse-style view framework. We've also got a print preview widget in the wings that we're going to add to this Real Soon Now[tm].

  Take a look, check out the code, join the mailing lists, and let us know what you think. :)
  

  Posted by: egalluzzo on November 11, 2003 at 08:07 AM

• VB for Swing
  Josh,

  Mostly, I agree, but I must take issue with some points. "VB for Swing" is a great idea, and much needed. I would further suggest that

  1) It must be easy to move back and forth between this new upper layer and Swing
  2) It should come in several different flavors. There are strengths and weaknesses to any one language (Java, Beanshell, Jython, Javascript) and any given application model (table based database-driven, single document centered, etc...). All should be supported, but there is no way to support everything in a single simple IDE. I suggest multiple targeted IDEs.
  3) Threading is what trips up many complicated Swing apps. There is stuff in Tiger to address some of the issues that complicated apps face (util.concurrent, JSR-174), but there is still a strong need for a framework for highly-multithreaded desktop apps. I doubt that there is much that can be accomplisded on the IDE front for such apps. Without a few applications based on it, such a framework can't be written. Unless those applications are open-source, such a framework won't be widely adopted. Does anybody know who the existing players are in this area? Here's one:
  http://thinkfree.com/

  The on-line documentation for Swing is quite nice, but doesn't go far enough. The new WebStart links are great. Imagine if there were also WebStart links to start the examples in a simple IDE. Imagine if components from the on-line docs and from the SwingSet demo could be drag-and-dropped into the IDE. That would be pretty friendly for beginners.

  Swing doesn't suck, it just isn't enough. It lacks the frameworks required to scale gracefully to increasingly complicated tasks.

  jEdit rocks. There are other Swing apps that do, too.

  "Swing layout managers suck. GridBagLayout is particularly bad, though it's better than all the others. Layout is an inherently visual task that needs visual tools. I wouldn't layout a magazine with a text file, I'd use Quark. Why shouldn't I have a quality visual builder for my Swing app?"

  Because readers can't resize magazine pages.

  Posted by: coxcu on November 11, 2003 at 12:06 PM

• Re: VB for Swing
  Who are you, my twin brother?!!! I agree completely with every point.

  There should be multiple IDEs with a screen definition file format for interchange.

  For threading I really think that there should be more abstracted objects to handle it. There are so many ways to decouple background processing from the UI that it becomes very complicated. I would like a couple of different objects that I can subclass and register and have it take care of all of the threading issues.

  I'd love to see the kind of documentation/IDE integration you are talking about. Not just for beginners. I'd love to use those kinds of features too. Much like the jEdit plugins (jEdit is my favorite editor as well).

  - joshua

  Posted by: joshy on November 11, 2003 at 12:19 PM

• In defense of Layout Managers...
  Josh,

  First a clarification: VB wraps COM, not MFC, and MFC is best thought of as wrapping Win32.

  As it's already been stated, most Java IDE's have a forms generator that's easy to use.

  I'll go out on a limb and state that Swing is easier than VB, although Swing's flexibility can make it appear more difficult at first glance.

  For instance, VB uses a simple, absolute grid to position controls. But to handle form resizing, one must write code.

  While in Java, one can either reproduce this exact behaviour with the AbsoluteLayout manager, or eliminate the resize code completely by using one of the other layout managers.

  If someone is serious about Swing, they should spend some time writing AWT and Swing components in vi or any editor. They should layout out the gui w/ pencil and paper, and try different combinations.

  Once they feel comfortable with the layout managers, they can go back to the IDE.
  With the new understanding, they will surely be less frustrated. And there will always be AbsoluteLayout for the casual user.

  Swing if flexible. But a framework just to simplify it is unnecessary. Program organization should be planned at design time or in the organization's standards process.

  If maintenance programmers don't know where to find parts of the code, there are design and documentation issues.

  And as far as text goes, John Zurowski's Definitive Guide To Swing is quite good.

  As many people have already said, 'just because the features are there, doesn't
  mean you have to use them.'

  Let's keep Swing flexible, and leave the work of simplification to tools...or perhaps a handy xslt file...
  

  Posted by: d_bleyl on November 11, 2003 at 02:28 PM

• Swing is close
  Nice topic, hope this generates a lot of activity.
  Bottom line is that Sun has built Swing to a level that is very powerful and flexible. It is very consistent (MVC) and has common generic ways of using it for simple things, but allows the programmer to have an extensive amount of control. I think that Sun did a great job of not "over doing" JFC - by creating a base that is easy to expand. We have been able to take the JFC components and make them "Object Aware" so that they will work directly from an object model. For the most part, all that was required was to implement the component data models to work with an object model.
  A lot of programmers I know who use VB could not write a VB programs without the VB IDE. Try writing a VB program using notepad? You find out real quick how bad of a language it really is. M$ has been very good at creating visual "code generators" that hide the ugliness of their languages and APIs.
  

  Posted by: vvia on November 11, 2003 at 10:50 PM

• Swing's dance over OS
  In my personnal experience of using Swing, I greatly regret the dependance of Swing with the OS that makes it
  impossible to create an Interface like ThreeDegrees' or
  certain skin of MediaPlayer$ !

  Sure it's possible to do everything you can do with VB, but with VB I can go further like drawing a completely new interface...

  And that's a fact: for an application that wants to attract a large audience the look makes the difference !

  Posted by: guimel on November 12, 2003 at 02:08 AM

• Swing is close
  "Try writing a VB program using notepad?" Why would anyone want to do that?

  Posted by: vazz on November 12, 2003 at 03:28 AM

• Re: Here we go again
  -----Part 1------------
  I think every one is right here, may be should we put the things in a different way: the needs are easy, standard and open.

  1. easy: we need as beginner to be able to learn and do things, as "senior" be able to do it very quickly. Swing should be viewed as a low level framework and an "easy" GUI, named ?? Swing, a high level framework

  2. standard: to be more interresting, a high level GUI framework should be standard, so that every one is interrested to learn it

  3. open: even if some one is using the high level framework he/she should be able to switch back to low level stuffs

  On top of the easy framework any IDE tool can provide its own way to present the framework. Like you write java code, the compiler translate it to byte code for the JVM.

  -----Part 2------------
  Another thing I would like to point is, about elits... Today we can see two kind of "programming people" (I want to be short here). One kind is professional, the other one is people that try to do their true job (like physicians and other) using computers (PCs) as a tool. I think the real target of VB-like environments is every person not beeing an IT developer/prefesional? (I guess VBA-Excel, VBA-Access are even more representative)

  I would compare this separation to the need to replace a lamp, I do it myself, but I won't replace all the electricity in my house... I prefer calling a true professional.

  Jean

  Posted by: jeanlazarou on November 12, 2003 at 03:42 AM

• Re: Swing's dance over OS
  I'm not sure what you mean. Are you saying that you would like to completely customize the widgets to make the look like something that's not native, like the usual mp3 player skins? This is possible pretty easily by just overriding the paintComponent methods of standard Swing components and using an AbsoluteLayout manager.

  Do you think it should be easier to do this kind of customization, or is there a feature that's missing.
  Would you like to see an article on how to do these kinds of things?

  Thanks
  - Joshua

  Posted by: joshy on November 12, 2003 at 05:23 AM

• Re: In defense of Layout Managers...
  I agree. Swing is easier than VB for advanced features, but is much easier for beginners or for advanced developers doing prototyping.

  I do write my GUI code in a text editor and I start out with paper and pencil, but I keep feeling like widget layout should be done visually since it is an inherently visual task.

  Swing is very flexible. It's a great foundation that provides a lot of benefit, but I'd like to see more systems built on top of it to make the programmer more powerful.

  I really want to make this clear. I don't want to change Swing itself that much. I just want to add other things on to it, and have those other things be standard and open.

  Posted by: joshy on November 12, 2003 at 05:32 AM

• Re: Swing's dance over OS
  Joshua,

  Yes , it's what I mean !
  I've seen in Cole/Eckstein 'Java Swing' that to completely recreate a new L&F (Look&Feel), 'from scratch', I must extend LookAndFeel class and then each UI delegates in javax.swing.plaf !

  It's not really what we could say 'easy' !

  Have you another mean ?

  I'd like to know it ,!
  thx
  -Simon
  

  Posted by: guimel on November 12, 2003 at 05:50 AM

• Re: Swing's dance over OS
  It depends on what you want to do. You can create an entire L&F but for just one app there are easier ways. Creating a L&F will separate the look of your widgets completely from the widgets themselves. The upside is you can apply a L&F without changing your code. However, if you want a pretty UI for one app based on images and custom drawing code, there are much easier ways to do it. It just means you have to modify your code to do it. I think I'll have to do this in another Swing Hack.

  - Joshua

  Posted by: joshy on November 12, 2003 at 06:03 AM

• try NetBeans form editor
  The netBeans GUI builder really is pretty good, but if it has one fault, it is the lack of a top notch layout manager. The ones which are included are OK, and using them, one can get a GUI up and running pretty quickly. But there are minor problems, which taken in whole reduce the resultant GUI from "best" to "pretty good" (IMHO). (These are visual issues like conformance to the Java L&F guidelines, lining up buttons and text fields at font baseline, etc...)

  Much of this is talked about in the javadesktop forums:

  http://www.javadesktop.org/forums/thread.jspa?threadID=42&tstart=0
  http://www.javadesktop.org/forums/thread.jspa?forumID=2&threadID=82&messageID=2534

  NetBeans needs to add SpringLayout, JGoodies Forms, or NaturalLayout (or ideally, all of the above). Or, it could just make layout management pluggable.

  Posted by: jtr on November 12, 2003 at 07:22 AM

• Re: In defense of Layout Managers...
  That sounds a lot different than 'Swing failed' or 'Layout managers suck'.

  For me, Swing gui prototypes are fast and easy, even with an xml file or db connection to populate a few combo boxes or generate a list of check boxes on the fly.

  I'm still struggling with the idea that it is somehow good when an inexperienced developer drops buttons on a form in order to demo the prototype to the user.

  When the user assumes the project is 80% done, the poor developer scurries off and proceeds to fumble over code crammed into one on_click event handler.

  Obviously there is a maintenance issue here, and most definitely one of quality. But this rookie developer is none the wiser.

  In fact, in his mind, there is no such thing as a windowless application. His IDE has convinced him it's best to drop a button called 'Go' on a form and put all the code in one handler.

  Now this would infuriate any VB developer who has taken the time to learn best practices, or really understand the tool, but unfortunately, it's a label.

  It's one thing to add a separate tool or framework like Struts on top of Swing for the people who need it. Why not? Is it necessary to have a standard? Struts didn't need to be a standard to succeed, it's success helped to form a new standard.

  
  

  Posted by: d_bleyl on November 12, 2003 at 07:23 AM

• Swing is close
  You can create some vb programs with notepad, because some VB code is valid VBScript code:

  'Start program
  msgbox "I'm a window created in notepad"
  'End program

  It's completely unfeasible to write a real vb program in notepad, and I don't think the poster is advocating that.

  I believe the point is that if you *could* write a VB app in notepad, like you can a Swing app,
  it would mean that, in theory, you could develop practically anywhere, and have an abundance of tools to choose from, like JBuilder, NetBeans, Eclipse, IDEA and more, because the API is clean enough and worthwhile enough to build different IDE's on.

  The test is, if you can do it in notepad, you can do it anywhere. It's also a sign of usability and intuitiveness of the API. But in VB's case, it demonstrates that it is a completely closed system designed to foster dependence.

  
  

  Posted by: d_bleyl on November 12, 2003 at 07:36 AM

• Re: Swing's dance over OS
  Hi Joshua,

  I thought you were telling me an interesting reference
  on the subject....

  Anyway, it seems that it's easier to do that with AWT
  than with SWING !

  So back to the departure ?
  
  -Simon

  Posted by: guimel on November 12, 2003 at 08:40 AM

• Why Swing?
  What's wrong with AWT? Wait, let me ask that again. What's wrong with AWT that Swing fixed? Layout manager, threading issues, lack of visual layout tools; Swing is no better than AWT in those regards.

  Basically, then, the problem with AWT boils down to its sparse set of widgets. Ok, Swing improves MVC support with things like ListModel; those should be there along with a richer AWT.

  Correct me if I'm wrong, but isn't what we really want from Java is the ability to do what we can with other languages: Write a program that looks just like and is just as responsive as a program using native widgets because--of all things--it actually uses native widgets?

  For the most part, I can't tell if an application is written in C, C++, C#, Objective-C, or, heck, Pascal just by looking at the interface (or from the steps I have to go through to launch the application, for that matter). So, why, oh why, can I tell in a moment that I'm using a Java application?

  Sun, swallow your pride and expand the set of native widgets in AWT. I hear IBM has a little something that might help you out.

  Posted by: jimothy on November 12, 2003 at 03:20 PM

• Swing Flaws - Inherent?
  Hi All,

  I've been writing Swing apps for several years that many people find elegant. And I teach developers in working with Swing efficiently: how to design, layout, implement, bind and validate data, finding an appropriate architectures, etc.

  I'd say that your analysis describes well how Swing is perceived by the majority of developers. And you mention some of the biggest obstables developers face when working with Swing. But it doesn't follow that these problems are inherent. I've found that almost all problems you mention can be addressed by code, libraries, the app architecture, patterns, general programming practices, and well-designed examples, tutorials, etc. And I've found that the average developer can work well with Swing, if only taken by the hand - in about 2 to 10 days.

  Now let me comment your analysis. Many developers I worked with were slow in finding design, implementing layouts, building panels, binding data, handling events, and arranging the different code parts and code layers. I've found that one can boost a developer's productivity a lot - to the extent that the Swing work takes only a small fraction of the whole project. I teach a Swing application development process that is based around a multi-tier architecture, that seperate the domain, tool and presentation layers clearly and that is based on a productive layout system. Even though most parts are done programmatically, developers get results quickly and both the code and visual design is quite consistent.

  I don't inherently favor hand-written code over tool support, the contrary is the case. But from my perspective most Swing builder tools fail to produce consistent, high quality UIs quickly. Building a Java desktop app can be a difficult task: if you aim to support multiple platforms, multiple L&fs, fonts, fonts sizes, screen resolutions, and locales. For example, I'd say that even one of the well-received tools, Jean-Marie Hullot's InterfaceBuilder doesn't address all these tasks. Most of my customers favor to hand-build a consistent high-quality editor in 1 hour over using a tool that produces inflexible, inconsistent, poorly portable screen design in half an hour.

  I once worked with a a Swing team for a design company that produced both print media and screen design. The traditional design team outperformed our Swing team by a factor of 10 to 20 - although we felt that we were the much smarter team. The designers use paper and pencil as well as tools like PhotoShop to find and produce a meta design (or design module). Assistent designers instantiate these and generate a bunch of designs. And finally an implementation crew hand-writes HTML code.

  I tried to bring this process to Swing, and you'll find many of these steps supported by the open source, no-charge Forms layout system that you can download from JavaDesktop.org. Currently the framework lack tool-support for finding design. A tool for editing FormLayouts are under way.

  Do Swing layout managers suck? I agree that the JRE core layout managers are a source of trouble. I've analyzed several problems and provide an article about these problems, a set of layout goals and a sample solution for the layout and the layout process. See http://www.jgoodies.com/articles/ In short: there are Swing layout managers, and more generally layout systems, that don't suck, that are quite easy to learn, easy to work with and that produce layout results that can compete with and can outperform modern native layouts.

  I've seen many Swing apps that are horrible to understand and to maintain. Mostly because the developers had no guidelines to follow: Where to put what code? How to separate concerns? How to work with Actions? How to launch an app? Etc. But it doesn't follow that this is a Swing problem. As a counter example, there are well structured and well designed Swing applications; but it seems that only a minority knows about good Swing practice patterns.

  I won't say that Swing is too powerful, but it has a quite large conceptual weight. And nobody will deny that this leads to a high learning curve. Swing is a widget toolkit, plus extensibility, plus MVC framework, plus exchangeable look&feel. I've never met a single developer who faces large problems with the Swing widget toolkit API. The UI components are quite easy to learn and to work with. Almost all problems stem from poor implementations in the UI delegates - a thing that can be fixed, and that has been fixed by third parties. I recommend that novice Swing developers focus on the core tasks of UI development before they explorer the more advanced features of the framework. This seems to be an approach that works. I personally can work much better with Swing than with all other toolkits or framework I used before: I can do more with less code, the code is better structured, and I get results quickly. Swing's extensibility allows me to do things that one can hardly implement with native toolkits. I will show some of these features and how they improve the usability in upcoming demos that I will publish in a JavaDesktop.org 'Demos' project.

  I like that you turn your analysis and the whole text into a productive discussion. I wholeheartly agree with the need for options beside the Metal l&f. In my opinion there are already some useful and more or less professional third party l&fs. Also, Sun is working on a new default l&f that I like a lot.

  Just like you, I often mention that Swing needs something like Struts. I've worked with a team of MVC, object, J2SE, JSP novices and Struts and the Struts sample applications have always guide the team members so they could hardly fail. I think that one can port this aspect of Struts to Swing, and I aim to do so. I want to provide a draft of my unofficial Java desktop blueprints for the JavaOne 2004. And will demonstrate _an_ approach how to address the many common Swing tasks. That effort is combined with the production process mentioned above.

  I agree that the cross-tool UI representation may help, but I don't see this as the very next step. In my courses, developers face many other problems before screen design or changing the UI tool stiffles their productivity.

  In my above comments of your analysis I just wanted to point out that the Swing problems are not inherent to the toolkit. I'm not saying that Swing is easy to work with, easy to learn for the average developer. The contrary is the case - again, unless there's some help. Therefore a VB-like tool support would definitely help Swing, so that non-coders can build at least the simple data presenters and editors.

  I don't think that we need an intermediate API but a bunch of good practive patterns, well designed sample applications and prepared solutions.

  In my opinion many of the Swing articles and books are part of, or the source of the problem. I've found that Swing is ready for production, but obviously many developers fail to work with Swing. And many developers are not dumb but especially smart. So consequently the problem lies somewhere else. I'm sure that articles and a book will help. I've started a series of articles and presentations about layout, and a First Aid for Swing. These will be published at JavaDesktop.org and hopefully the first articles will be available in December.

  I like the competition you suggest. I've polished my JDiskReport application and turned it into a Web startable thing just because I had hoped to win the Web Start Deployment contest 2001 (?) - that then was cancelled.

  I'm looking forward to an interesting and productive discussion.

  Best regards, Karsten Lentzsch
  

  Posted by: karsten on November 13, 2003 at 06:45 AM

• Blogging = hyperbole

  I disagree very strongly with your BLOG.

  Swing apps are not any slower to build. In my experience, *complex* apps are faster to build in Swing than in any other UI technology (e.g. HTML/Javascript/JSP, Windows native). There are a number of excellent Swing GUI-building tools that exist. I'm fond of the one in Sun's IDE, but Visual Age had a nice one as well.

  Of course, I'm assuming that (1) developers actually stick with the tools and learn to use them pragmatically, (i.e. no "aw crap I couldn't do this one thing so I'll throw the tool away"), (2) the developers understand event-based programming, (3) the developers are instructed in the "best practices" of the platform. Any shop that won't commit to the education and methodological discipline necessary to do quality UI work should not be surprised at "slow" results, whatever the technology ... Swing, SWT, VB, or JSP.

  The Swing layout managers don't suck -- learn to use the tools. Conceptually, GridBagLayout is not that different than laying stuff out in HTML using tables. There are other layout managers out there in the public domain that might suit you better (e.g. that one with springs and struts.) I've found it straightforward to lay out complex windows using GridBagLayout and visual tools.

  Swing apps are no harder to maintain than any other UI app. It all boils down to process and discipline on your team. Garbage in, garbage out. No panacea is going to substitute for proper documentation.

  Swing is not "too powerful." Swing does what needs to be done at its layer in the coding stack -- I see you understand that given your "request to the community" for an intermediate API, rather than a request to Sun to make Swing more "high level".

  Granted, putting "Swing may be too low-level for simple tasks" in bold isn't as attention grabbing as "Swing is too powerful", but hey -- BLOGS are the best places for hype. I see your spin, and that is what it is.

  Every layer you build on top of Swing, every "simpler API", will necessarily exclude functionality that a portion of the user base will want. What you hide, someone will want to expose. You want to expose native features, and you want a simpler layer for developers. Uh ... ok. Riiiiiight. You can't have everything for free -- there is a cost.

  Swing apps have no worse a history than Windows apps. Did you ever use Windows 3.1? Microsoft's game for sweeping away bad-tastes from old platforms is to rebrand there APIs every couple of years. Should we ask Sun to rebrand Swing so we can say to our bosses, "This Java Widgex (tm) technology means are developers don't have a learning curve anymore! Everything is visual programming now, I promise!"

  Everytime a BLOGGER blogs hyperbole, they may gain undue attention, but the truth suffers.
  

  Posted by: cpu_fusion on November 13, 2003 at 01:19 PM

• Blogging = hyperbole
  Having used other UI toolkits and frameworks, I'll disagree strongly with your post. UI design absolutely can be easier than Swing, but I can't do much here rather than repeat what others and myself have already said, so there's probably not much use in trying to argue otherwise.

  What hopefully is a useful discussion, however, is your comparison of GridBagLayout to HTML tables. Conceptually, the concept is very similar: there are analogs to TD cells, colspan and rowspan, align and valign, etc. But here's the difference: HTML declaratively describes the layout, while Swing does it programmatically. And that's one of Mr. Marianaci points: UI layout should not be in code. He suggests XML or serialized beans.

  It may help to take the comparison even further. In HTML, tables are deprecated for layout in favor of CSS. Should something similar exist for Java? It turns out, Mr. Marianacci has also considered this idea.

  Posted by: jimothy on November 13, 2003 at 01:48 PM

• Blogging = hyperbole
  Ok, so we have:
  1. programatic layout;
  2. declarative layout;
  which can be accomplished via:
  A. layout using tools; and
  B. layout that is hand crafted.

  None of these are the "one true path". They are all valid, and they will likely need to be intermixed on any substantial UI effort.

  There are tools that allow (1) with both (A) and (B). (e.g. Sun's IDE)

  Because programatic layout exists, (2) can be accomplished by tools (B). If the tools exposes the declarative data, you can accomplish (A).

  As this BLOG says "Layout is an inherently visual task that needs visual tools. I wouldn't layout a magazine with a text file, I'd use Quark. Why shouldn't I have a quality visual builder for my Swing app?" Yes, such tools exist, and there is no reason why they cannot support declarative layout without any changes to Swing.

  Swing has hardly "failed" however, which is why I see the BLOG as overstated. HTML and Javascript hadn't "failed" before CSS; in fact, they all compliment each other. I see the same future for Swing.
  

  Posted by: cpu_fusion on November 13, 2003 at 03:07 PM

• Swing's bad rep...
  Swing has a bad rep because of basically two things.

  Show me some large desktop apps that run smoothly and without an incredible amount of used memory. I don't that this is impossible, I'm just saying there are companies worth billions of dollars who can't seem to do it so how can little old me do it.

  I hate 'metal' aughghghghhghghg!!!!! This must be the ugliest gui I've ever seen. It's got a default color of purple! Purple??? I'm supposed to pitch java to major corporations and the default color is purple????!!! Why haven't they change this. I mean, it's crazy.

  jbs

  Posted by: jseltzer1717 on November 13, 2003 at 04:18 PM

• Here we go again
  I've been told this for ever that there are good large swing apps. I used them all. What you're not telling is they only look good on machines with gobs of processing speed and gobs of speed. You know this and I know this.

  Posted by: jseltzer1717 on November 13, 2003 at 04:32 PM

• Swing's bad rep...
  One answer to both things: IntelliJ IDEA 3.0. Is full-featured IDE large enough for you ;-) ? Check it, it looks really sexy. And 4.0 is even more beautiful.

  First time I ran it I didn't believe that this is Swing app -- its performance is nearly identical to native apps.

  Also, I don't think that it's Sun responsibility to change metal L&F. We have several other options already. Check Kunststoff L&F (http://www.incors.org/). Or commercial Alloy product (http://www.incors.com/lookandfeel/).

  Next check http://www.l2fprod.com/ & http://www.javootoo.com/

  Posted by: silaev on November 15, 2003 at 06:37 AM

• Re: Blogging = hyperbole
  I said that Swing has failed because it hasn't lived up to the promise of creating high quality apps that we see everywhere. Why is that? Swing is a full featured API that lets you do pretty much anything, and with less trouble than MFC. So why aren't there tons of Swing apps? Why are all desktop apps written to native, mostly Windows, APIs? That is what I'm trying to get at. I listed off the reasons why I think this is the case and what we can do about them.

  In my opinion, Swing has succeeded in being a robust programmatic API for developing portable GUI applications. It has failed, however, and being a *popular* system for powerful and attractive desktop applications.
  - Joshua

  Posted by: joshy on November 16, 2003 at 07:15 AM

• Re: Blogging = hyperbole
  There is one main reason why has Swing failed - it is not native. Two simple examples:
  I have Vim installed under Windows. The install program added an entry in the file context menu - edit with Vim, which is very handy. Whenever I open/choose a file in a file-open dialog, I can right-click on the file, see it under vim with syntax highlighting and decide whether it is the right one. Of course, it doesn't work with JFileChooser and never will.
  Another example - html rendering. Every modern OS has a web browser. Of course Swing doesn't make use of it, it has JEditorPane. which cannot render anything correctly. If I write a RSS client, I cannot show to the user the page behind the link in a news item correctly.
  Another point to consider - native widgets are usually written in C (Windows, Gnome) or C++ (Qt, KDE). They are integrated with the OS, that Java has to use sooner or later. Thus naitve widgets will always be faster - using Swing punishes the developer and user and gives nothing in return.
  FInally, an app shuldn't require anybody to install additional packages like jre.
  I have one, very important questions to Swing desingers, that bothers me. Why Swing is not normal, like *every* other toolkit in the world? What is the purpose of it being not native?
  SWT/JFace is very well thought, looks normal, behaves normal, is normal. In eclipse 3.0m4 I can even call a web browser (ie under windows) within several lines of code and control it - it's a dream!
  The only thing that swt/jface lacks is integration with default j2se and good documentation
  Of course Sun won't give up Swing and replace it with something decent, because they resent IBM and will promote Swing till they go bankrupt. or java dies.

  Posted by: mic256 on November 16, 2003 at 09:25 AM

• Swing's bad rep...
  I'll further qualify jseltzer's request to be shown a large, stable, and responsize applications that is not for developers, by developers.

  As far as look-and-feel: If the goal of Java on the desktop were to produce applications that are indistinguishable from native applications--which I think it should have been--we'd have no need for Swing's pluggable look-and-feel (PLAF) at all.

  PLAF doesn't come cheap. It saddles Swing architectural and performance artifacts that affect both the developer and end-user experience. For programs where a skinnable or custom UI is desired, there are other libraries available that support these features. I just don't feel a non-native appearance should be in the de facto Java standard for GUI development any more than it belongs in another language like C or C++.

  Posted by: jimothy on November 17, 2003 at 07:15 AM

• Re: Blogging = hyperbole
  "Creating high quality apps that we see everywhere."
  "Poweful and attractive desktop applications."

  So you are disappointed that the shelves of your local software retailer are not populated with Swing-based apps, nor is your Linux or Windows distribution delivered with Swing apps, nor are there web pages full of swing applets on your favorite sites. Fair enough.

  However, if you do look around some, such as:
  http://java.sun.com/products/jfc/tsc/sightings
  or, if you look at the custom applications many I.S. shops are developing in house these days, you will find that Swing has been creating high-quality apps; powerful apps; attractive apps.

  True, your CD/DVD creater, your MP3 ripper, your graphic arts program, or your favorite 3d game aren't in Swing ... but if you think about it, that's hardly surprising. Once you get over a certain need in terms of app horsepower, you're going to see code written in C++ to native APIs. That's really more of a fault of Java than Swing however, and the benefits of a VM layer pay off for other kinds of apps.

  The real "pie" right now for Swing is in "thin-client" enterprise apps -- applications that need a more sophisiticated UI than HTML/JS/CSS can deliver comfortably. Swing is doing very well in that segment; the guarantees of the VM layer -- especially OS independence, are "killer".

  Where Swing is at right now isn't where it could be, in a perfect world, but it is certainly winning popularity contests in the segments its design choices were appropriate for.
  

  Posted by: cpu_fusion on November 17, 2003 at 08:04 PM

• Re: Blogging = hyperbole
  I think you're missing the big picture -- Swing wasn't intended to be native like, say, SWT. If you're disappointed that AWT didn't evolve into SWT, I agree.

  "Of course, it doesn't work with JFileChooser and never will."

  A cross-platform UI has to draw a line somewhere between consistency across platforms and native L&F. The file chooser in Swing has evolved from Java 1.2 to 1.4. Given no technical reason why the feature you describe couldn't be abstracted across operating systems and integrated into JFileChooser, saying "never will" seems to be just a guess.

  "... JEditorPane. which cannot render anything correctly"

  Ah yes, I forgot that I.E. has perfect CSS support, and that Java gives people warts.

  " using Swing punishes the developer and user and gives nothing in return."

  Oh come now -- try cross-platform consistancy, for starters, and a great API IMHO.

  I agree SWT/JFace is great, and would like to see them both a part of the Java standard ... but get out of your narrow viewpoint as to what Swing has to be to be "successful". Not everyone's projects have your same requirements which *have* to be satisfied with native widgets.
  

  Posted by: cpu_fusion on November 17, 2003 at 08:27 PM

• partly true
  Hi !
  Just wanted to post a few comments here :
  1) an example of a graphical swing app I downloaded recently :
  http://www.objectclub.jp/Jude/
  An UML graphics editor that is very quick and has slow footprint
  2) About your comments :
  We need *layers*
  The bottom layer is what upper layers use. I think AWT was really wonderfully extended to provide everything I need
  The next layer goes around building GUIs programatically, this is what Swing does, and I think it's nice, but as you explained, it needs lots of programming skills
  The layer that's missing in my opinion is a declarative layer, something that would borrow from XForms, XUL, windows/mac resource editors, to effectively separate predefined widget configuration information from the code that uses it. However, this is not an easy thing to do, but as Swing has reached its limits here I think it would be the time to implement such concepts.

  HK
  

  Posted by: hkara1 on November 19, 2003 at 02:36 AM

• Re: Blogging = hyperbole
  I think this is an excellent point. Now don't get me wrong, I am not anti-Java. I like the language, it makes me much more productive than C++.
  But I think what we often miss as Java developers is that Java is good for us -- not necessarily for our customers. That is a crucial difference, that IMHO is why we see internal and consultant projects being done in Java, but not COTS applications.
  Why should the user care if the app is cross platform? The vast majority use only one platform. Even if they use more than one, why should they care? It is an implementation detail.
  Don't ask them to go through extra downloads, more memory consumption, outrageous load times, and a sluggish ui just because we only want to write it -- 'er compile it -- once.
  I hope SWT/JFace does succeed, I would really like to see Java become a more viable choice for COTS development.

  Posted by: mschmeets on November 29, 2003 at 05:49 PM

• Suming up hipano-discussion of "Swing has failed"
  I’ve been asked (http://weblogs.java.net/pub/wlg/808) by a java.net editor, Daniel, to sum up the discussion about Joshua’s “Swing has failed. What we can do” that we had in a Spanish Java community (http://javahispano.org). The original discussion is here: http://www.javahispano.org/news.item.action?id=1059050878, but is in Spanish, so probably most of you won’t understand it.

  First I must recognize I haven’t read all the 59 replies to the post, so probably the ideas I’m summing up here about the hispano-disccussion of Joshua’s post probably have already appeared in other posts.

  While some of ours users though similar to Joshua than another abstraction layer is needed over Swing, some of them stated that no; all Swing should be redesigned, as the way of dealing with problems in Swing is more oriented to the academic world than to the real one. One of our users said that Swing was a “clear case of abuse of OOP”, and that it should be deprecated, as AWT was, coming up with a fully new API. He mentioned a real case of unexpected complexity in Swing: the first time you ant to write two words in different colours in a JTextPane you need to employ several hours, which is a huge amount of time for such a simple problem.

  Some of ours users think that Swing situation is not so bad, but it just has a bad history, but Sun already has addressed plenty of problems, and actually the API is quite good, and probably continue improving in jdk 1.5.

  About the look and feel subject, while some users also complain and want a better one, some of them stated that Windows and Gtk are enough. Other user said that he was disappointed by jdk looks and feel, but “kunststoff” (http://www.incors.org) was enough for his espectatives. Other users preferred jgoodies: http://jgoodies.com.

  There also was a user who believes that IDE’s have a lot of to do with Swing bad reputations, not only because Graphic interface designers are not as powerful as they should be, but also because the code they generate is quite inefficient and difficult to maintain
  .
  Other ideas that came up is that SWT is “the path” to solve Swing problems, and that one of Swing problems, it’s fat and slow, would be solved if we compiled the bytecode to native. This opinion was rebated by other user, who said that some of the Hot Spot optimizations can make Java’s bytecode go faster than it would go the same bytecode compiled to native.

  I hope that our little community (at least compared to the java.net community) has contributed something to this debate with our ideas.

  Abraham Otero.
  

  Posted by: abraham1905 on December 15, 2003 at 04:42 AM

• VB for Swing: Buoy
  Does anybody have any experience with Buoy?

  From the Buoy site:

  A Better User Interface Toolkit
  What Is Buoy?
  Buoy is a library for creating user interfaces in Java programs. It is built on top of Swing, but provides a completely new set of classes to represent graphical components. It offers many advantages over using Swing directly, including:

  * A much simpler, cleaner, and more consistent API
  * A better mechanism for laying out interface components
  * A far more powerful event handling mechanism, which is based on dynamic binding of arbitrary methods as event listeners
  * Built in support for serializing user interfaces as XML, then reconstructing them again

  Other important features of Buoy include:

  * It forms a "transparent wrapper" around Swing. It hides the complexity of Swing when you don't want to deal with it, but doesn't get in your way when you actually need that complexity.
  * It is very small and efficient. The entire compiled library is only 188 K.
  * It is written entirely in Java, and works on any JVM that is compatible with J2SE 1.4 or later.
  * All source code is in the public domain.

  http://buoy.sourceforge.net/

  Posted by: coxcu on January 08, 2004 at 07:31 AM

• I totally agree with you about the lack of good information on designing complex applications with Swing. I am teaching myself how to program in Java, and I am very happy with the progress I have made. It is very hard to find good example code. I use netbeans and am comfortable with it, but when I do find example code, I have to translate it to what I'm used to seeing in netbeans. I have a good understanding of the basic components. But I have no idea how you could integrate them into even a simple text editor without having a huge mess. What can you recomend?

  Posted by: yorkpaddy on December 01, 2004 at 11:42 AM

• wow power leveling
  wow powerleveling
  wow power leveling
  wow gold
  wow items
  feelingame.com
  wow tips
  Most Valuable WOW Power Leveling Service
  wow power leveling faq
  cheap wow power leveling
  wow power leveling
  wow powerleveling
  wow power lvl

  Posted by: wowleveling3 on December 13, 2007 at 06:59 PM

This work is licensed under a Creative Commons License.