Is Java good for writing simple, yet sleek GUI apps?

[Love Rhino]

Hello there.

I have 10+ years doing C/C++/Unix development writing
databases, compilers, and network software. I have
a few years of Java experience.

I need to write a GUI application for the fairly recent
versions of Windows (NT, XP, 2000...). Since I'm all about
interoperability, I'm thinking about using Java to do it.
I don't have *any* GUI experience, nor Windows experience.

My worry is that Java Swing isn't ideal for me. Many
developers I've talked to, and website reviews I've read,
say it's slow and overly complex for very simple things.

I'm wondering if that's just old news, and the latest
version of Swing addresses those problems? If not, can
you recommend other alternatives to Swing, that are
reasonably fast and portable?

My project is straight forward. Provide some buttons
for users to query a database, and display the data.
Some of the queries may require the user for specific
dates, amounts, etc. Provide some forms for users to
add data to a database. Later versions, I would like
the data to be displayed on a spreadsheet like table
and to be able to left/right click the cell for futher
drill downs, but that's later versions. My boss wants
a proof of concept, right now that doesn't look
ugly.

I'm thinking about going the VB route, but my Unix
intuition says to stay away. The better solution is to
give the project to a GUI guy.

Anyways, any suggestions would be great. Thanks for
your time!

 

[steve]

Hello there.

I have 10+ years doing C/C++/Unix development writing
databases, compilers, and network software. I have
a few years of Java experience.

I need to write a GUI application for the fairly recent
versions of Windows (NT, XP, 2000...). Since I'm all about
interoperability, I'm thinking about using Java to do it.
I don't have *any* GUI experience, nor Windows experience.

My worry is that Java Swing isn't ideal for me. Many
developers I've talked to, and website reviews I've read,
say it's slow and overly complex for very simple things.

I'm wondering if that's just old news, and the latest
version of Swing addresses those problems? If not, can
you recommend other alternatives to Swing, that are
reasonably fast and portable?

My project is straight forward. Provide some buttons
for users to query a database, and display the data.
Some of the queries may require the user for specific
dates, amounts, etc. Provide some forms for users to
add data to a database. Later versions, I would like
the data to be displayed on a spreadsheet like table
and to be able to left/right click the cell for futher
drill downs, but that's later versions. My boss wants
a proof of concept, right now that doesn't look
ugly.

I'm thinking about going the VB route, but my Unix
intuition says to stay away. The better solution is to
give the project to a GUI guy.

Anyways, any suggestions would be great. Thanks for
your time!

I would say you are talking to idiots, who are so far out of date on their
technical skill , it is sad.

the trick with java is all in the threads, most bad developers try to do
everything in 1 thread, ( usually the graphics thread), so they end up with
shitty ,slow programs. which they then blame on the java.
The idea is to launch multiple threads , so that operations do not block each
other & bog your application down.



check out the following: (iReport-Designer)
http://sourceforge.net/project/showfiles.php?group_id=64348


this will give you an idea as to speed, cross platform issues etc, of using
java. (I.E with a good programmer there are virtually none)

it will also allow you to "Build" graphical reports tied to most major
databases.
it had a drag & drop interface, for fields/text etc.
( you can compile 90% of the report, then the other 10% can be queried from
the user), or you can write a java plugin, that can query the user during the
running of the report.


this ties into Jasperreports (java)
http://sourceforge.net/projects/jasperreports

which can produce and output reports in a number of different formats.

PDF/HTML/EXCEL/XML/ Whatever



or go to
www.oracle.com
find "JDeveloper", this is a complete IDE written in java.

I would guess , completing your task could be done in a morning , in
JDeveloper.

if you are using ORACLE database, I can get you started, with any help you
need, on any of the above. if you are using another database i cannot help
too much.



steve

 

[kjc]

I can't speak for everyone, but, I don't find Swing complex at all.
If you've been using C++ as long as you say. It should be a cake walk
for you. Swing is VERY OO centric. It is VERY flexible for building
complex GUI's. However issues can and WILL arise when/if doing I/O of
one form or another. You will have to make use of the java
multithreading capabilities in order to keep your users happy whilst the
I/O takes place. One of the down sides IMHO is the performance. Since
Swing does not use the components found in the native windowing system,
there will always be a performance hit. For simple apps. No problem,
a few nested panels, some buttons, some event listeners. Piece of cake.

 

