Oracle Blog

Blog for theplanetarium

Monday Jul 06, 2009

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.

But for Swing
developers who have art and science in equal measure, JavaFX is a great companion to add to
the portfolio.

Wednesday Apr 15, 2009

A cute little newish project you may not
have seen is the ImageUploader
project over at java.net. Its a cross-platform Swing
application (screenshot)
for selecting images to upload, as the name hints at, complete with drag
and drop from native file explorers, roll-over effects, image
preview. When the time comes up upload multiple files, it POSTs
them over to a URL, complete with reassuring progress indicators. Its
under BSD,
and even the Janitor
could easily check the repo, compile it in NetBeans and have it running
within minutes.

Nice, especially as an applet, if you need image upload on your website.

Monday Mar 02, 2009

Small changes to the Java
language can have a powerful effect. How many of us remember Java
SE 5 as the release that included the for each
loop ? Sometimes, the biggest doors are opened by the smallest keys.

Thursday Feb 26, 2009

As you probably know, there's a growing number of regular podcasters
on various aspects of the Java Platforms. A great way to stay on top of
what's going on in the Java world, and hear a few stories you might not see written down.

Wednesday Feb 04, 2009

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 buildout
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 partylibrary or component.

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.

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.

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 existingapplications,
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.

So its interesting to see commercial
apps picking up on the new runtime and deployment features in the JRE.
Like the PDF
Viewer from BFO.
You can see
a video of it being dragged out of the web page here, but this
blog entry outlines the other features it uses, like control over
the heap size, and how to make the desktop shortcut to it.