Swing is dead! Long live Swing.

[Knute Johnson]

I was doing some investigation of JavaFX and found a Q&A on the
javafx.com website.

"6. Is JavaFX replacing Swing as the new client UI library for Java SE?
Yes. However, Swing will remain part of the Java SE specification for
the foreseeable future, and is included in the JRE. On one hand, Swing
is widely used in existing Java desktop applications, but relies on an
old architecture, which requires a certain level of expertise and
specialization. On the other hand, JavaFX features a set of modern UI
controls that can be skinned using standard CSS techniques. While we
recommend developers to leverage JavaFX APIs as much as possible when
building new applications, it is possible to use Swing and JavaFX within
the same application, allowing developers to extend existing Swing
applications."

I've just started playing with JavaFX and I've got a long way to go to
really understand it but it looks fairly simple. I don't know what it
is going to be like to produce the type of GUI interfaces that I usually
do for work with it though.

Maybe we need a comp.lang.java.fx group.

knute...

 

[Roedy Green]

I've just started playing with JavaFX and I've got a long way to go to
really understand it but it looks fairly simple. I don't know what it
is going to be like to produce the type of GUI interfaces that I usually
do for work with it though.

I have been hoping for a new way of doing GUIs that was more like CSS,
where you don't specify all the details for every component
explicitly. Back in the DOS days, in my Abundance language I did not
have to explicitly label fields or lay them out. Such things should
be possible in Java. The sort of thing I would like is an
international mailing address type, that you treat like an atom. When
you give it more space on screen fields grow. When you give it less,
labels disappear, fields shrink and fields temporarily hide. It knows
about postal codes, formatting, provinces etc. and ensures the user
keys a valid address, perhaps with automatic postal code lookup
without writing code other than to enable the feature.

 

[Novice]

I was doing some investigation of JavaFX and found a Q&A on the
javafx.com website.

"6. Is JavaFX replacing Swing as the new client UI library for Java SE?
Yes. However, Swing will remain part of the Java SE specification for
the foreseeable future, and is included in the JRE. On one hand, Swing
is widely used in existing Java desktop applications, but relies on an
old architecture, which requires a certain level of expertise and
specialization. On the other hand, JavaFX features a set of modern UI
controls that can be skinned using standard CSS techniques. While we
recommend developers to leverage JavaFX APIs as much as possible when
building new applications, it is possible to use Swing and JavaFX within
the same application, allowing developers to extend existing Swing
applications."

I've just started playing with JavaFX and I've got a long way to go to
really understand it but it looks fairly simple. I don't know what it
is going to be like to produce the type of GUI interfaces that I usually
do for work with it though.

Maybe we need a comp.lang.java.fx group.

My sole experience with JavaFX is the couple of hours I've spent messing
around with it this morning so I don't speak from any great expertise.
However, given the fact that JavaFX only works in Windows XP/Vista/7 at
the moment - a Mac version exists but is apparently not that mature yet
and a Linux version is anticipated _eventually_ - I submit that JavaFX
may not be worthy of a great deal of development effort yet, at least for
those who want to develop things that are going to run on multiple
platforms, some of which _aren't_ Windows.

It may be "the next big thing" before too long and it may be worth
investing some time to learn now rather than jumping on the bandwagon
later but I'm not inclined to put much time into it until it's clear that
it will be made available for all the platforms on which we expect to run
our Java code. A statement of commitment indicating that Mac and Linux
versions WILL be available at the same or similar level to the Windows
versions by some not-too-distant date is probably all I need to get more
enthusiastic about JavaFX....

 

[Arne Vajhøj]

I was doing some investigation of JavaFX and found a Q&A on the
javafx.com website.

"6. Is JavaFX replacing Swing as the new client UI library for Java SE?
Yes. However, Swing will remain part of the Java SE specification for
the foreseeable future, and is included in the JRE. On one hand, Swing
is widely used in existing Java desktop applications, but relies on an
old architecture, which requires a certain level of expertise and
specialization. On the other hand, JavaFX features a set of modern UI
controls that can be skinned using standard CSS techniques. While we
recommend developers to leverage JavaFX APIs as much as possible when
building new applications, it is possible to use Swing and JavaFX within
the same application, allowing developers to extend existing Swing
applications."

