Prompted by a
vigorous
discussion on Jonathan Giles blog about whether Sun is ready to do
a
'
Swing 2.0', its
time to lay out where we (at Sun) are with Swing. So here it is.
Swing and Sun
Swing is really important to Sun.
We have a large and
vibrant group of developers who are developing and maintaining Swing
GUI
applications. Its
APIs,
components and
underpinnings
are critical
to Java's future position in developing rich client applications of all
kinds.
In contrast to the early years of hectic
build
out
of Swing, we've slowed the growth of APIs over the last few
years. This is largely because, despite gaps in the API set for some
applications, compared with those early
days (or with
JavaFX today), the
Swing APIs are broad enough to build most enterprise desktop
applications. And that which is not there can most often be added with
a
third party library or
component.
Building with
Swing. Building on Swing
At the same time we've also seen a growing role for Swing, and its
underlying
graphics runtime, as a basis or inspiration for other RIA
technologies. Such as our own
JavaFX,
which uses both graphics stack and many of the
Swing components in its
desktop profile, or such as
Griffon,
Thinlet,
Pivot and
LWUIT to name but a few.
So our focus has been shifting (starting well before the
advent
of
JavaFX, even of
Java
SE 6) from filling out what were then major gaps in
Swing as a UI toolkit, to making it
easier
to develop with Swing, and to making the
runtime deploy and
perform better. Progress on both counts are a benefit to Swing
developers but also to other technologies that depend on Swing and its
foundation.
Sun's priorities
for Swing and JDK 7
To that end, the priorities for our
effort between
JDK
6 and
JDK 7 are:
first to make the runtime
lighterweight (
faster download,
faster
startup), better
integrated
into the browser, and with improved
runtime performance.
Some of this we have
already
delivered in Java SE 6u10, but there is
more to come. And
second to take a big swing (!) at
reducing the amount of boilerplate code and conceptual complexity in a
developing typical swing application with the
Swing Application Framework
in JDK 7.
We've also set things up in
OpenJDK
to make it easier for developers outside Sun to
contribute to Swing,
and we hope to help integrate some backwards compatible features
created
outside Sun into the JDK. We'll be working with the
XRender pipline
team to bring graphics acceleration to Java on Unix platforms. Also
in
JDK
7 we'd
like to include other components such as
JXLayer, the
DatePicker, and
CSS styling also. And
perhaps other components or features, as mentioned in
some of the
comments in
the thread, all such contributions depending on the usual
constraints
of quality of implementation, accompanying tests and of course, timing.
On a related note, some have mentioned a desire to use JavaFX features from Swing: we're interested in
hearing what
kind of Swing applications you are writing that might require JavaFX
components to be embedded as we figure out the next releases.
Not ready for an
incompatible revolution
Now, some of the discussion at
Jonathan's blog
reminded us of the many areas in the APIs that need
updating:
largely because of the advent of new
Java
language features and
SE
APIs that were added after the Swing APIs were created, that now
provide much more convenient and reliable ways to manipulate Swing than
were possible before. But we have a more conservative attitude towards
breaking backwards compatibility than some of the commenters on the
thread (
and
beyond): an attitude formed out of years of talking with
developers and customers who depend on Swing. (As an aside, you may be
curious as to the
inherent
design issues regarding the EDT). Now
JDK 7 modularity will
likely
provide
a neater way to move gracefully to some possible future
backwards-incompatible version of the Swing APIs. But in terms of where
we put our effort today, we don't think such an evolutionary cleanup,
albeit useful and desirable, its enough reason to disrupt
existing applications,
tools,
books,
tutorials,
courses and
frameworks that are
built with today's Swing.
Are you ?
But if what you want is revolution
not evolution, if you would like to see bigger, more radical changes
inside Swing, then please consider that you have all the
source
code for Swing
together with the supporting infrastructure to
create a project and
broadcast its existence at
OpenJDK.org.
It's why, in part, we set up
OpenJDK:
to make it easier for you to bring the next big RIA idea to life.
To a large degree JavaFX is designed with a new generation
of developers in mind, those with a little more art than science in
their backgrounds. More into shifting shapes on screen than polymorphism
in code. And they may well be wearing skinny
jeans for the first time,
unlike the Janitor who
was pioneering
them in the 1980s.
One cool thing about JavaFX 
Today, 
Small changes to the 
As you probably know, there's a 
Whether or not you are coming to
One of the most popular features of
the recent Java SE 6u10/11 releases was the 
Most of you thought the 
Today, news for devotees of