Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Swing is dead! Long live Swing.

Reply
Thread Tools

Swing is dead! Long live Swing.

 
 
markspace
Guest
Posts: n/a
 
      02-26-2012
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?

 
Reply With Quote
 
 
 
 
Lew
Guest
Posts: n/a
 
      02-26-2012
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/wikipedi.../c/cf/Friz.jpg
 
Reply With Quote
 
 
 
 
Lew
Guest
Posts: n/a
 
      02-26-2012
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/wikipedi.../c/cf/Friz.jpg
 
Reply With Quote
 
Arne Vajhj
Guest
Posts: n/a
 
      02-26-2012
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


 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      02-26-2012
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

 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      02-27-2012
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/wikipedi.../c/cf/Friz.jpg
 
Reply With Quote
 
Arne Vajhøj
Guest
Posts: n/a
 
      02-27-2012
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
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      02-27-2012
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.
 
Reply With Quote
 
Arne Vajhøj
Guest
Posts: n/a
 
      02-28-2012
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


 
Reply With Quote
 
Arne Vajhj
Guest
Posts: n/a
 
      02-28-2012
On 2/17/2012 6:00 PM, Arne Vajhj wrote:
> On 2/17/2012 11:35 AM, Novice wrote:
>> Arne Vajhj<(E-Mail Removed)> wrote in
>> news:4f3d91f3$0$291$(E-Mail Removed):
>>
>>> On 2/16/2012 2:13 PM, Novice wrote:
>>>> Knute Johnson<(E-Mail Removed)> 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/ja...ads/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/2...ar-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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Having compilation error: no match for call to (const __gnu_cxx::hash<long long int>) (const long long int&) veryhotsausage C++ 1 07-04-2008 05:41 PM
Use of Long and Long Long Bart C C Programming 27 01-15-2008 05:27 AM
long long and long Mathieu Dutour C Programming 4 07-24-2007 11:15 AM
unsigned long long int to long double Daniel Rudy C Programming 5 09-20-2005 02:37 AM
Assigning unsigned long to unsigned long long George Marsaglia C Programming 1 07-08-2003 05:16 PM



Advertisments