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

On Wed, 15 Feb 2012 19:25:19 -0800, Knute Johnson
<nospam@rabbitbrush.frazmtn.com> wrote, quoted or indirectly quoted
someone who said :

>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.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
One of the most useful comments you can put in a program is 
"If you change this, remember to change ?XXX? too".
 

Knute Johnson <nospam@rabbitbrush.frazmtn.com> wrote in news:jhhsv4$uov$1
@dont-email.me:

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

-- 
Novice

On 2/15/2012 10:25 PM, Knute Johnson wrote:
> 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.

On 2/16/2012 2:13 PM, Novice wrote:
> Knute Johnson<nospam@rabbitbrush.frazmtn.com>  wrote in news:jhhsv4$uov$1
> @dont-email.me:
>> 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....

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

On 2/15/2012 11:13 PM, Roedy Green wrote:
> On Wed, 15 Feb 2012 19:25:19 -0800, Knute Johnson
> <nospam@rabbitbrush.frazmtn.com>  wrote, quoted or indirectly quoted
> someone who said :
>
>> 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.

That is one of the features JavaFX offers.

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

Arne

On 2/16/2012 3:29 PM, Arne Vajh�j wrote:
>
> 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.

-- 

Knute Johnson

On 2/16/2012 6:50 PM, Knute Johnson wrote:
> On 2/16/2012 3:29 PM, Arne Vajh�j wrote:
>> 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.

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

Arne

On 2/16/2012 3:52 PM, Arne Vajh�j wrote:
> On 2/16/2012 6:50 PM, Knute Johnson wrote:
>> On 2/16/2012 3:29 PM, Arne Vajh�j wrote:
>>> 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.
>
> Do yourself a favor and start using FXML and CSS right away.
>
> Arne
>
>

I'm going to need another book :-).

-- 

Knute Johnson

On 2/16/2012 7:01 PM, Knute Johnson wrote:
> On 2/16/2012 3:52 PM, Arne Vajh�j wrote:
>> On 2/16/2012 6:50 PM, Knute Johnson wrote:
>>> On 2/16/2012 3:29 PM, Arne Vajh�j wrote:
>>>> 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.
>>
>> Do yourself a favor and start using FXML and CSS right away.
>
> 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

On 2/15/2012 7:25 PM, Knute Johnson wrote:

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

Arne Vajh�j <arne@vajhoej.dk> wrote in
news:4f3d91f3$0$291$14726298@news.sunsite.dk: 

> On 2/16/2012 2:13 PM, Novice wrote:
>> Knute Johnson<nospam@rabbitbrush.frazmtn.com>  wrote in
>> news:jhhsv4$uov$1 @dont-email.me:
>>> 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....
> 
> 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. 

-- 
Novice

On Wed, 15 Feb 2012 19:25:19 -0800, Knute Johnson
<nospam@rabbitbrush.frazmtn.com> wrote, quoted or indirectly quoted
someone who said :

>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.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
One of the most useful comments you can put in a program is 
"If you change this, remember to change ?XXX? too".
 

On 2/17/2012 12:24 PM, Roedy Green wrote:
> On Wed, 15 Feb 2012 19:25:19 -0800, Knute Johnson
> <nospam@rabbitbrush.frazmtn.com>  wrote, quoted or indirectly quoted
> someone who said :
>
>> 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.

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

On 2/17/2012 11:35 AM, Novice wrote:
> Arne Vajh�j<arne@vajhoej.dk>  wrote in
> news:4f3d91f3$0$291$14726298@news.sunsite.dk:
>
>> On 2/16/2012 2:13 PM, Novice wrote:
>>> Knute Johnson<nospam@rabbitbrush.frazmtn.com>   wrote in
>>> news:jhhsv4$uov$1 @dont-email.me:
>>>> 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....
>>
>> 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.

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

In article <4f3d96c1$0$293$14726298@news.sunsite.dk>, arne@vajhoej.dk 
says...
> 
> On 2/16/2012 6:50 PM, Knute Johnson wrote:
> > On 2/16/2012 3:29 PM, Arne Vajh�j wrote:
> >> 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.
> 
> Do yourself a favor and start using FXML and CSS right away.

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

-- 
...Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

