Joshua Marinacci's Blog

"Why don't you ship Swing Apps", two years later.

As I write this I am speeding over the Atlantic at around 500 miles per hour towards a two week business trip. The goal is to work out further details of the JavaFX tools and plan our schedule for next year. (And no I'm not going to give you any details. That's not what this post is about :). As I'm finishing up emails and pondering my two weeks of meetings I'm struck by a question: How did we get here?

Okay, I don't mean the existential question of existence. Instead, how did Java, more specifically client Java, get here? How did we end up with the new version of the JRE, and JavaFX, and great new stuff in NetBeans 6? I'm feeling a renaissance of client Java welling up, but there were some dark days in the past. In fact, I wrote about them prodigiously.

I started my Java.net blog almost two years before I came to work for Sun and I've often be critical of client-side Java; but only because I love it and want to see improvements. Two of my blog entries come to mind, in particular. The first, Swing has failed. What can we do?, was written in late 2003 and a second, The Reponse to Why Don't you Ship Swing Apps, in mid 2005.

Looking at the stats these two blog posts are among my most heavily read blog entries with about 10 times the average for most of my posts. (The number one spot, oddly enough, goes to Swing Hack 4: The universal right click, which I suspect is boosted by the long tail of Google).

It has been over two years since I wrote that second post (and will hit 3 by the time of JavaOne), so I thought I'd take a moment to reflect on what were the problems I documented back then and what we've done to fix them. It's really quite extraordinary. Everything on my list has been addressed! Now, I'm not saying that I'm the reason they are all fixed, but it is nice to see that we were all thinking about the same things. Let's take a look at what we've done. (the following list is condensed from both blog entries).

Why Swing apps suck

Swing apps are slow to build and Swing layout managers suck. Well, these complaints basically boil down to the lack of good visual tools, now addressed by the NetBeans form builder and greatly improved in version 6 with binding and the app framework. Check.

Swing apps are hard to maintain. This complaint is really that we need some sort of a framework for Swing applications. We now have such a beast, creatively named the Swing Application Framework. Check.

Swing is too powerful. I was really complaining about not having higher level components. A lot of this is solved with the components from SwingLabs, though we still have some work to do. Half check.

No native features. The problems with JNI have a long and sordid history but JNA has made great strides here, as have new features in Java 6 (like the java.awt.Desktop API and SystemTray) as well as the many things the Apple Java team has done to improve native fidelity. You can even use JNA to create real shaped Windows. At least 3/4 of a Check.

Swing apps have a bad history Well, still working on this one. We've made headway with really cool JavaOne demos (Extreme GUI makeover, Aerith, Iris) but we've got more to do. We really need the community help, though. What do you need from us to make great looking apps? 1/2 check.

Make something better than Metal and Visual Appearance (ie, don't be ugly). I'd say that Nimbus really fixes this one. Oh, and of course the many fixes we did to the Windows Look and Feel. Check x 2!

Better Javadocs & Examples, the look of the JavaDocs haven't changed, though the content has. That's something I hope to address soon. I know we have some great new examples coming out both as part of NetBeans and in another form you'll hear about later. 1/2 check.

Deployment: Java Web Start, Java Auto-Install Toolkit, Smaller JRE Download: Update N is designed to completely solve these problems. Check.

Performance and Memory Usage. Tons of work went into Java 6 to improve performance and reduce memory usage. Update N will include more improvements specifically targeted at startup time. We've definitely got this one down. Super Check.

All the pieces

So here's my real point. When Java 6 update N ships (when the N has been replaced with an actual number), we will have completed a series of changes designed to revolutionize desktop Java programming. While it may appear that all of this has happened in the last six months since the JavaFx announcements last May, that is not the case. This is really many different pieces in development for quite a while, some of them for years. (we've wanted to do the Java Kernel idea for a *long* time).

So the pieces are coming together. Better runtime. Better tools. Better deployment. (and I even hear better jobs). It's a great time to be a client Java developer. So what are you going to build?

Comments

• Seems almost silly really...but I'm going to build a blogging tool. I really liked MarsEdit on the Mac, but I had nothing similar on my Windows system. So, I'm going to create it myself -- using all these nice desktop features of the Java platform of course.

  Posted by: joconner on November 11, 2007 at 11:20 AM

• Good to hear it. Let me know what you build. I could use a good one too.

  Posted by: joshy on November 11, 2007 at 11:29 AM