[Joe]

Hello there.

I have 10+ years doing C/C++/Unix development writing
databases, compilers, and network software. I have
a few years of Java experience.

I need to write a GUI application for the fairly recent
versions of Windows (NT, XP, 2000...). Since I'm all about
interoperability, I'm thinking about using Java to do it.
I don't have *any* GUI experience, nor Windows experience.

My worry is that Java Swing isn't ideal for me. Many
developers I've talked to, and website reviews I've read,
say it's slow and overly complex for very simple things.

I'm wondering if that's just old news, and the latest
version of Swing addresses those problems? If not, can
you recommend other alternatives to Swing, that are
reasonably fast and portable?

My project is straight forward. Provide some buttons
for users to query a database, and display the data.
Some of the queries may require the user for specific
dates, amounts, etc. Provide some forms for users to
add data to a database. Later versions, I would like
the data to be displayed on a spreadsheet like table
and to be able to left/right click the cell for futher
drill downs, but that's later versions. My boss wants
a proof of concept, right now that doesn't look
ugly.

I'm thinking about going the VB route, but my Unix
intuition says to stay away. The better solution is to
give the project to a GUI guy.

Anyways, any suggestions would be great. Thanks for
your time!

I'm all for using the right tool for the right job. The terms you've
heard describing Swing, "slow" and "overly-complex" are too vague to be
of any use. The real question is: What is the right language for this
application? From the requirements you've listed, I would say go with
VB. The only reason not to would be if you think interoperability is
going to be an issue at some future (near-future, actually) date.

 

[Thomas G. Marshall]

steve coughed up:

I would say you are talking to idiots, who are so far out of date on
their technical skill , it is sad.

the trick with java is all in the threads, most bad developers try to
do everything in 1 thread, ( usually the graphics thread), so they
end up with shitty ,slow programs. which they then blame on the java.
The idea is to launch multiple threads , so that operations do not
block each other & bog your application down.

......While being exceedingly careful to remain thread-safe. Swing is not
thread safe. Nor are the collection classes (by default). And even with
totally thread safe classes, you can /still/ get yourself into hot water if
you don't synchronize properly.

Java is mighty powerful. But don't go thinking that you can just launch
multiple threads without worry.

 

[Mark Wright]

One joyful day (Wed, 08 Sep 2004 06:08:12 GMT to be precise), "Thomas G.

.....While being exceedingly careful to remain thread-safe. Swing is not
thread safe.

True, but provided all threaded Swing access is done via
EventQueue.invokeLater() you shouldn't have any problems updating a GUI
from threads.

Mark Wright
- (e-mail address removed)

================Today's Thought====================
"In places where books are burned, one day,
people will be burned" - Heinrich Heine, Germany -
100 years later, Hitler proved him right
===================================================

 

[Alex Hunsley]

One joyful day (Wed, 08 Sep 2004 06:08:12 GMT to be precise), "Thomas G.
Marshall" <[email protected]> decided
that the Usenet community would benefit from this remarkable comment:




True, but provided all threaded Swing access is done via
EventQueue.invokeLater() you shouldn't have any problems updating a GUI
from threads.

And conversely, any time consuming activity should be done *off* the GUI
thread.....

 

[Thomas G. Marshall]

Mark Wright coughed up:

One joyful day (Wed, 08 Sep 2004 06:08:12 GMT to be precise), "Thomas
G. Marshall" <[email protected]>
decided that the Usenet community would benefit from this remarkable
comment:


True, but provided all threaded Swing access is done via
EventQueue.invokeLater() you shouldn't have any problems updating a
GUI from threads.

Ah, sure, and very good point for the OP. But that's not what I was
responding do. Steve's post:

Steve:
the trick with java is all in the threads, most bad
developers try to do everything in 1 thread, ( usually
the graphics thread), so they end up with shitty ,slow
programs. which they then blame on the java. The
idea is to launch multiple threads , so that operations
do not block each other & bog your application down.

You, he, and I are correct. But his statement of (Para-Ph) "not doing
everything in the graphics thread" and "launch[ing] multiple threads" needs
a strong thread safety caveat, particularly for the OP who claims to have no
GUI experience.

....[snip]...

 

[Thomas G. Marshall]

Alex Hunsley coughed up:

And conversely, any time consuming activity should be done *off* the
GUI thread.....

