how are Java GUI apps being used these days?

[Digital Puer]

Where are Java GUI applications being used currently? Since I've never
seen shrink-wrapped Java software, I would think GUIs are used for
in-house software or perhaps horizontal (business-to-business,
as opposed to business-to-mass market consumer) markets? Any insight?

 

[Christophe Vanfleteren]

Where are Java GUI applications being used currently? Since I've never
seen shrink-wrapped Java software, I would think GUIs are used for
in-house software or perhaps horizontal (business-to-business,
as opposed to business-to-mass market consumer) markets? Any insight?

http://java.sun.com/products/jfc/tsc/sightings/

 

[Josef Garvi]

Where are Java GUI applications being used currently? Since I've never
seen shrink-wrapped Java software, I would think GUIs are used for
in-house software or perhaps horizontal (business-to-business,
as opposed to business-to-mass market consumer) markets? Any insight?

Open Source projects?
http://freerails.sourceforge.net/

--
Josef Garvi

"Reversing desertification through drought tolerant trees"
http://www.eden-foundation.org/

new income - better environment - more food - less poverty

 

[chris]

Where are Java GUI applications being used currently? Since I've never
seen shrink-wrapped Java software,

How do you know this?

 

[Michael Borgwardt]

How do you know this?

Ever heard of something called "memory"?

 

[Mark Preston]

How do you know this?

Its called "making a wild assumption". He / She almost certainly has and
equally certainly wouldn't recognise them if they hit him / her on the
head with a bat...

 

[Eric Sosman]

Its called "making a wild assumption". He / She almost certainly has and
equally certainly wouldn't recognise them if they hit him / her on the
head with a bat...

"Puer" is masculine; "puella" is feminine.

 

[Roedy Green]

Its called "making a wild assumption". He / She almost certainly has and
equally certainly wouldn't recognise them if they hit him / her on the
head with a bat...

For example if you compile your code with Jet, out the end comes a
single *.exe file that looks for all the world like a C++ program.

Unless you started studying the exe with a hex viewer or if you
recognised somebody's LAF, you would not know it was Java.

 

[Mark Preston]

"Puer" is masculine; "puella" is feminine.

Not at all suprised - Latin was a compulsory subject at my grammar
school until it was realised how dreadfully bad I was at it and how much
of my time (and staff time) was being wasted trying to teach me to do
any better.

 

[Tim Ward]

Unless you started studying the exe with a hex viewer or if you
recognised somebody's LAF, you would not know it was Java.

Changing the size of a window and spotting how the window's contents don't
update properly until you release the mouse button can be a bit of a
giveaway.

So can things like waiting several minutes for the piece of window under a
menu to be repainted after the menu is removed, and lots of other similar
things indicating that non-native controls are being used (tables that don't
sort, anyone?). Admittedly applications using non-native controls aren't
necessarily Java (some badly ported Unix applications written in C to a
"portable" GUI library are even worse at this, indeed vastly worse) but
learning to tell which is which isn't a terribly big deal.

 

[Bent C Dalager]

So can things like waiting several minutes for the piece of window under a
menu to be repainted after the menu is removed, and lots of other similar
things indicating that non-native controls are being used (tables that don't
sort, anyone?). Admittedly applications using non-native controls aren't
necessarily Java (some badly ported Unix applications written in C to a
"portable" GUI library are even worse at this, indeed vastly worse) but
learning to tell which is which isn't a terribly big deal.

It sounds more like learning the skill of "spotting shoddy software
and calling it Java". I've seen enough horrid MFC-based software to
know that software quality is primarily a result of good or bad
programmers, not good or bad APIs.

Cheers
Bent D

 

[Tim Ward]

It sounds more like learning the skill of "spotting shoddy software
and calling it Java".

No dear, I can do better than that, I've been in this game since long before
either MFC or Java were invented. Silly insults when you don't know who
you're talking to are not helpful to anyone.

 

[Chris Uppal]

It sounds more like learning the skill of "spotting shoddy software
and calling it Java". I've seen enough horrid MFC-based software to
know that software quality is primarily a result of good or bad
programmers, not good or bad APIs.

You are confusing two levels. I agree that bad UI design is bad UI design, no
matter what it's written in. But a UI design, good or bad, will also reflect
the implementation technology, and it's /that/ that "marks" Java/Swing
applications. On a Windows platform, Java/Swing applications stand out as
non-standard in many ways that are easy to recognise, and either very hard or
impossible[*] to avoid.

Put it the other way around: it would be virtually impossible for a programmer
using the standard Windows toolkits and APIs to create an application that
fooled people into thinking it was written in Java/Swing. Oh, there are a few
things that would be easy enough to fake, like putting a long delay into the
startup, making windows fail to refresh during resizing, using the wrong fonts,
and so on, but gettig the details right would involve ditching the Windows
components entirely and re-writing Swing in C++ (or whatever).

Of course the picture may be different for non-Windows platforms, or for non
Swing UIs (I'm not sure what Eclipse does look like, but it sure don't look
like Swing ;-)

-- chris