• I am very pleased to see that many things have improved, but …
  The Java update N will only be available for Windows. I choose java (for my XML editor) to be multi-platform, but the functionality and desktop integration differs so much on each platform. On a Mac I can easily integrate my application using a .plist file and the OSXAdapter (the extended mac ApplicationAdapter). This will allow me to build a application that reacts to System events like handleOpenFile and handleQuit. On Windows I am not able to do that. I am using Launch4j to deploy my application, but the integration is much less than I would like to see. I really think this should be improved to become successful on the desktop.

  Posted by: deneer on November 11, 2007 at 12:35 PM

• What you are talking about is wanting a different deployment method than webstart or applets. I agree that there should be better solutions for this. There are several commercial solutions and some open source ones, but none that I would call great. We did just start a new project to create installers that might address your problems.

  I'm curious, though. Are there things you want to do that aren't possible with Java Web Start?

  Posted by: joshy on November 11, 2007 at 12:41 PM

• Yeah you guys are to be commended for all the work you have done. Including open sourcing java! That's a big one, too, because java 6 can be bundled with many linux distros now, and perhaps be better integrated into other open source apps and projects (like the OLPC laptop).

  I would say though that I hope update N and future versions of javafx work in the browser well, too, with applets not just webstart apps, so that javafx is a real alternative to flash. I saw the recent threads on the javafx list about applets (which don't really work at the moment).

  Applets have such a bad rep, but then again so did flash a few years ago.

  Posted by: dug on November 11, 2007 at 01:20 PM

• > Swing layout managers suck
  Nope, that one is still not solved. Sure, you did add a LM that is good for tools. A great one even. The problem is that not many is using IDE all through the creative process since beans that are fully IDE compliand is hard to come by. So, the creative layout process is quite usually started in the IDE, using the RAD tool but then tweaked in code. This is where it fails. GroupLayout can not be edited by hand... At least not by normal people. :)

  There is a layout manager that now is almost in the TOP 25 RFEs. MiG Layout will solve the layout issue. It does so much more than the other layout managers. It is like CSS for Swing layouts.. Go and read some of the comments to the RFE, they are quite flattering at times. :)

  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6530906

  Cheers,
  Mikael

  Posted by: mikaelgrev on November 11, 2007 at 01:23 PM

• I think Java webstart is great for deploying the application within your company and I do use it there. This way you are sure everyone has the same and latest version. But home users want the application on their disk. It may be just a feeling or emotion, but that is the way it works Technically I had big problems to use the endorsed mechanism in Java Webstart and in the end I had to work with a small loader jar that does the actual class loading. What I can not do with java webstart and what I can do with a .plist file is associating extensions, defining document icons for different extensions, hiding my application in the dock, etc. What I can not do is telling to Windows to open a double-clicked document in my already running application.
  By the way talking about some still missing features in java. I really would like to see the flying saucer “merged” in the HtmlEditorKit. I mean, we need a java component that is capable of properly displaying webpages, a pure java webbrowser component.

  Posted by: deneer on November 11, 2007 at 01:30 PM

• Josh,

  I agree with pretty much everything you said here. One area I haven't seen included in all these client improvements is USB. I have had several interesting ideas for client applications that needed some sort of USB support. It is such a shame that we have had the API defined for so long, and yet still only a Linux implementation exists. I have considered trying to implement this before, but the learning curve is so high since you have to understand the huge USB spec and understand a lot of native drivers/APIs. I was wondering if you have heard of any plans to change this?

  Thanks,
  Chris

  Posted by: chrisw1229 on November 11, 2007 at 02:51 PM

• And where is my good lightweight HTML renderer/browser component? Oh yeah, I still have to pay for it.

  Posted by: kebernet on November 11, 2007 at 03:09 PM

• Well , since someone above has bragged about an alternative layout manager, let me plug the most popular layout manger on Sourceforge: Pagelayout at pagelayout.sourceforge.net. It even comes with a GUI builder at Gola at gola.mathnium.com that generates Java code which eminently readable by mere mortals

  Posted by: varan on November 11, 2007 at 03:10 PM

• Josh, you gave me a good hint for the final title of my speech at JavaPolis - I was searching one for weeks but didn't like what I found so far. Thanks! :-)

  Posted by: fabriziogiudici on November 11, 2007 at 04:54 PM