I've just started playing with JavaFX and I've got a long way to go to
really understand it but it looks fairly simple. I don't know what it is
going to be like to produce the type of GUI interfaces that I usually do
for work with it though.

Maybe we need a comp.lang.java.fx group.

Maybe.

If there are enough applet and desktop app developers
to make it relevant.

Otherwise here would be preferable.

Arne

PS: JavaFX is actually rather cool.

 

[Arne Vajhøj]

My sole experience with JavaFX is the couple of hours I've spent messing
around with it this morning so I don't speak from any great expertise.
However, given the fact that JavaFX only works in Windows XP/Vista/7 at
the moment - a Mac version exists but is apparently not that mature yet
and a Linux version is anticipated _eventually_ - I submit that JavaFX
may not be worthy of a great deal of development effort yet, at least for
those who want to develop things that are going to run on multiple
platforms, some of which _aren't_ Windows.

It may be "the next big thing" before too long and it may be worth
investing some time to learn now rather than jumping on the bandwagon
later but I'm not inclined to put much time into it until it's clear that
it will be made available for all the platforms on which we expect to run
our Java code. A statement of commitment indicating that Mac and Linux
versions WILL be available at the same or similar level to the Windows
versions by some not-too-distant date is probably all I need to get more
enthusiastic about JavaFX....

Did you read the text you commented on?

"6. Is JavaFX replacing Swing as the new client UI library for Java SE?
Yes."

It says that JavaFX will become part of Java SE.

Then it will be on all platforms with (that version
or higher of) Java SE.

Arne

 

[Arne Vajhøj]

I have been hoping for a new way of doing GUIs that was more like CSS,
where you don't specify all the details for every component
explicitly.

That is one of the features JavaFX offers.

And Knute did even mention it (you just did not quote that part).

Arne

 

[Knute Johnson]

PS: JavaFX is actually rather cool.

I bought a book and am starting to try to learn the differences. The
thought of starting over with a new API is a little daunting.

 

[Arne Vajhøj]

I bought a book and am starting to try to learn the differences. The
thought of starting over with a new API is a little daunting.

Do yourself a favor and start using FXML and CSS right away.

Arne

 

[Knute Johnson]

Do yourself a favor and start using FXML and CSS right away.

Arne

I'm going to need another book .

 

[Arne Vajhøj]

I'm going to need another book .

javafx.* classes are fine, but that is just another GUI
API. It is when you start using fxml and css files that
it really becomes different.

Arne

 

[markspace]

Maybe we need a comp.lang.java.fx group.

Or a comp.lang.java.gui, as the swing news group is low traffic enough
to bear additional traffic for jfx.

 

[Novice]

Did you read the text you commented on?

"6. Is JavaFX replacing Swing as the new client UI library for Java
SE? Yes."

It says that JavaFX will become part of Java SE.

Then it will be on all platforms with (that version
or higher of) Java SE.

That will be fine when it is true but my point was that it this hasn't
happened yet and Oracle hasn't committed to a specific date when it will
happen.

I'm just a little leery about vaporware. It wouldn't be the first time
something like this was promised and then failed to happen for one reason
or another.

It might be a little premature to embrace JavaFX given that Oracle's
intentions may not materialize.

 

[Roedy Green]

javafx.com website.

you have to install the 32- and 64-bit versions of JavaFX separately
on the customer machine. The JDK installs it (always on the C: drive),
but not the JRE.

I found it very flaky running the demo apps, though the apps, when
they worked, were fairly impressive visually.

 

[Arne Vajhøj]

you have to install the 32- and 64-bit versions of JavaFX separately
on the customer machine. The JDK installs it (always on the C: drive),
but not the JRE.

I found it very flaky running the demo apps, though the apps, when
they worked, were fairly impressive visually.

The multimedia stuff may be a bit flaky as they must be
dependent on external software to work.

But normal GUI stuff seems rock solid to me.

Arne

 

[Arne Vajhøj]

That will be fine when it is true but my point was that it this hasn't
happened yet and Oracle hasn't committed to a specific date when it will
happen.