[*] /I/ don't know how to do it, and I've never seen an application that I knew
(independently) to be written in Java that managed it. I know that doesn't
imply that there are no applications that /do/ manage it without my realising
it.

 

[Guest]

Its called "making a wild assumption". He / She almost certainly has and
equally certainly wouldn't recognise them if they hit him / her on the
head with a bat...

Swing's enormous memory consumption, not-quite-right emulation of the
Windows look & feel, and GC pauses are always dead giveaways to me.

 

[Roedy Green]

Changing the size of a window and spotting how the window's contents don't
update properly until you release the mouse button can be a bit of a
giveaway.

Those are problems with your JVM. I don't think you have used Jet. It
does not use the Sun JVM. Your app is fully standalone, natively
compiled, and highly optimised. I works the same way a C++ compiler
does. Apps come as a single XXX.exe perhaps with some *.dlls.


Try it. There isa free version for personal use. See
http://mindprod.com/jgloss/jet.html

 

[Roedy Green]

Swing's enormous memory consumption, not-quite-right emulation of the
Windows look & feel, and GC pauses are always dead giveaways to me.

Again, those are problems with your JVM. A modern generational
garbage collector does not have long pauses.

You are repeatedly confusing problems with the language with problems
with your tools.

 

[Guest]

Again, those are problems with your JVM. A modern generational
garbage collector does not have long pauses.

Swing consumes massive amounts of memory under the (at least) half dozen
JVM's I've used, including the most recent releases for Windows (from Sun),
HP-UX, AIX, and Solaris. I will be happy to eat crow if you can demonstrate
even one JVM that runs a real Swing application that does not immediately
gobble down megabytes of memory in the double digits.

I never said the GC pauses were long. But they are noticeable. For them
to be noticeable at all in GUI applications is dissapointing. The latest
Sun JVM for Windows has a Swing demo program which exhibits periodic and
noticeable GC delays on my developer level hardware which is less than 6
months old.

The not-quite-right emulation of the Windows look & feel is not a problem
that is solveable given the ever-changing nature of the Windows look & feel.

If you're claiming there are JVM's that don't exhibit any of these problems
please point those JVM's out to me.

You are repeatedly confusing problems with the language with problems
with your tools.

Surely you are mistaking me for another poster. I did not repeatedly
claim anything (I only made a single post to which you responded) and
I did not suggest these issues were language problems. Please be more
careful in your responses.

Before you ignite your flamethrower, you should know I use a variety of
Java programs (some of them aren't Swing-based, such as Eclipse, and some
of them ARE Swing-based, such as jEdit) and find them highly usable and
enjoy them a great deal. I'm not a random Java/Swing basher. My response
was aimed squarely at the person to whom I responded who said (paraphrased)
that you "can't tell the difference between a native GUI app and Swing-based
GUI app".

While I like and use Java and Swing-based applications daily, his or her
comment is clearly exaggerated - and dare I say it - sounded like a rather
religious response.

All that being said, I think Sun took the wrong approach with Swing, and
should have attempted to leverage native widgets as much as possible, much
like very successful libraries such as wxWidgets.

 

[Roedy Green]

Swing consumes massive amounts of memory under the (at least) half dozen
JVM's I've used, including the most recent releases for Windows (from Sun),
HP-UX, AIX, and Solaris. I will be happy to eat crow if you can demonstrate
even one JVM that runs a real Swing application that does not immediately
gobble down megabytes of memory in the double digits.

that is also true of any other complex windowing system. It is just
that you notice it more when the library runs in your own address
space.

Have you checked the price of RAM lately? This is not the issue it was
even 5 years ago.

Why don't you TRY Jet and see just how small things can get.

See http://mindprod.com/jgloss/jet.html

Here are some examples:

command line program (the replicator sender portion): jar=64,585,
exe=289,280

awt program (Amazon book refer): jar= 64,585, exe=93,184

swing program ( Cyberview Plus multi-security cameras): jar= 502,767,
exe=605,696

 

[Roedy Green]

If you're claiming there are JVM's that don't exhibit any of these problems
please point those JVM's out to me.

Even if there were no decent JVMs or native compilers you still are
incorrect is saying the LANGUAGE Java has such and so problem. It does
not. The JVMs do.

You could only say that if you could show that there is no possible
way to write an efficient JVM because of something about the design of
the language.

You have not done that. You sound like JTK's little brother.

Try out Jet. Check out JDK 1.5. It might blast some of the cobwebs
out of your mind about how Java HAS to be.

See http://mindprod.com/jgloss/jet.html

 

[Tim Ward]

Try out Jet. Check out JDK 1.5.

Very expensive. Changing the platform like this means the products have to
go through an entire system test cycle from scratch, regression testing
won't hack it. There isn't the commercial driver for doing this work.

(Just to pick a simple example: We *know* that some aspects of socket
handling more-or-less work in 1.4.1, well enough for us to live with anyway,
we *know* they're broken to the point of unusability in at least two other
versions, we can live without the expense of repeating all the testing
particularly as these problems are intermittent time-dependent things.)