• Something that´s perceived as a general issue (difficult layout managers) cannot be solved with an "IDE feature" (Netbeans).

  Perhaps a way to improve the GUI building situation is not to tie it to Netbeans. Instead, create a "standalone" GroupLayout editor that would settle this issue even for the people using Emacs/Vi....!
  

  Posted by: niqueco on November 11, 2007 at 05:37 PM

• I was going to build a screen cast recorder plugin for NetBeans but has run into a wall, need JNI for getting the mouse pointer states and bitmaps which is not encapulated in either Robot nor MouseInfo. So I guess I think it would be swell if we could lower the common-denominator of platform-specificness a bit to allow for more than just boring business applications to be made in Java.

  Posted by: mrmorris on November 11, 2007 at 06:02 PM

• I don't really see desktop Java taking off before lightweight/heavyweight mixing is in the baseline. I know it went into JDK7 with build 19, but hopefully Java 6 update N will address this. It would solve all sorts of issues with web browser support, multimedia, and even ActiveX/COM embedding (on Windows). Which, to be honest, are all more important for desktop Java to me than better layout tools.

  Posted by: samkass on November 11, 2007 at 08:33 PM

• WinForms layout sucks even more on .NET, anchoring and TableLayoutPanel have their limits. Doing my first C# WinForms layout was a real pain compared to the choice (formlayout and others) that exists on Java. Layout managers work well for localized UIs and dynamic layouts. Coordinate-based visual layout managers struggle, even if you can outwit them in the end. Try switching technologies before complaining too hard about Swing :-)
  - Chris

  Posted by: chris_e_brown on November 12, 2007 at 12:51 AM

• I'm not going to build anything since Swing GUIs are completely broken with Compiz-Fusion. The bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6429775 has been closed despite it not being fixed at all, which is really making me hate sun. How is Java going to have a revival on the desktop when it is broken by default on the most popular desktop linux distro (Ubuntu 7.10)?

  Posted by: rhoomba on November 12, 2007 at 02:20 AM