On 2/20/2012 2:27 PM, Wanja Gayk wrote:
> In article<4f3d96c1$0$293$14726298@news.sunsite.dk>, arne@vajhoej.dk
> says...
>>
>> On 2/16/2012 6:50 PM, Knute Johnson wrote:
>>> On 2/16/2012 3:29 PM, Arne Vajh�j wrote:
>>>> 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.
>>
>> Do yourself a favor and start using FXML and CSS right away.
>
> 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

In article <4f42d9a5$0$295$14726298@news.sunsite.dk>, arne@vajhoej.dk 
says...

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

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.

Kind regards,
Wanja


-- 
...Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

On 2/20/2012 8:09 PM, Wanja Gayk wrote:
> In article<4f42d9a5$0$295$14726298@news.sunsite.dk>, arne@vajhoej.dk
> says...
>
>>>>> 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.
>>>
>>> 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.
>
> 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

On 2/20/2012 8:28 PM, Arne Vajh�j wrote:
> On 2/20/2012 8:09 PM, Wanja Gayk wrote:
>> In article<4f42d9a5$0$295$14726298@news.sunsite.dk>, arne@vajhoej.dk
>> says...
>>
>>>>>> 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.
>>>>
>>>> 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.
>>
>> 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.

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

On 12-02-20 03:27 PM, Wanja Gayk wrote:
> In article <4f3d96c1$0$293$14726298@news.sunsite.dk>, arne@vajhoej.dk 
> says...
>>
>> On 2/16/2012 6:50 PM, Knute Johnson wrote:
>>> On 2/16/2012 3:29 PM, Arne Vajh�j wrote:
>>>> 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.
>>
>> Do yourself a favor and start using FXML and CSS right away.
> 
> 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
-- 
-- Gaiety is the most outstanding feature of the Soviet Union.
Josef Stalin, November 1935

On 2/25/2012 10:37 AM, Arved Sandstrom wrote:
> On 12-02-20 03:27 PM, Wanja Gayk wrote:
>> In article<4f3d96c1$0$293$14726298@news.sunsite.dk>, arne@vajhoej.dk
>> says...
>>>
>>> On 2/16/2012 6:50 PM, Knute Johnson wrote:
>>>> On 2/16/2012 3:29 PM, Arne Vajh�j wrote:
>>>>> 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.
>>>
>>> Do yourself a favor and start using FXML and CSS right away.
>>
>> 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.

> 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

In article <6f72r.16359$L12.15612@newsfe23.iad>, asandstrom3minus1
@eastlink.ca says...

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

Of course not, but in this case you've got the choice between letting 
the compiler (or let's say the IDE's background compilation) take care 
of something or not.
I've been frequently annoyed by tools that do their binding by matching 
Strings to classes or component names, because every time you move, 
refactor or mistype something you're bound to get screwed. And it likes 
to happen in the worst possible moments. I'd rather avoid it, if I have 
the choice.

Kind regards,
anja


-- 
...Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

On 2/26/2012 9:24 AM, Wanja Gayk wrote:

> I've been frequently annoyed by tools that do their binding by matching
> Strings to classes or component names, because every time you move,
> refactor or mistype something you're bound to get screwed. And it likes
> to happen in the worst possible moments. I'd rather avoid it, if I have
> the choice.


I tend to agree, strongly.  For situations where I might be tempted to 
just use strings, I try to substitute enums.  For example, instead of

  bind( someComponent, "event-name" );

I'd use this:

  bind( someComponent, Events.NAME );

It provides automatic syntax checking, and is much easier to refactor if 
names need to be changed or moved around later.

Any thoughts on this idea?

Wanja Gayk wrote:
> asandstrom3minus1 says...
>
>> 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.
>
> Of course not, but in this case you've got the choice between letting
> the compiler (or let's say the IDE's background compilation) take care
> of something or not.
> I've been frequently annoyed by tools that do their binding by matching
> Strings to classes or component names, because every time you move,
> refactor or mistype something you're bound to get screwed. And it likes
> to happen in the worst possible moments. I'd rather avoid it, if I have
> the choice.

+1

Why use string-based binding like that in Java, among whose main strengths is 
rigorous type safety?

