Sun Drops the Swing Application Framework from Java 7

Posted by Charles Humble on Sep 30, 2009

Sections

Architecture & Design,

Development,

Enterprise Architecture

Topics

Programming ,

Language ,

Platforms ,

Java

Tags

JVM ,

Java SE

Sun has dropped JSR 296: Swing Application Framework (SAF) from Java 7. Writing on his blog spec lead Alexander Potochkin said:

"After much discussion it's become clear that the Swing Application Framework API as it is today hasn't reached consensus and we feel still needs further design work done.

Since the SAF API was committed to milestone 5 of JDK7 and that time is already here, this date is now impossible, and we need to decommit SAF from any specific JDK 7 milestone."

Only two new features, Elliptic-Curve Cryptography and the Swing JXLayer component, made it into the original Milestone 5 schedule. In response Sun has merged Milestones 5 and 6, extending the period for Milestone 5 to 29^th October. Milestone 5 will now be the feature complete build and will include the new features from Project Coin, the JXDatePicker for Swing, and updates to the JAXP, JAXB, and JAX-WS APIs that make up Java's XML stack, bringing them up to the most recent stable versions. Following the feature complete build at the end of October Sun plans a further 14 builds (until February 2010) to prepare a release candidate. The complete list of Java 7 features can be found on the OpenJDK website here.

Since Potochkin made his announcement about SAF, at least two forks of the framework (BSAF, SAFF) have sprung up. Jonathan Giles expressed his frustration at this on his blog:

"We went from the original SAF project whose requests for help fell on deaf ears (although admittedly there was not much visibly happening on Sun's side either) to two actives forks. If we had offered our time back when it was still JSR-296 we could have had this integrated into JDK 7, but because we waited for it to effectively die, we now have to most probably wait until JDK 8, if ever, before an app framework for Swing can be integrated into a Java release."

On the SAF mailing list Giles further suggested ditching one of the two forks so all the efforts can coalesce around one fork

"Assuming the two fork owners agree, pick one of the forks that presently exist, and call that SAF.next. Immediately stop and preferably delete the other fork to save any confusion."

Potochkin has also confirmed to InfoQ that another much requested feature, Cascading Style Sheet (CSS) based styling for Swing components, which was a possible part of the Milestone 5 Swing Updates package, won't be in Java 7 either. JavaFX has this capability, and Ethan Nicholas created a fairly comprehensive prototype for Swing, blogging about this project in summer 2008. Nicholas has also provided a tutorial with downloadable code at the project's website.

1. Back to top

   Sun Drops the Swing Application Framework from Java 7

   by totoro totoro

   they should release few releases outside the jdk (like jsf did) before bundling it with jdk. I understand the need for Swing app framework, but don't see a reason to why it needs to be bundled with jdk.

   Reply

2. Back to top

   Another alternative to SAF

   by Alex Ruiz

   Jean-Francois Poilpret has been working on a Swing application framework called Guts-GUI. Originally based on Sun's SAF, it shares similar goals and by now I think it is a clean implementation with no dependencies on SAF. It uses Guice under the covers (no more singleton ApplicationContext.) More details at kenai.com/projects/guts/pages/Guts-gui

   Reply

3. Back to top

   Stop calling it "Java 7"

   by Neil Bartlett

   There's no such thing as Java 7, the JSR for it has not even been started yet (and may never be). What you're talking about is JDK7, an open source project controlled by Sun.
   
   Think I'm being pedantic? Then try to find a single instance from the last 2 years of a Sun employee referring to "Java 7". Schwartz made a slip-up in his JavaOne keynote, but aside from that it's like trying to get a stage actor to say "MacBeth".

   Reply

4. Back to top

   Big news: Sun removes something?

   by Vic _

   So far java has been getting fatter and fatter. Why can't "Swing 2" be a separate jar?
   Why can't swing 1 be a separate jar?
   Etc.
   
   .V

   Reply

5. Back to top

   Re: Big news: Sun removes something?

   by Esko Luontola

   Let's hope that Project Jigsaw and similar efforts will make the standard library smaller.
   
   An ideal situation would be where Java runtime would have only the java.lang package integrated, and everything else would be distributed as external libraries in OSGi bundles. The Java runtime would download missing dependencies automatically from a web server, similar to how Maven works. The most common dependencies could be bundled with the JRE installer, to make the first startup faster, but the JRE would work even without those things bundled.
   
   That would solve many problems related to version conflicts, backwards compatibility and such.

   Reply

6. Back to top

   Re: Big news: Sun removes something?

   by jamie swain

   Let's hope that Project Jigsaw and similar efforts will make the standard library smaller.
   
   An ideal situation would be where Java runtime would have only the java.lang package integrated, and everything else would be distributed as external libraries in OSGi bundles. The Java runtime would download missing dependencies automatically from a web server, similar to how Maven works. The most common dependencies could be bundled with the JRE installer, to make the first startup faster, but the JRE would work even without those things bundled.
   
   That would solve many problems related to version conflicts, backwards compatibility and such.

   
   
   That is the WORST FXXXING IDEA EVER. I would leave it to a Maven person to figure out a way to make something as simple as using Java with its standard libraries as complicated as dependency management with Maven. I seriously don't see what kind of "version conflicts" or "backwards compatibility" problems you might be having that this would fix. If anything that seems like a recipe for version conflict disaster.
   
   Maybe I just like things to be easy.

   Reply

7. Back to top

   Re: Big news: Sun removes something?

   by Esko Luontola

   "I seriously don't see what kind of "version conflicts" or "backwards compatibility" problems you might be having that this would fix."
   
   It would allow making compatibility breaking changes to libraries, without breaking the users of the old library versions. Right now the Java standard library has lots of deprecated and badly designed APIs which would be best removed. With a modular standard library, users of the old APIs could just label "Java SE 6" as their dependency, and they could still use all those APIs, even though newer Java versions would have much better but slightly incompatible APIs.

   Reply

8. Back to top

   Re: Big news: Sun removes something?

   by Peter Firmstone

   Yes I agree, the complexities surrounding backward compatibility have been abstracted from view for Jamie, who like most java developers can remain ignorant due Sun's efforts maintain platform compatibility by relying on the flexibility of Bytecode backward compatibility, allowing older bytecode to run on later JVM's.
   
   But for people like Jamie, these dependencies and module / package download upgrades would need to be abstracted too, otherwise the Java platform would loose favour.

   Reply

9. Back to top

   Re: Big news: Sun removes something?

   by Chu Kit

   I am going to learn a OS-independent GUI tech. In such case, should I pick SWING? or SWT or RCP? or other choice like Guts-GUI mentioned in this thread? thanks for any advice.

   Reply

• Older >