You bet! Just for the record, I don't Mark wasn't saying otherwise---he was
responding to my caveat.

 

[Laurens]

I need to write a GUI application for the fairly recent
versions of Windows (NT, XP, 2000...). Since I'm all about
interoperability, I'm thinking about using Java to do it.
I don't have *any* GUI experience, nor Windows experience.

My worry is that Java Swing isn't ideal for me. Many
developers I've talked to, and website reviews I've read,
say it's slow and overly complex for very simple things.

I've worked with Swing for years, but have given up on it eventually.
The performance in Java 1.4+ is acceptable and the JGoodies L&Fs improve
the appearance immensely, but Swing apps still feel out-of-place. I
don't agree with the notion that blocking the event thread is what makes
Swing apps unresponsive. Blocking the event thread (or queue) will
freeze any UI, no matter whether your use C++, Delphi or Java. Swing is
simply more sluggish because it's layered on top of the native UI. It
does not hook into the OS event queue the way a native UI does.

If cross-platform compatibility isn't much of a concern (Windows-only,
as in your case) then SWT is a good choice. It offers a truly native UI,
while at the same time using *much* less memory. (Even if you leave
performance out of the equation, Swing still uses far too much memory.)

SWT's API is less powerful in the sense that it doesn't offer an MVC
framework like Swing, but at the same it is easier and more
straighforward to work with. Putting this in perspective: in the past,
I've used Delphi and VC++ and neither offered an MVC framework like
Swing, yet I was still able to be productive and deliver applications.

I've released a freeware Windows-only app that uses SWT. You can find
screenshots here: http://home.planet.nl/~fridael/sunrise/tour/

This is a Swing app I made earlier: http://jpluck.sourceforge.net/

Both do roughly the same: convert websites and newsfeeds to Plucker
documents for offline reading on Palm OS handhelds.

Anyway, that's my take on it. There have been so many SWT vs. Swing
flamewars before. No need to start another one.


Regards
-Laurens

 

[Superdude]

Well, whoever you are I just downloaded Sunrise.

 

[hempx]

if you need speed
use SWT
http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html

but swing is very good and complete.

it looks for jgoodies.

it wanted to help more, but I not speak English.

 

[Andrew Thompson]

it wanted to help more, but I not speak English.

You speak English well enough, your
message was easy to understand.

I would hate to read this group if every
person who had to 'translate to English'
stopped posting. The group would become
very boring, and much less useful.

 

[Thomas G. Marshall]

Andrew Thompson coughed up:

You speak English well enough, your
message was easy to understand.

I would hate to read this group if every
person who had to 'translate to English'
stopped posting. The group would become
very boring, and much less useful.

TBPH I can't say that one way or another. I suspect that America alone is
big enough for useful dialogs. Same for the UK, or any sizable country.

But I /do/ want to assure hempx that he did a fine job with his post, and
encourage him and others without English as a native language to post more
often.

Heck, I was born into the English language, and I'm about as bad as they get
...

 

[Thomas G. Marshall]

Laurens coughed up:

I've worked with Swing for years, but have given up on it eventually.
The performance in Java 1.4+ is acceptable and the JGoodies L&Fs
improve the appearance immensely, but Swing apps still feel
out-of-place. I don't agree with the notion that blocking the event
thread is what makes Swing apps unresponsive. Blocking the event
thread (or queue) will freeze any UI, no matter whether your use C++,
Delphi or Java. Swing is simply more sluggish because it's layered on
top of the native UI. It does not hook into the OS event queue the
way a native UI does.

If cross-platform compatibility isn't much of a concern (Windows-only,
as in your case) then SWT is a good choice. It offers a truly native
UI, while at the same time using *much* less memory. (Even if you
leave performance out of the equation, Swing still uses far too much
memory.)

My [wrong?] understanding is that it sets up a peer relationship and uses
native windowing components much like the AWT does.

This means that it oughta work just fine on all platforms, no? Isn't
eclipse running on linux, for example?

Furthermore, I have a question concerning SWT z-order. Z-order was one of
the great undoings of the AWT, since, for example, the mac and the PC layer
their components in opposite order. IIRC, the mac uses last on top, and the
PC uses last underneath, or I may have that backwards.

How does the SWT handle that issue?

....[rip]...

 

[Andrew Thompson]