I'm just a little leery about vaporware. It wouldn't be the first time
something like this was promised and then failed to happen for one reason
or another.

It might be a little premature to embrace JavaFX given that Oracle's
intentions may not materialize.

It is true that we do not know what version of Java SE it will be in.
Nor do we know when that version will be available as a standard. And
we obviously do not know when all Java implementations has implemented
that standard (for some server platforms 1-2 years delay is common).

But Oracle has said that it will be part of SE.

And as I read the docs then Oracle has started distributing
JavaFX with JRE from 7u2.

http://www.oracle.com/technetwork/java/javafx/downloads/index.html

<quote>
Starting with Java SE 7 Update 2 and JavaFX 2.0.2, the JavaFX Runtime is
co-installed every time the JRE is installed.
</quote>

(that must be for Windows only)

To me that is about as good as it an be for a non-paying customer.

Arne

 

[Arne Vajhøj]

It certainly looks different, but you lose all the nice error checking
that the compiler does for you, you lose the code completion feature and
whatnot, hell that FMXL doesn't even have a schema..
On the other hand you'll have a good overview over the scene graph. I'd
only use that feature if my GUI must be changeable without recompiling.
I consider FXML a good format for GUI-Designers, that's all.

The split in Java, FXML and CSS gives a pretty good separation
of functionality, layout and style.

Not having everything checked at compile time is IMHO a small
price to pay to achieve that.

Arne

 

[Arne Vajhøj]

You don't need fxml to achieve that.

you can have a class for the layout, a class for the application code
and a .css file for the style.

True, but with the FXML-Java split the technology assist with
enforcing the split.

Arne

 

[Arne Vajhøj]

True, but with the FXML-Java split the technology assist with
enforcing the split.

Note that I will not recommend adding JavaScript to the
mix, because then suddenly there is a somewhat blurred line
between what is in Java and what is in JavaScript.

Arne

 

[Arved Sandstrom]

It certainly looks different, but you lose all the nice error checking
that the compiler does for you, you lose the code completion feature and
whatnot, hell that FMXL doesn't even have a schema..
On the other hand you'll have a good overview over the scene graph. I'd
only use that feature if my GUI must be changeable without recompiling.
I consider FXML a good format for GUI-Designers, that's all.

Kind regards,
Wanja

I don't know that much about FXML. I've used XAML a fair bit on the .NET
side, and I expect the concepts are similar. I'll probably end up
playing with FXML some, because it does look interesting: I'll be happy
when Oracle comes out with Linux and Mac OS X support, right now I'll
force myself to experiment on Windows.

Point being, and this is something that is also applicable to the
overall erratic, generally substandard history of Java IDE support for
GUI design (some IDES good, some OK, some crappy), let's say for JSF
with or without Facelets, you can get all that error-checking and code
completion if someone builds it.

To use another example, I can write complex XML complete with excellent
schemas, and write XSLT 2.0 stylesheets that process that XML, but if
I'm doing all of that using a non-aware text editor then I have no code
completion, no validation, and no error checking as I edit. If I'm using
advanced XML editors instead, I get all of that.

Similarly, if an IDE chooses to make appropriate linkages between a GUI
description language like FXML or XAML, and code-behind, then you've got
that extra checking, and you can have code completion. There is no
reason in principle why an IDE could not support both for FXML
expression bindings or controller method event handlers, for example.

A compiler is only one tool. You can't expect it to take care of
everything for you.

AHS

 

[Arne Vajhøj]

I don't know that much about FXML. I've used XAML a fair bit on the .NET
side, and I expect the concepts are similar. I'll probably end up
playing with FXML some, because it does look interesting:

Adobe MXML and MS XAML is the same concept.

I'll be happy
when Oracle comes out with Linux and Mac OS X support, right now I'll
force myself to experiment on Windows.

2.1 beta is available for Linux now.

http://www.oracle.com/technetwork/java/javafx/downloads/devpreview-1429449.html

And according to roadmap
http://www.oracle.com/technetwork/java/javafx/overview/roadmap-1446331.html
MacOS X version will be GA in Q2 and Linux version in H2.

Arne