• People know that the usual workaround of setting export AWT_TOOLKIT=MToolkit in the script that runs the applications fixes the problem on Linux (BTW, it's not always needed: I've put that in the launcher of my app and I discovered that it crashes on Ubuntu 7.10 64bits, where I've been reported that just removing the option is just fine). Since I see a lot of people working with NetBeans (Swing app) on Ubuntu 7.10 (including myself) I see it as an annoyance rather than a showstopper. Also, I think that Sun should be faster in closing some kinds of bugs, but the fact that in Linux each thing can be done in ten different ways for sure does not help.

  Posted by: fabriziogiudici on November 12, 2007 at 02:46 AM

• A functional testing tool for Swing - 2 years ago there was nothing to test multi-threaded Swing apps. Now we have Frankenstein http://www.openqa.org/frankenstein/

  Posted by: ckponnappa on November 12, 2007 at 04:12 AM

• The biggest thing affecting desktop Java for me is the horrible implementations of JFileChooser. On Windows it doesn't support the context menu properly which is REALLY noticed by users. It doesn't even display icons properly if you are using something that badges the icons like TortoiseSVN. It doesn't support a few of the "Views" like "Thumbnails" and "Tiles". On Mac I've heard a lot of complaints that it is unusable.

  JFileChooser is a fundamental interface on most Swing desktop apps, yet it is so neglected.

  Posted by: swpalmer on November 12, 2007 at 06:49 AM

• The JFileChooser problem is a a big problem. It's true that one can buy a component for that but it should be part of the JRE. I've asked about the status of JFileChooser in Java 7 but got no answer from Sun engineers. It should also be possible to add context menus to JTextComponents without any hacks, don't you think Josh?

  Carl

  Posted by: carcour on November 12, 2007 at 08:31 AM

• 
  Swing apps have a bad history Well, still working on this one. We've made headway with really cool JavaOne demos (Extreme GUI makeover, Aerith, Iris) but we've got more to do. We really need the community help, though. What do you need from us to make great looking apps? 1/2 check.

  That one is not even solved 1/100. And no, doing yet another elitist demo at JavaOne will do nothing. Stop doing these demos and start working on the real issues, like the JDK. Replace the brain dead example code that comes with it with code that really demonstrates features and best practice.

  Then get the Java tutorial authors to do the same.

  Manage to assemble and organize all Swing, Graphics 2D, JOGL, media framework (and related desktop technologies like sound) documentation in one single place. The available information is extremely fragmented, as if Sun employees and departments don't talk to each other. Some important information is well hidden in release notes (magic system properties), others in tutorials, articles (published in lots of different places by Sun), API docs, JDK docs, an unknown number of website, sblogs, etc. Man, get that stuff organized! Currently this is amateurish!

  Get the tenth of thousands (no joke) of bugs in Swing and related packages fixed. After roughly ten years it is high time that JTable (worst Swing component ever) and JFileChooser (second worst) get fixed. Fix the HTML renderer components, fix the handling of application supplied fonts, fix the API documentation, fix, fix, fix, fix, fix, fix ... And then fix some more. And stop adding vanity features to Java until things are fixed.

  Send the Swing team out on internships into companies who build real-world applications. So the Swing developers can at least once see beyond their own noses and learn what's really important for real-world Java desktop applications. Hint: It is usually not another piece of bling.

  But don't do waste your time with yet another demo.This demo business is very much like adolescent boys talking about sex. Lots of talk, but those who talk and show of the most never did "it".

  Posted by: ewin on November 12, 2007 at 10:25 AM

• I don't ship swing apps because there is no Java SE avalable on highend PocketPC :( and AFAIK, Swing is not running on CDC (over J9 or whatever) ! So, this means either beeing stuck to CDC (with a ugly HCI), or switch to alternative non-java solution ... doh !

  Nowadays Highend PocketPC are fast enough for hosting JavaSE stack, having it in the JavaSE camp would help us bring powerfull java enterprise mobile solution (lots of potential).

  Beeing stuck to CDC means, poor graphics, little toolkit libraries (such as GIS, graph ..) and tons of headaches.

  Joshua, I would be glad to run Swing on Java (non SE) ! What about bringing back a "100% Java" Swing ? Doing so, would help porting (say to CDC first) and would ease modularity of the JDK (see Java Module JSR).

  Swing on CDC ? OpenJDK on PocketPC ?
  Any plans in that direction ?

  Rgs,
  JB

  Posted by: bjb on November 12, 2007 at 10:37 AM

• +1 on an actual usable implementation of USB. The inability to easily use common peripherals, such as webcams, is pretty pathetic.

  Posted by: jeeky on November 12, 2007 at 11:02 AM

• You might have a swing competitor soon. Android was released, and its view and listener(notifications) based.

  Posted by: i30817 on November 12, 2007 at 11:16 AM

• One gets the sense from the Swing projects on this site that some of the engineers working on these projects have yet to graduate from the 'jee whiz, look what Swing can do?' stage.

  Posted by: varan on November 12, 2007 at 11:46 AM

• another +1 on USB / serial port support. I have 2 projects that have to go non-Java because of this. Trying to use existing solutions on Windows is too much effort to keep working reliably.

  Posted by: pcomp on November 12, 2007 at 02:07 PM

• I hope that Sun does not think that code like this will solve any problems of usability.

  "[fill]10[top,10:20]", "[fill]push[]", "[fill]10:10:100:push[top,10:20]".

  Posted by: varan on November 12, 2007 at 03:09 PM

• +1 for dropping all the elitest JavaOne Swing demos. Yes we KNOW you are all really good and can do amazing things, but fix the basics first and bring forth a bit more pragmatism.

  Posted by: mrmorris on November 12, 2007 at 04:59 PM

• @Varan. Why so hostile? Have I done something to offend you?

  Posted by: mikaelgrev on November 13, 2007 at 01:29 AM

• There are some great Swing applications: have you ever tried MagicDraw or VisualParadigm (both are UML Studios). I'm working every day with MagicDraw and I'm amazed about its responsiveness. I know that these are not "business" or "consumer" applications, but still are extremely complex and they do a wonderful job ...

  Posted by: linus on November 13, 2007 at 03:05 AM

• deneer You can do most of the things you want using JNLPs in Java 6. You can register file types, icons, and be called when your filetype is opened.

  chrisw1229 I haven't heard of anything new on USB. I'll look into it.

  
  kebernet There's Flying Saucer and JDIC, but I agree we need a better solution. Something like wrapped webkit.

  fabriziogiudici That's great. What's the title?

  niqueco The gui builder in NetBeans is open source so it could be made standalone or bundled in Eclipse. In fact, some people do use NetBeans just for the gui builder and do the rest of their coding in vi/Emacs very successfully.

  rhoomba What is still broken with Compviz? I thought that Dick Wall said it was working in a recent episode of the JavaPosse podcast.

  varan What sort of Swing related projects would you like to see on Java.net?

  Thank you all for your thoughtful responses.

  Posted by: joshy on November 13, 2007 at 06:32 AM

• Another +1 for USB. Access to all those digital cameras and scanners would be great... not to mention fancier things like Lego Mindstorms robots, game controllers (some support is already available there through the JInput project), direct control of mobile phones... e.g. BitPim in Java.

  I for one don't mind the fancy Swing demos. I think they are an important motivational tool to show that even with the thousands of Swing bugs (shall we count bugs in Microsoft APIs?) we really don't have it THAT bad. Some very compelling desktop apps are easily coded in Java.

  My companies application ships pretty much only on Windows. We use Java for the productivity gains and the access to tools and libraries that make development easier. And we keep the door open for an easier transition to other platforms.

  Posted by: swpalmer on November 13, 2007 at 06:59 AM

• Since you asked, here are my two cents,

  We need an API for developing at least simple GUI applications without having to dwell into abstract details. What I have in mind, for example, is something like a call of the type Form("text","login","choice","number",{"one","two","three"},"color",
  "userchoice", "matrix","myMatrix"...)

  to construct a form for me, show it, and when the user is done, to be able to use form.getLogin(), form.getNumber(), form.getChoice(), ...form.getMyMatrix(), to get the user response. No need for me to worry about layout, evenhandlers, or even components, etc. etc.

  It sounds to be at an impossibly high level, but it appears to be not undoable if you make some default choices for colors and layouts etc. I think that such an API will be useful for a very large number of GUI developers.

  Posted by: varan on November 13, 2007 at 11:11 AM

• What we really need are better language abstractions, the tooling is really going overboard because of it.

  Posted by: mrmorris on November 13, 2007 at 01:43 PM

• To those complaining about the lack of a Windows implementation of the javax.usb API, there's a good reason for that: the technical limitations of Windows. javax.usb is a good API but its a low level API to enumerate devices and transfer raw data through USB pipes. But unfortunately Windows provides NO user-mode API to do this. The API is for kernel mode drivers only. So the javax.usb implementation would have to install a custom kernel-mode driver. Its not like you could just bundle a native library with your app. It doesnt work that way. The windows way to work with custom USB devices is to create a kernel mode driver and expose a high level user-mode API around it. They dont want you to be able to able to r/w to any arbitrary device.

  Posted by: benloud on November 13, 2007 at 03:41 PM

• varan It sounds like you would enjoy using the open source JMatter framework http://jmatter.org/. It will create guis from datastructures automatically. The guy who works on it is pretty cool and has built a very interesting project.

  Posted by: joshy on November 14, 2007 at 01:22 AM

• Most of those "checks" that you list are really nowhere near done yet, let alone proven successful and adopted:

  - NetBeans 6 - beta
  - Swing Application Framework - alpha at best
  - Nimbus - beta at best
  - Update N - not yet ready
  - Binding - beta at best

  Since no one is going to adopt all those at once and some may prove to be unsuccessful, it seems there's still a long road ahead for destkop Java.

  Posted by: madmatt on November 14, 2007 at 06:22 AM

• I have to agree with madmatt. The mixing of NetBeans6, Beans Binding, Swing Framework is still quite a gamble... you spend a lot of time updating to the latest versions, fighting the balance between what each API can reason about and submitting bugs. I.e. try refactoring a JSR-296 @Action annotation and see your app menu/button/shortcuts stop working, without any warning or error.
  I've submitted a bug just now but its unclear whether this is really just a limitation/consequence of so much going string type-unsafe based these days in Java or whether it should indeed take part in the refactoring. For pragmatic reasons and since NetBeans insists on locking so much of your code, I think it should.

  Posted by: mrmorris on November 14, 2007 at 08:08 AM

• Swing is going to take over the universe...

  Posted by: ah_um on November 14, 2007 at 02:36 PM

• Swing layout managers still suck, and suggesting tools (eg, NetBeans) that might be helpful is NOT much of an improvement. Sun hasn't heard their Java users begging for better layout managers, file choosers, table components, etc for years, and apparently little more is heard now.

  I'm very happy for the brilliant programmers who create the flashy demos -- it's surely a lot of fun. But this emphasizes the gap between the real and some fantasy world, breeding as can be seen from the comments, increasing resentment that Sun isn't connected to the real needs of Swing programmers.

  It's good to see real progress on Swing and hear encouraging alpha and beta hype, but the glass is still surprisingly empty.
  

  Posted by: fredswartz on November 18, 2007 at 02:35 AM

• Okay, here is something I still don't understand. Many people complain that the standard layout managers that come with Swing are primitive, and I certainly agree with that. The answer, I am always told, is that Sun should build new layout managers. Why? There are a bunch of really great 3rd party layout managers already that you can very easily include in your application at the cost of an extra jar. Why do you want Sun to include it? You can use a great cool layout manager *today* without waiting for the next release of the JDK. Why isn't that good enough? What's preventing you from using these layout managers. And the same goes for table components and many other Swing additions. (File choosers are a different matter and should be dealt with in Java 7).
  

  Posted by: joshy on November 18, 2007 at 09:42 AM

• Posted by: ewin on November 12, 2007 at 10:25 AM

  - YES!!!

  Posted by: surikov on November 19, 2007 at 02:14 AM

• Josh, the reason is twofold.

  1. These third party LMs will only get sporadic supports in tools.
  2. A new Java developer expects the build in LMs to be sufficient and expect only to need to get new ones for exotic needs. One would not expect to need to go and search for one to start with. Basically this is a projection problem. You are trying to see through their eyes but you see what you see. You know how to go and get new layout managers. A beginner do not see the options. It seems to be very hard to actually see what a beginner sees. Also, corporate developers need approval to use third party LMs since all in the project needs to learn them.

  If developers complain about the layout managers being crap, it is probably so. You can not say that people should get their act together and not be what they are.

  Cheers,
  Mikael Grev

  Posted by: mikaelgrev on November 19, 2007 at 05:24 AM

• Yeah we can add the jars, but I don't understand why the JDK shouldn't include the best possible layout managers?
  All desktop application developers have to build/layout GUI Components, and here is a need for simpler standardized layout managers that are intuitive to read / modify / understand.

  It would be great if someone looked into what layout managers / form builders could be eligible to either include in the JDK or take ideas from to create a great intuitive layout manager and/or form builder.
  

  Posted by: jorgenrapp on November 21, 2007 at 11:42 AM

• Josh,
  Use better alternatives to Swing components? You're right that Swing doesn't have to be good because there are good alternatives available from others. I use other GUI packages and have written layout managers, so other than the time or licensing annoyance of using better solutions, I suppose there's little reason to fix a number of Swing problems. Perhaps Sun would be so kind as to deprecate those components for which there are better (non-Swing) alternatives :-)

  Out of touch? The motivation for the earlier post was shock that a prominent Sun person would seem so out of touch with Swing reality. Perhaps I should just accept it as normal advertising hype where something is promoted as good (Matisse), neglecting to tell the customer that the reason they need it is that the basic product is flawed!

  
  Beginners are out of luck. Mikael mentioned the problem of beginners not knowing which Java components they should avoid in preference to outside packages. Beginners?? -- I don't know either! OK, beyond BorderLayout my choices are either MigLayout or my own layout, but for JTable I'm unsure; and which improved int JTextField is best, etc?

  
  Textbooks are the losers. Where the damage is really done to beginners is in textbooks. Few textbook author want to base their books on non-standard packages. And students (correctly) demand standard Java. I really loved (NOT) that book I had to teach from that used the author's lame IO package for everything -- when the students finally figured that out ("You mean we'll never write a real, standard Java program in this class?!!!"), there was a rebellion. So most authors use standard Java layout managers. The result is that the examples look like crap, encourage setSize and absolute positioning, and the student's own GUI programs often look bad. Generation after generation of students come away from the GUI programming experience with bad layout experiences. This demotivates them, gives Java a bad reputation, and doesn't create good GUI programmers for industry. I realize the goal of Java was to make difficult programs possible, but a few improvements could make simple programs easy too.

  Sorry for the long, negative rant, but Java is a language I really like, and needless flaws make me crazy when they never get fixed - or even acknowledged. And I really do appreciate the work that continues to imporve it. Thanks for all the good stuff!
  

  Posted by: fredswartz on November 24, 2007 at 10:07 AM

This work is licensed under a Creative Commons License.