Sometimes in frameworks you'll do that, e.g., name an implementing class in a 
properties or XML configuration file, but the cost is always deferral of 
less-expensive compile-time safety to later, more costly run-time type 
failures. The benefit had better be worth it, and also worth the fragmentation 
of logic across more source artifacts.

I've seen the sacrifice made in code, too. That's just an execration. One 
egregious example I saw used reflection and casting to obtain a no-argument 
constructor based on matching class names to certain other class names, but 
still requiring casting through those same types. They sacrificed type safety, 
performance, simplicity and good sense to create a "factory" that had none of 
the benefits of an actual factory.

Prefer compile-time type assertions to run-time matchups.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

markspace wrote:
> Wanja Gayk wrote:
>> I've been frequently annoyed by tools that do their binding by matching
>> Strings to classes or component names, because every time you move,
>> refactor or mistype something you're bound to get screwed. And it likes
>> to happen in the worst possible moments. I'd rather avoid it, if I have
>> the choice.
>
>
> I tend to agree, strongly. For situations where I might be tempted to just use
> strings, I try to substitute enums. For example, instead of
>
> bind( someComponent, "event-name" );
>
> I'd use this:
>
> bind( someComponent, Events.NAME );
>
> It provides automatic syntax checking, and is much easier to refactor if names
> need to be changed or moved around later.
>
> Any thoughts on this idea?

+1

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

On 2/26/2012 1:27 PM, markspace wrote:
> On 2/26/2012 9:24 AM, Wanja Gayk wrote:
>> I've been frequently annoyed by tools that do their binding by matching
>> Strings to classes or component names, because every time you move,
>> refactor or mistype something you're bound to get screwed. And it likes
>> to happen in the worst possible moments. I'd rather avoid it, if I have
>> the choice.
>
>
> I tend to agree, strongly. For situations where I might be tempted to
> just use strings, I try to substitute enums. For example, instead of
>
> bind( someComponent, "event-name" );
>
> I'd use this:
>
> bind( someComponent, Events.NAME );
>
> It provides automatic syntax checking, and is much easier to refactor if
> names need to be changed or moved around later.
>
> Any thoughts on this idea?

The idea is perfect.

But I don't think it is possible for the Java-FXML scenario.

Arne