Heck, I was born into the English language, and I'm about as bad as they get
...

;-) I was almost going to mention earlier,
that I get help from a lot of people with
'foreign sounding' names, and assume they
grew up in America or Britain because
they can correct my grammar, ..only to
discover later that they had never as
much as visited either country.

 

[Laurens]

My [wrong?] understanding is that it sets up a peer relationship and uses
native windowing components much like the AWT does.

You are correct. SWT creates native peers and in that respect it
resembles AWT more than Swing. Discussions always revolve around Swing
vs. SWT, while in fact SWT is really an alternative to AWT.

This means that it oughta work just fine on all platforms, no? Isn't
eclipse running on linux, for example?

Well, I badly worded this in my previous post. What I meant to say is
that SWT works best on Windows. The Linux/GTK implementation, for
instance, has no printing support(or at least not last time I checked).
The Windows implementation obviously gets the highest priority from the
Eclipse team. Arguably, Swing behaves more consistently across platforms
than SWT.

Furthermore, I have a question concerning SWT z-order. Z-order was one of
the great undoings of the AWT, since, for example, the mac and the PC layer
their components in opposite order. IIRC, the mac uses last on top, and the
PC uses last underneath, or I may have that backwards.

How does the SWT handle that issue?

Well, if you mean 3D layers then I don't know the answer. SWT does have
a "z-order" concept but that refers to the order in which controls are
laid out in a GridLayout.


Regards
-Laurens

 

[Tor Iver Wilhelmsen]

Swing is simply more sluggish because it's layered on top of the
native UI. It does not hook into the OS event queue the way a native
UI does.

Swing components are _painted_ on top of native components. But the
system event model is the same in Swing as in AWT. What Swing has
extra are model events.

And since 98% of Java code is compiled into native code at runtime
anyway, it's not the "written in Java" aspect of Swing that slows it
down, but rather the amount of events created and sent back and forth.
Experienced Swing programmers reduce this by e.g. unregistering
components with the ToolTipManager.

Windows-only

That's the reason I avoid SWT: It only runs on whatever platform SWT
has been ported to, while the AWT underlying Swing will simply be
there in J2SE.

 

[michael]

Swing components are _painted_ on top of native components. But the
system event model is the same in Swing as in AWT. What Swing has
extra are model events.

And since 98% of Java code is compiled into native code at runtime
anyway, it's not the "written in Java" aspect of Swing that slows it
down, but rather the amount of events created and sent back and forth.
Experienced Swing programmers reduce this by e.g. unregistering
components with the ToolTipManager.


That's the reason I avoid SWT: It only runs on whatever platform SWT
has been ported to, while the AWT underlying Swing will simply be
there in J2SE.

how about an HTML GUI interface ? its fast , easy and reliable.

thanks
Michael

 

[Thomas G. Marshall]

Laurens coughed up:

My [wrong?] understanding is that it sets up a peer relationship and
uses native windowing components much like the AWT does.

You are correct. SWT creates native peers and in that respect it
resembles AWT more than Swing. Discussions always revolve around Swing
vs. SWT, while in fact SWT is really an alternative to AWT.

This means that it oughta work just fine on all platforms, no? Isn't
eclipse running on linux, for example?

Well, I badly worded this in my previous post. What I meant to say is
that SWT works best on Windows. The Linux/GTK implementation, for
instance, has no printing support(or at least not last time I
checked). The Windows implementation obviously gets the highest
priority from the Eclipse team. Arguably, Swing behaves more
consistently across platforms than SWT.

Furthermore, I have a question concerning SWT z-order. Z-order was
one of the great undoings of the AWT, since, for example, the mac
and the PC layer their components in opposite order. IIRC, the mac
uses last on top, and the PC uses last underneath, or I may have
that backwards.

How does the SWT handle that issue?

Well, if you mean 3D layers then I don't know the answer.

(go fixed width font)

No, if you have widget1 and then "place" widget2 (in that order), are you
guaranteed the following on all platforms?

+----------------+
| |
| 1 |
| |
| +-------+------+
| | |
| | |
| | |
+--------+ |
| 2 |
| |
| |
+--------------+

Or do you get the following on some, like the mac:

+----------------+
| |
| 1 |
| |
| +------+
| | |
| | |
| | |
+--------+-------+ |
| 2 |
| |
| |
+--------------+