Beauty Is in the Eye of the Beholder
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Sun’s Withdrawal of SwingX Funding Angers Community
Posted by Charles Humble on Dec 02, 2008
Announced at JavaOne 2004, the SwingLabs project has been an important breeding ground for new Swing-based UI technologies that can feed into the core JDK. The project initially attracted a number of developers outside of Sun but has faltered a little in the last year. Sun has now decided to cease funding for the SwingX project altogether, as announced via a post to SwingLabs' forum by Jeanette Winzenburg . This has angered many in the Swing development community where there is a growing view that the core Swing APIs are being relegated to a supporting GUI library for the newer JavaFX technology. Kirill Grouchnikov puts this succinctly in his blog post on the topic:
"core Swing is in the process of being retired as a legacy UI technology inside Sun, and last week has marked another sad (yet expected) milestone - stopping the funding of SwingX project."
In his analysis on the history of SwingLabs, Kirill cites Sun's January 2007 decision to drop the SwingX Painter layers and the JXComponent interfaces as the trigger point for the decline in community involvement arguing that:
"this has effectively destroyed the trust of external contributors, who never came back, even after Sun developers have retired themselves from being involved in the project."
Krill is also deeply skeptical about JavaFX:
“I don't know what the future holds for JavaFX. Sun is heavily betting on it, and nobody wants to have their Nomad moment forever archived on the Internet. All I know is that JavaFX has effectively halted all core Swing development. Over the last 18 months, we have seen significant architectural initiatives (JSR 295 and JSR 296) changing leads and frozen. All client-facing improvements in Java2D, AWT and Swing in Java 6 Update 10 are completely driven by the requirements of JavaFX.”
Sun staff engineer Josh Marinacci, who is closely associated with Sun’s JavaFX project, states in a follow-up post that such concern is premature, arguing that SwingX and SwingLabs continue on, and that Swing developers will benefit from recent changes in Java SE 6 Update 10 and ahead in Java 7:
“As a life long client Java developer I have never been happier with the current state of the Java stack. Client Java applications are becoming faster, more reliable, and easier to develop. And this is true for both Swing and JavaFX applications. Stay tuned for the 1.0 release of JavaFX. I think you will be happy when you see what we've been working on. It's an exciting time to be a GUI app developer on the Java platform. “
It is certainly the case that Sun remains publicly committed to JavaFX. At Adobe's MAX conference Sun re-iterated that Java FX Desktop 1.0 would ship in early December (the date has now been set as December 4th), with JavaFX Mobile and TV delivered during the first calendar quarter of 2009. Moreover Sun has been actively hiring engineers to work on JavaFX in the last year, recruiting staff from Apple and Adobe amongst others. The fact remains however that software contributes relatively little to Sun’s bottom line. Sun’s total software revenues for the first quarter of fiscal 2009 was $124m, compared with $507m for storage and $1,246m for servers and other systems. Having announced lay-offs of around 6,000 employees without giving notice to any individuals, a certain amount of concern in the wider Java community, as well as within Sun, is understandable. For developers who have committed to Java and Swing the lack of transparency on Sun's plans for Swing in Java 7 is becoming a real concern.
RelatedVendorContent
18 agile and lean practices for effective software development governance
NOSQL, The Web And The Enterprise
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
Improve Java Garbage Collection, Runtime Execution, and JVM visibility with Zing
Neglecting Swing/X Harms Custom Enterprise Software Development
by
Norbert Ehreke
Posted
Re: Neglecting Swing/X Harms Custom Enterprise Software Development
by
Hanno P
Posted
Re: Neglecting Swing/X Harms Custom Enterprise Software Development
by
Richard Osbaldeston
Posted
Re: Neglecting Swing/X Harms Custom Enterprise Software Development
by
andrew mcveigh
Posted
Re: Neglecting Swing/X Harms Custom Enterprise Software Development
by
Richard Osbaldeston
Posted
What is an API
by
James Richardson
Posted
Re: What is an API
by
Norbert Ehreke
Posted
swing isn't dead, it's just living underneath JavaFX
by
andrew mcveigh
Posted
Google Web Toolkit or OpenLaszlo
by
Richard Nare
Posted
Re: Google Web Toolkit or OpenLaszlo
by
William H
Posted
Re: Google Web Toolkit or OpenLaszlo
by
jeff ji
Posted
-
I have been coding Swing for the last 10 years. (Yes, the road was bumpy.) I am a developer working for a consultancy that creates custom applications for larger companies. Our Swing applications are always sitting on top of a database, mostly SQL Server but sometimes Oracle.
What our customers want is this: Fast development, stable and attractive UIs, possibly adapted slightly to their corporate identity. Swing provides an excellent platform, but we had to weather some hardships in terms of learning Swing's pitfalls (AWT Event Dispatch Thread, anyone?). For newbies Swing is tough. JDBC support is good, but can be improved. Application infrastructure is non-existent. Beansbinding: nada. By now, we do have a framework that provides us with a solid foundation, but we'd love to have more easy to use components (say TreeTable, a MappingChart, a PropertyGrid, simple(!) 2D graphics etc.)
Recently in a discussion with several professional developers and customers we all agreed that the single most important aspect of software to our enterprise customers is: (tadaaa) DATA. Plain and simple. (Well, that's not too surprising, since our customers have databases.) They simply want to search, filter, extract, edit and enter data. There are report request galore. (I am totally with Karsten Lentzsch: www.artima.com/weblogs/viewpost.jsp?thread=242077)
I know. This is soooo boring. But that's what they want. They do not care about transparency, animations or eye-candy in general. They want their data. Now. Of course, they'd love to be platform independent (hint, hint, hint!) using mobile phones, laptops, netbooks, etc. But essentially the looks are not important. The content is. And, they really do not care if we use Java or WinForms or any other software that'll provide them the functionality they require.
Therefore, if I could wish for something, here it is: make Swing so easy to use, that the term "Rich Client" gets a new meaning in the enterprise! Fuel Java WebStart! If HTTP can (again: easily!) be used as a deployment channel, make it even more readily available. (Our applications could easily live without security checks, because our applications run within an intranet and users are authenticated against the database.) To all JavaFX folks: It's not about eye candy, but stability, maintainability and ease of use, especially deployment. Provide a rich infrastructure, all the JSRs that have been shelved were exactly
right on target; SwingX was right on target with JXLayer and JXTreeTable. And even the simple JXBusyLabel was a wonderful addition.
If Sun effectively retires Swing (development) we'll eventually switch to another platform. And it's not going to be
JavaFX! (Neither Flex, since nobody I know is keen on "programming" XML or WebServices when JDBC/ODBC is available.)
Personally, I think that Sun has no interest in Swing because it does not create revenue from it, at least not directly.
It's precisely of the scenario that I described above. If Sun would somehow make some money off of the custom software that
is created with Swing, it might reconsider. But it does not, so Swing seems doomed. I am sorry about this, but
I am pretty sure, that's the road we're facing. -
I think that a couple of things need to be considered here:
1. SwingX was never that great.
They never really got to a great situation with releases and it took them way to long to even get to that state. The components had to be updated to work with 3rd party L&Fs. Many of the components were contributed from Fred's L2FProd custom components, anyway. I just use the directory chooser in that -- it's not going anywhere.
2. JavaFX is built on top of Swing and Java2D
Swing development and bug fixing is not stopping and it's not going anywhere because all their JavaFX GUI stuff depends on it -- it's just that development is oriented at the moment around supporting JavaFX. Apparently we now get a fast scene graph and probably some other things such as codecs and video support. We'll possibly get a timing framework too. I guess they just aren't pushing the platform fwd in the way that hits the sweet spot for direct Swing developers. Suffice to say, though, most of the library stuff existed in external form before...
Andrew -
I don't understand why there is a discussion here about Swing against JavaFX.
JavaFX IS Swing! It sits on top of it. JavaFX cannot do anything without Swing, so I think Sun will never ever have the idea to doom Swing.
Maybe the SwingX project was not heading the direction they want it to go and they have something else in mind, I don't know.
JavaFX just delivers what you wish: an easier way to develop Swing applications. It's not necessary to use transparency and animation, it's an additional feature that maybe other people need.
I think it is natural that Sun is now focusing on JavaFX, because it will be now released and it is the recent strategy of client side Java for Sun. -
> JavaFX cannot do anything without Swing, so I think
> Sun will never ever have the idea to doom Swing.
Because AWT really blossomed after they built Swing ontop of it.
The issue is more whether Sun still has the same desire to keep extending and developing Swing alongside it's newer UI framework. They clearly don't have the resources to give both equal support and the plans for Swings JDK7 JSRs have suffered major setbacks in the meantime. It not going anywhere, but is it deprecated in all but name?
As I understand it JavaFX isn't really built on Swing more Java2D. JavaFX comes in different profiles for different types of devices. The desktop profile can have Swing components embedded in it, but embedding JavaFX in Swing may be a different story.. one they're unwilling to share with us yet.. groups.google.com/group/javaposse/browse_thread... -
Norbert - having a bit of trouble understanding you there. JDBC support is lacking in Swing? Well, they are two different APIs... so no surprises there.
Application infrastructure is non-existent? OK! (what on earth do you mean?)
Your customers want to do stuff with data? OK, good. I'm happy for you. How is this relevant? There is more than one GUI application in the world, thank goodness.
Java Web Start works pretty well for launching swing apps... what more do you want from it?
As for no security checks etc... did you write maven? A major design point of java is authenticating downloaded code. Just because you write enterprise quality software, doesn't mean that others don't write decent quality software....
If you're a decent swing developer, and you find a component missing, write your own component- pop it on google code. Pretty much all you need of the basic stuff is there. Some of the APIs are not super... but there is a lot you can do.
Good luck! -
Because AWT really blossomed after they built Swing ontop of it.
Swing is sort of based on AWT -- it's more of a completely different direction. Where AWT had native peers for everything, Swing took the different tack. A similar division existing in the smalltalk world (VisualWorks=emulated widgets versus Envy/Developer=native peers). Java has both in one library :-(
As I understand it JavaFX isn't really built on Swing more Java2D.
Admittedly it may be out of date, but the scenegraph for JavaFX was very much based on Swing and Graphics2D. See: scenegraph.dev.java.net/
Embedding swing widgets into javaFX panels is pretty much fundamental here, and all the transforms rely on the G2D magic.
Do you have knowledge that this has changed?
Andrew -
>Swing is sort of based on AWT -- it's more of a
>completely different direction. Where AWT had native
>peers for everything, Swing took the different tack
Isn't there a similar change implied in JavaFX where components exist as nodes in a scenegraph 'canvas' and JavaFx components are more visually rich and vector/bitmap/alpha based - less focused on providing a framework capable of all things to enable the emulation of OS specific widgets.
>Embedding swing widgets into javaFX panels is pretty
>much fundamental here, and all the transforms rely on
>the G2D magic.
I'm not sure I'd call that fundamental - more a stop gap. While you can bring Swing components into the desktop profile JavaFX node space I'm not sure you gain that much (shearing & rotating tables?). JTables & JTrees won't provide practical components on a mobile or 10" TV/DVD interface. I think JavaFX components are meant for more Google Gadgets, Glossitrope/AB5k territory thats if you really intend to show the same interface to all devices - lowest common denominator rules the day.
As to their future plans who really knows? as a community we've been kept in-the-dark.. but you know how when you've a golden hammer in your hands pretty much everything starts looking like a nail. -
www.openlaszlo.org/
or
code.google.com/webtoolkit/
Either seems better for the web. -
Surely it depends what you are building? I agree that GWT has the advantage of being based on open standards and for some things that is fine but there are problems I need to solve in the enterprise apps I build where neither GWT or Flash can really do the job and Java is a great alternative to have in the toolbox. I’m really pleased to see client side Java getting some attention and buzz again – JavaFX is pretty impressive in my opinion for a version 1 product.
-
gwt is a good tookit, but it is hard used in my project
-
James - let me elaborate a bit... I am indeed concerned with Sun's priorities. To me, JavaFX focusses on designers and their problem domain. It's about eye candy. That does not mean that I do not respect the people doing this stuff. On the contrary. Yet, I do believe that in the enterprise this is not that important. Now, if Swing were more easily approachable, if Swing had more components, if developers could whip out entire applications in a best-practise-fashion that is provided and supported by Sun, wouldn't that be great? (That's what I meant be application infrastructure.) And wouldn't it be great if Java WebStart could be more customized in ways that make it easier to deploy applications without the assumption that the user is standalone in the internet (instead of a user in a company, behind a secure firewall)?
You are proabably right that I could develop a tree table component myself. Yet, that argument is bit lame to me, since Josh, Jeanette, et. al. could do a job much, much better than I could ever do. In the projects that I am involved with, time is always so scarce that my customers would never allow me to do this. In fact, you could also probably customize the Linux kernel, but in most cases (even though Linux is open source) you'd probably use it as an operating system, right?
Yet, as I said, if Sun does not make money with Swing and if they are right in thinking, that their base of Swing developers plus all those web designers out there will flock to JavaFX, hey, who am I to doubt that? I just think that Sun is making a big mistake here and I am sad about it, because Swing is a great platform and IMHO it deserves more than becoming the next legacy API.
Cheers, Norbert
11 comments
Watch Thread Reply