On 12-02-26 05:16 PM, Lew wrote:
> Wanja Gayk wrote:
>> asandstrom3minus1 says...
>>
>>> 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.
>>
>> Of course not, but in this case you've got the choice between letting
>> the compiler (or let's say the IDE's background compilation) take care
>> of something or not.
>> I've been frequently annoyed by tools that do their binding by matching
>> Strings to classes or component names, because every time you move,
>> refactor or mistype something you're bound to get screwed. And it likes
>> to happen in the worst possible moments. I'd rather avoid it, if I have
>> the choice.
> 
> +1
> 
> Why use string-based binding like that in Java, among whose main
> strengths is rigorous type safety?
> 
> Sometimes in frameworks you'll do that, e.g., name an implementing class
> in a properties or XML configuration file, but the cost is always
> deferral of less-expensive compile-time safety to later, more costly
> run-time type failures. The benefit had better be worth it, and also
> worth the fragmentation of logic across more source artifacts.
> 
> I've seen the sacrifice made in code, too. That's just an execration.
> One egregious example I saw used reflection and casting to obtain a
> no-argument constructor based on matching class names to certain other
> class names, but still requiring casting through those same types. They
> sacrificed type safety, performance, simplicity and good sense to create
> a "factory" that had none of the benefits of an actual factory.
> 
> Prefer compile-time type assertions to run-time matchups.
> 
I agree with you guys in general, but I'm not sure I see the problem for
the situation we are discussing. Whether it's FXML or Facelets XHTML in
JSF, or XAML over in .NET land [1], you're talking about things that
have strong mappings to the code-behind (whether Java or C#).

There is no need to discover only at _runtime_ that your "strings" were
wrong. Both JSF Facelets XHTML and FXML are amenable to having a great
deal of rigorous checking done by hypothetical toolsets before the
underlying Java ever gets compiled. If a particular method in a
particular Java class is called for, that can be checked in principle
before building.

If your hypothetical tool is "screwing you" every time you make a typo
or other mistake when moving, renaming or otherwise refactoring things,
then I suggest that the hypothetical tool sucks...to use technical
terminology. As an example, let's say I've got EL in a JSF Facelets page
that references a couple of managed beans. So you've got references to
the @ManagedBean or @Named names, to the getters/setters in those
classes, and to action methods. You're seriously telling me that a
decent tool couldn't solidly track the reference bindings and do proper
refactorings for that stuff?

Same goes for FXML: where elements of FXML are references to Java
things, a proper tool can clearly maintain the mappings between FXML and
Java.

Surprise, surprise: you actually do have some tools out there that
competently do stuff like this, like IntelliJ IDEA for JSF 2.0.

And you know, you can thoroughly mess up when renaming, moving or
otherwise refactoring in a pure Java environment too, and all your
compiler will tell you is in how many places you now have a mistake.
I've seen plenty of cases where developers - myself included - thought
they knew all the usage sites of something, and figured to manually
refactor. In more than just a few cases that manual refactoring resulted
in something that *compiled* just fine, but was now erroneous, maybe
because you typo'd something. It can absolutely happen, easily actually.

So using *tool*-assisted refactoring makes much sense. In which case,
why is one kind of tool-assisted management OK and another kind bad?

AHS

1. XAML not the same thing as the other technologies I mention, but in
one of its uses, as a UI markup language in WPF, there are strong
similarities.
-- 
-- Gaiety is the most outstanding feature of the Soviet Union.
Josef Stalin, November 1935

Arved Sandstrom wrote:
> I agree with you guys in general, but I'm not sure I see the problem for
> the situation we are discussing. Whether it's FXML or Facelets XHTML in
> JSF, or XAML over in .NET land [1], you're talking about things that
> have strong mappings to the code-behind (whether Java or C#).
>
> There is no need to discover only at _runtime_ that your "strings" were
> wrong. Both JSF Facelets XHTML and FXML are amenable to having a great
> deal of rigorous checking done by hypothetical toolsets before the
> underlying Java ever gets compiled. If a particular method in a
> particular Java class is called for, that can be checked in principle
> before building.

This approach works well, and tool choice is an important part of programming.

The key principle is to catch problems early and even earlier. 
Compilation-level type safety is the strongest tool for that, when applicable. 
Post-deployment tools are the weakest. What you describe is between those 
extremes.

As I said in my post, there are use cases for offloading type checking from 
the compiler. Your suggestions reduce the cost of that decision, making the 
cost-benefit analysis tilt more in favor of doing such offloading.

> If your hypothetical tool is "screwing you" every time you make a typo
> or other mistake when moving, renaming or otherwise refactoring things,
> then I suggest that the hypothetical tool sucks...to use technical
> terminology. As an example, let's say I've got EL in a JSF Facelets page
> that references a couple of managed beans. So you've got references to
> the @ManagedBean or @Named names, to the getters/setters in those
> classes, and to action methods. You're seriously telling me that a
> decent tool couldn't solidly track the reference bindings and do proper
> refactorings for that stuff?

I haven't seen anyone make that claim here. Have you? To whom is that question 
addressed?

The egregious example I cited was not a case of a tool screwing them. It was a 
case of custom fubaration of something simple into a right mess.

One claim I do make is that the further down from compilation to customer use 
you go, the worse it is to catch and fix problems. I compared the endpoints; 
you provided a midpoint in that spectrum. I do not claim, in fact explicitly 
disclaimed that one should never pay such a cost. It's a question of what you 
can afford and what it buys you, always.

The problem is that people often unwittingly pay more than they should, and 
worse, get no benefit thereby. You must be aware.

With Java you are certain to have a compiler and a runtime. I certainly would 
never espouse relying only on those two tools as if none others exist, but the 
more you can get the compiler to do, without sacrificing what you need, the 
cheaper it is to be right.

> Same goes for FXML: where elements of FXML are references to Java
> things, a proper tool can clearly maintain the mappings between FXML and
> Java.
>
> Surprise, surprise: you actually do have some tools out there that
> competently do stuff like this, like IntelliJ IDEA for JSF 2.0.

Does it work with FXML?

> And you know, you can thoroughly mess up when renaming, moving or
> otherwise refactoring in a pure Java environment too, and all your
> compiler will tell you is in how many places [and precisely where! - ed.] you now have a mistake.

Right, but at least you know at compilation and not later.

> I've seen plenty of cases where developers - myself included - thought
> they knew all the usage sites of something, and figured to manually
> refactor. In more than just a few cases that manual refactoring resulted
> in something that *compiled* just fine, but was now erroneous, maybe
> because you typo'd something. It can absolutely happen, easily actually.

Doesn't IntelliJ reduce the cost of refactoring? Why not use its capabilities 
for that?

No one is claiming that compilers and type safety solve all problems. What are 
you hoping to prove? The fact remains that errors that *are* caught at 
compilation are cheaper to fix than those caught later. The ones that are 
missed don't change that.

> So using *tool*-assisted refactoring makes much sense. In which case,
> why is one kind of tool-assisted management OK and another kind bad?

I'm on your side with this question.

> 1. XAML not the same thing as the other technologies I mention, but in
> one of its uses, as a UI markup language in WPF, there are strong
> similarities.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

On 2/26/2012 7:59 PM, Lew wrote:
> Arved Sandstrom wrote:
....
> One claim I do make is that the further down from compilation to
> customer use you go, the worse it is to catch and fix problems. I
> compared the endpoints; you provided a midpoint in that spectrum. I do
> not claim, in fact explicitly disclaimed that one should never pay such
> a cost. It's a question of what you can afford and what it buys you,
> always.

 > No one is claiming that compilers and type safety solve all problems.
 > What are you hoping to prove? The fact remains that errors that *are*
 > caught at compilation are cheaper to fix than those caught later. The
 > ones that are missed don't change that.

I agree with the principle of earlier is better.

But note that an inconsistency between Java and FXML will
cause an exception every time the scene is attempted to be
displayed.

I will expect GUI developers to try and run their GUI at least once
before considering a change to be done.

So the practical difference between compile time error and runtime
error in this specific case is not as big as in many other cases.

>> Same goes for FXML: where elements of FXML are references to Java
>> things, a proper tool can clearly maintain the mappings between FXML and
>> Java.
>>
>> Surprise, surprise: you actually do have some tools out there that
>> competently do stuff like this, like IntelliJ IDEA for JSF 2.0.
>
> Does it work with FXML?

I would assume not.

I would also assume that tools for FXML will show up if/when
JavaFX becomes popular.

Arne

Arne Vajhøj wrote:
> Lew wrote:
>> One claim I do make is that the further down from compilation to
>> customer use you go, the worse it is to catch and fix problems. I
>> compared the endpoints; you provided a midpoint in that spectrum. I do
>> not claim, in fact explicitly disclaimed that one should never pay such
>> a cost. It's a question of what you can afford and what it buys you,
>> always.
>
>> No one is claiming that compilers and type safety solve all problems.
>> What are you hoping to prove? The fact remains that errors that *are*
>> caught at compilation are cheaper to fix than those caught later. The
>> ones that are missed don't change that.
>
> I agree with the principle of earlier is better.
>
> But note that an inconsistency between Java and FXML will
> cause an exception every time the scene is attempted to be
> displayed.
>
> I will expect GUI developers to try and run their GUI at least once
> before considering a change to be done.
>
> So the practical difference between compile time error and runtime
> error in this specific case is not as big as in many other cases.

I was careful to use the term "compilation to customer". You're still talking 
about a point well before customer exposure. You do illustrate that there's a 
continuum involved.

I reiterate that compile-time checks are not going to catch everything. I 
reiterate the point others including you make that there are stages between 
compilation and customer. I reiterate that along that continuum are many 
useful steps, and I concur that they're all needed.

Everything is about cost-benefit. You have so much time and energy in a 
project to fix bugs, refactor, add features, and do QA. QA cannot be all 
manual and catch everything after the fact, even at the penultimate stage 
before customer deployment. As much as possible (but no more) must be pushed 
to compilation and other early at-developer-desk stages. As much as possible 
(but no more) of what's left must be pushed to early integration testing. As 
much as possible (but no more) of what's left must be pushed to later 
pre-deployment testing. As much as possible (but no more) of all that testing 
must be automated. As little as possible (and even less) must go wrong at the 
customer site.

Some might argue that "must" is too strong; "should" will suffice. To those I 
say sure, if you aren't motivated to do the most good for the least effort and 
cost, by all means use "should".

Arne Vajhøj wrote:
> Lew wrote:
>> Arved Sandstrom wrote:
> ...
>>> Same goes for FXML: where elements of FXML are references to Java
>>> things, a proper tool can clearly maintain the mappings between FXML and
>>> Java.
>>>
>>> Surprise, surprise: you actually do have some tools out there that
>>> competently do stuff like this, like IntelliJ IDEA for JSF 2.0.
>>
>> Does it work with FXML?
>
> I would assume not.
>
> I would also assume that tools for FXML will show up if/when
> JavaFX becomes popular.

The whole point of the "use tools!" rant is sort of moot if the tools aren't 
ready yet.

-- 
Lew
Some say the only requirements in life are death and taxes. Not true. The 
prisons have many inmates who freely chose not to pay their taxes.

On 2/27/2012 12:22 AM, Lew wrote:
> Arne Vajhøj wrote:
>> Lew wrote:
>>> One claim I do make is that the further down from compilation to
>>> customer use you go, the worse it is to catch and fix problems. I
>>> compared the endpoints; you provided a midpoint in that spectrum. I do
>>> not claim, in fact explicitly disclaimed that one should never pay such
>>> a cost. It's a question of what you can afford and what it buys you,
>>> always.
>>
>>> No one is claiming that compilers and type safety solve all problems.
>>> What are you hoping to prove? The fact remains that errors that *are*
>>> caught at compilation are cheaper to fix than those caught later. The
>>> ones that are missed don't change that.
>>
>> I agree with the principle of earlier is better.
>>
>> But note that an inconsistency between Java and FXML will
>> cause an exception every time the scene is attempted to be
>> displayed.
>>
>> I will expect GUI developers to try and run their GUI at least once
>> before considering a change to be done.
>>
>> So the practical difference between compile time error and runtime
>> error in this specific case is not as big as in many other cases.
>
> I was careful to use the term "compilation to customer". You're still
> talking about a point well before customer exposure. You do illustrate
> that there's a continuum involved.
>
> I reiterate that compile-time checks are not going to catch everything.
> I reiterate the point others including you make that there are stages
> between compilation and customer. I reiterate that along that continuum
> are many useful steps, and I concur that they're all needed.
>
> Everything is about cost-benefit. You have so much time and energy in a
> project to fix bugs, refactor, add features, and do QA. QA cannot be all
> manual and catch everything after the fact, even at the penultimate
> stage before customer deployment. As much as possible (but no more) must
> be pushed to compilation and other early at-developer-desk stages. As
> much as possible (but no more) of what's left must be pushed to early
> integration testing. As much as possible (but no more) of what's left
> must be pushed to later pre-deployment testing. As much as possible (but
> no more) of all that testing must be automated. As little as possible
> (and even less) must go wrong at the customer site.
>
> Some might argue that "must" is too strong; "should" will suffice. To
> those I say sure, if you aren't motivated to do the most good for the
> least effort and cost, by all means use "should".

Many words.

And it is correct.

It is just not going to make much difference in this case.

Arne

On 2/17/2012 6:00 PM, Arne Vajh�j wrote:
> On 2/17/2012 11:35 AM, Novice wrote:
>> Arne Vajh�j<arne@vajhoej.dk> wrote in
>> news:4f3d91f3$0$291$14726298@news.sunsite.dk:
>>
>>> On 2/16/2012 2:13 PM, Novice wrote:
>>>> Knute Johnson<nospam@rabbitbrush.frazmtn.com> wrote in
>>>> news:jhhsv4$uov$1 @dont-email.me:
>>>>> 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....
>>>
>>> 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.
>
> 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.

Actually Oracle has announced something now.

http://www.infoworld.com/slideshow/28552/java-roadmap-oracles-two-year-plan-185238

Slide 7

<quote>
Summer 2013: JDK 8

This release features modular capabilities via Project Jigsaw, as well 
as JavaScript interoperability, Java Virtual Machine convergence, JavaFX 
3.0, and Java closures capabilities and bulk parallel operations via the 
Lambda project.
</quote?

So JavaFX 3.0 - Java SE 8 - summer 2013.

If everything works out as planned. Software projects
has been delayed before! :-)

Arne

In article <jidthv$psp$1@dont-email.me>, -@. says...

> > I've been frequently annoyed by tools that do their binding by matching
> > Strings to classes or component names, because every time you move,
> > refactor or mistype something you're bound to get screwed. And it likes
> > to happen in the worst possible moments. I'd rather avoid it, if I have
> > the choice.

> I tend to agree, strongly.  For situations where I might be tempted to 
> just use strings, I try to substitute enums.  For example, instead of
> 
>   bind( someComponent, "event-name" );
> 
> I'd use this:
> 
>   bind( someComponent, Events.NAME );
> 
> It provides automatic syntax checking, and is much easier to refactor if 
> names need to be changed or moved around later.
> 
> Any thoughts on this idea?

I think the same way.
I'm even going further and strongly propose preferring Enums to boolean 
parameters and this is why:
http://brixomatic.wordpress.com/2010/02/24/boolean-harmful/

Kind regards, 
Wanja


-- 
...Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

In article <jie7f0$64h$1@news.albasani.net>, noone@lewscanon.com says...

> Why use string-based binding like that in Java, among whose main strengths is 
> rigorous type safety?

That's what I've been asking myself over and over when dealing with the 
Reflection-API. I once found a more or less pleasing solution to the 
reflection-string-mess for me, assumed there is an interface:

http://brixomatic.wordpress.com/2010/08/09/reflection-without-strings/

But of course that's just a workaround for not being able to reference a 
method directly, like:
Method collectionSize = Collection#size();
int size = (int)collectionSize.invoke(someList);

> Sometimes in frameworks you'll do that, e.g., name an implementing class in a 
> properties or XML configuration file, but the cost is always deferral of 
> less-expensive compile-time safety to later, more costly run-time type 
> failures. The benefit had better be worth it, and also worth the fragmentation 
> of logic across more source artifacts.

You're absolutely right. I have found that most of the times the benefit 
boils down to being able to change something while the program is 
running and I rarely come across a situation where this is really 
necessary.

Kind regards,
Wanja

-- 
...Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Wanja Gayk wrote:
> markspace wrote:
>> ...  For situations where I might be tempted to just use strings,
>> I try to substitute enums.  For example, instead of
>>
>>    bind( someComponent, "event-name" );
>>
>> I'd use this:
>>
>>    bind( someComponent, Events.NAME );
>>
>> It provides automatic syntax checking, and is much easier to refactor if
>> names need to be changed or moved around later.
>>
>> Any thoughts on this idea?
>
> I think the same way.
> I'm even going further and strongly propose preferring Enums to boolean
> parameters and this is why:
> http://brixomatic.wordpress.com/2010/02/24/boolean-harmful/

+1

This might irritate those who already find Java verbose, since 'String's are 
more compact to declare, but type safety and refactorability [sic] is a payoff 
in many situations.

I'm even worse, because I pump a "friendly" string representation into the enum.
<http://docs.oracle.com/javase/7/docs/api/java/lang/Enum.html#toString()>
«An enum type should override this method when a more "programmer-friendly" 
string form exists.»

Necessitating a corresponding 'public static E fromString(String rep)'.

'fromString()' compares 'toString()' strings first; if those fail it delegates 
to 'valueOf()'.

<sscce source="eegee/Essential.java">
package eegee;
/**
  * Essential {@code enum} implementation with "friendly" representation.
  */
public enum Essential
{
   FOO("foo"),
   BAR("bar"),
   FANCY("fancy form"),
   ANOMALY("useful to hold log or error messages"),
   ;
   private static final long serialVersionUID = 1L;

   private final String representation;

   /**
     * Constructor setting the friendly representation.
     * @param rep String friendly representation of constant.
     */
   private Essential(String rep)
   {
     this.representation = rep;
     assert this.representation != null;
   }

   @Override
   public final String toString()
   {
     return representation;
   }

   /**
     * Look up enum constant from String representation.
     * @param rep String representation of enum constant.
     * @return Essential constant matching the representation.
     */
   public static Essential fromString(String rep)
   {
     if (rep == null)
     {
       return null;
     }
     for (Essential value : values())
     {
       if (rep.equals(value.toString()))
       {
         return value;
       }
     }
     return valueOf(rep);
   }
}
</sscce>

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

On 12-02-28 06:19 PM, Wanja Gayk wrote:
> In article <jidthv$psp$1@dont-email.me>, -@. says...
> 
>>> I've been frequently annoyed by tools that do their binding by matching
>>> Strings to classes or component names, because every time you move,
>>> refactor or mistype something you're bound to get screwed. And it likes
>>> to happen in the worst possible moments. I'd rather avoid it, if I have
>>> the choice.
> 
>> I tend to agree, strongly.  For situations where I might be tempted to 
>> just use strings, I try to substitute enums.  For example, instead of
>>
>>   bind( someComponent, "event-name" );
>>
>> I'd use this:
>>
>>   bind( someComponent, Events.NAME );
>>
>> It provides automatic syntax checking, and is much easier to refactor if 
>> names need to be changed or moved around later.
>>
>> Any thoughts on this idea?
> 
> I think the same way.
> I'm even going further and strongly propose preferring Enums to boolean 
> parameters and this is why:
> http://brixomatic.wordpress.com/2010/02/24/boolean-harmful/
> 
> Kind regards, 
> Wanja
> 
This little sub-thread I would have re-declared a few posts ago. You
guys are advancing good ideas, but confusing the issue by making it
sound like, in the context of the original discussion, that the end-user
developer of FXML is going to be worried about these details when in
fact he or she is not: it's the tools builder who is.

That changes the discussion radically. Tools often use techniques and do
things which sometimes cannot be recommended for the developer pool at
large, because they are tricky and/or dangerous, and only above-average
programmers ought to be doing things like that.

I happen to agree in general that you use enums when you can. I don't
see what these recommendations for Joe Average Coder have to do with a
discussion of potential tool support for FXML.

AHS
-- 
-- Gaiety is the most outstanding feature of the Soviet Union.
Josef Stalin, November 1935

In article <BAm3r.14416$vo2.12997@newsfe07.iad>, asandstrom3minus1
@eastlink.ca says...

> > I think the same way.
> > I'm even going further and strongly propose preferring Enums to boolean 
> > parameters and this is why:
> > http://brixomatic.wordpress.com/2010/02/24/boolean-harmful/
> > 
> This little sub-thread I would have re-declared a few posts ago.

I agree that the discussion got off topic and might need a subject 
change if continued.

Kind regards,
Wanja


-- 
...Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

On 2/29/12 12:00 AM, Lew wrote:
> Wanja Gayk wrote:
>> markspace wrote:
>>> ... For situations where I might be tempted to just use strings,
>>> I try to substitute enums. For example, instead of
>>>
>>> bind( someComponent, "event-name" );
>>>
>>> I'd use this:
>>>
>>> bind( someComponent, Events.NAME );
>>>
>>> It provides automatic syntax checking, and is much easier to refactor if
>>> names need to be changed or moved around later.
>>>
>>> Any thoughts on this idea?
>>
>> I think the same way.
>> I'm even going further and strongly propose preferring Enums to boolean
>> parameters and this is why:
>> http://brixomatic.wordpress.com/2010/02/24/boolean-harmful/
>
> +1
>
> This might irritate those who already find Java verbose, since 'String's
> are more compact to declare, but type safety and refactorability [sic]
> is a payoff in many situations.
>
> I'm even worse, because I pump a "friendly" string representation into
> the enum.
> <http://docs.oracle.com/javase/7/docs/api/java/lang/Enum.html#toString()>
> «An enum type should override this method when a more
> "programmer-friendly" string form exists.»
I'm even worse than that. My designs often include replacing a boolean 
with an Enum that has *logic* in it. Flyweight strategy pattern.

public enum FooStrategy {
    ONE_WAY {
       public void handle(Foo foo) {
          foo.doItOneWay();
       }
    },

    ANOTHER {
       public void handle(Foo foo) {
          foo.doItAnother();
       }
    }
    ;
    public abstract void handle(Foo foo);
}

This is more verbose but ends up being more flexible and easier to 
maintain.  Enums can even implement interfaces, so you could add 
additional layer of abstraction which allows custom or statefull 
implementations alongside the the enum implementations.