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 29th 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.
Community comments
Another alternative to SAF
by Alex Ruiz,
Stop calling it "Java 7"
by Neil Bartlett,
Big news: Sun removes something?
by Vic _,
Re: Big news: Sun removes something?
by Esko Luontola,
Re: Big news: Sun removes something?
by jamie swain,
Re: Big news: Sun removes something?
by Esko Luontola,
Re: Big news: Sun removes something?
by Peter Firmstone,
Re: Big news: Sun removes something?
by Chu Kit,
Another alternative to SAF
by Alex Ruiz,
Your message is awaiting moderation. Thank you for participating in the discussion.
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
Stop calling it "Java 7"
by Neil Bartlett,
Your message is awaiting moderation. Thank you for participating in the discussion.
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".
Big news: Sun removes something?
by Vic _,
Your message is awaiting moderation. Thank you for participating in the discussion.
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
Re: Big news: Sun removes something?
by Esko Luontola,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Re: Big news: Sun removes something?
by jamie swain,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Re: Big news: Sun removes something?
by Esko Luontola,
Your message is awaiting moderation. Thank you for participating in the discussion.
"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.
Re: Big news: Sun removes something?
by Peter Firmstone,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Re: Big news: Sun removes something?
by Chu Kit,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.