Why is Java so UNAMBITIOUS?

[me]

Why isn't SWT and JFACE included in Suns JRE? I would love to build
desktop apps in Java, but AWT and SWING just isn't good enough.
Using 1.4.2 skins with SWING is not the answer, I wan't something
thats fast and responsive and has a look and feel that integrates
completely with the underlying platform. Deploying SWT as a
separate package is a pain. Either I ask the user to install the
platform binds himself or I build a platform dependent installer
myself - both solutions too difficult and not architecture agnostic,
it will never make it mainsteam.

And why isn't Suns JRE distributed and installed by default on
platforms such as RedHat and Suse? I am sure all involved parties would
benefit from that. Asking ppl to install Java on such platforms and
adding java to the path is only for programmers. I wan't mainstream
Java.

Dont give me that "use webstart", some other specialized solution or
"do it yourself" - i am talking about Java as mainstream.

 

[michel]

Why isn't SWT and JFACE included in Suns JRE? I would love to build
desktop apps in Java, but AWT and SWING just isn't good enough.
Using 1.4.2 skins with SWING is not the answer, I wan't something
thats fast and responsive and has a look and feel that integrates
completely with the underlying platform. Deploying SWT as a
separate package is a pain. Either I ask the user to install the
platform binds himself or I build a platform dependent installer
myself - both solutions too difficult and not architecture agnostic,
it will never make it mainsteam.

I found SWING to be a step backwards. Harder to use than AWT, thus not a
solution.

 

[Bent C Dalager]

I found SWING to be a step backwards. Harder to use than AWT, thus not a
solution.

I find jumbo jets to be a step backwards. Harder to use than my feet,
thus not a solution

Cheers
Bent D

 

[Tor Iver Wilhelmsen]

Why isn't SWT and JFACE included in Suns JRE?

Because Swing is there. SWT is an IBM-backed intermediate solution
somewhere between AWT and Swing, requiring native support. If Sun ever
accepts SWT into the JRE they will need to run QA on SWT for every
platform they supply a JRE on, and require that licensees also support
it.

Also, SWT is possibly released under a license that Sun doen't want to
apply to any part of the JRE.

I would love to build desktop apps in Java, but AWT and SWING just
isn't good enough.

Why not? I've been using Swing for years, and see few problems with
it, and certainly no reason to switch to a totally different widget
set.

Using 1.4.2 skins with SWING is not the answer, I wan't something
thats fast and responsive and has a look and feel that integrates
completely with the underlying platform.

AWT does, but has few components available.

And why isn't Suns JRE distributed and installed by default on
platforms such as RedHat and Suse?

You will have to ask them.

 

[Roedy Green]

Why isn't SWT and JFACE included in Suns JRE?

Because SWT is IBM's offering. The company that produces it wants you
to get it direct from them so that you will read their website, get
the latest, and acknowledge them as benefactor.

 

[Roedy Green]

And why isn't Suns JRE distributed and installed by default on
platforms such as RedHat and Suse?

The problem with letting anyone else distribute your stuff is that
they won't necessarily be as vigilant as you about offering only the
latest and greatest. It becomes harder to propagate a fix. It becomes
impossible to retract a booboo.

It becomes more work for you to monitor them all and make sure they
are all offering the latest stuff unmodified.

I write little utilities. Obsolete copies of them over 10 years old
are still floating around the web. Sometimes I get letters from
people who have finally tracked me down.

What Sun might do instead is distribute a digitally signed file, that
on installation, updates itself with any mandatory fixes from Sun's
site. Then Sun could safely allow obsolete copies to float around. In
the worst case they would trigger a complete new download when used.


see http://mindprod.com/projbulkfiledistributor.html
and http://mindprod.com/projautoupdate.html

 

[Roedy Green]

And why isn't Suns JRE distributed and installed by default on
platforms such as RedHat and Suse?

It may be that Sun is really only interested in reaching the customers
who are relatively affluent. The rest are just a nuisance. For people
with high speed Internet access, installing the JRE or JVM is not a
problem. You can do it with a couple of clicks.

If the wanted to spread Java, you would think at least they would send
copies of the new downloads each month to all the user groups and tell
them to burn copies for their members.

 

[Dushyanth Inguva]

Yeah. I do agree.
Not only in the GUI field, java API lacks in virtually every field.
There is no 3 step process to achieve things.
Examples of few of the shortcommings are:
1. Lack of a ThreadPool, ConnectionPool, ObjectPool (yeah J2EE
supports, but what about JDK? - I'm not talking about Apache's
solutions here. Apache's projects are a boon to JavaMan kind. But im
talking of J2SDK)
2. The mouse wheel support was introduced ages after it came into the
market. Wakeup SUN !!!
3. Why isn't there a nice deployment mechanism? Download and run
(without installing web start or anything.) I mean you can download an
exe from a website and double click to run it. You can download a jar
and do what !!! (Yeah the manifest file MainClass "feature" is
present. But show me how many jar files use it)
(SUN - I can code it for you. FREE of charge)
4. VERY ANNOYING ONE: When opening a big applet under java plugin, it
shows an ugly progress bar showing how much each class has been
loaded. Does the end user really care which class is getting loaded?
Compare this to Flash's Wait icons. The plugin can atleast show a
JAVA. LOADING... icon or something.

The list could go on and on. All around the world, java programmers
have been solving problems, and solving them again and again
Thanks to Apache, Sourceforge and others we are not completely groping
in the dark.

One of the reason people give for the "lack of features" in java is
that JCP takes time. But do you actually need a JCP to put a
threadpool in J2SDK ?

Even after all this, i am a java fanatic and would remain that way.
But it would be great if SUN actually makes java more usable (Nope.
I'm not talking about J2SDK 1.5 )

Dushyanth Inguva
Java Developer

 

[Bent C Dalager]

3. Why isn't there a nice deployment mechanism? Download and run
(without installing web start or anything.) I mean you can download an
exe from a website and double click to run it. You can download a jar
and do what !!! (Yeah the manifest file MainClass "feature" is
present. But show me how many jar files use it)
(SUN - I can code it for you. FREE of charge)

Web Start is built into the 1.4.1 JRE. They have a bit of script magic
you can put into your HTML that takes care of automatically
downloading the JRE if the user doesn't already have it.

You can hardly blame Sun for Java developers not bothering to make
their applications user friendly either. MainClass is so trivial to
implement, I fail to see how this could have been done significantly
easier.

Cheers
Bent D

 

[Roedy Green]

1. Lack of a ThreadPool, ConnectionPool, ObjectPool (yeah J2EE
supports, but what about JDK? - I'm not talking about Apache's
solutions here. Apache's projects are a boon to JavaMan kind. But im
talking of J2SDK)

If these tools are freely available, why is it important to you to
have them in the JDK? Threadpooling is a server function, not
something you need to burden client users of Java downloading.

 

[Roedy Green]

4. VERY ANNOYING ONE: When opening a big applet under java plugin, it
shows an ugly progress bar showing how much each class has been
loaded. Does the end user really care which class is getting loaded?
Compare this to Flash's Wait icons. The plugin can atleast show a
JAVA. LOADING... icon or something.

I have not see this. What JVM are you using?

 

[Harald Hein]

3. Why isn't there a nice deployment mechanism? Download and run
(without installing web start or anything.) I mean you can
download an exe from a website and double click to run it. You can
download a jar and do what !!! (Yeah the manifest file MainClass
"feature" is present. But show me how many jar files use it)
(SUN - I can code it for you. FREE of charge)

This is the core of the latest Sun vs. Microsoft legal battle. You
need to ship that feature pre-installed on a platform. Microsoft
just does not want to do it. That feature btw exists. It is a JRE with
web start.

One of the reason people give for the "lack of features" in java
is that JCP takes time.

The JCP is designed for big fat corporations. Sun claimes the "C"
stands for community, but that is a joke. If you pay enough, you get
the most fucked-up API into Java, while simple things are not fixed for
ages.

 

[me]

Why isn't SWT and JFACE included in Suns JRE?

Because Swing is there. SWT is an IBM-backed intermediate solution
somewhere between AWT and Swing, requiring native support. If Sun ever
accepts SWT into the JRE they will need to run QA on SWT for every
platform they supply a JRE on, and require that licensees also support
it.
Also, SWT is possibly released under a license that Sun doen't want to
apply to any part of the JRE.

SWT is currently open source, so IBM has already shown that they are
not complete control freaks about this project. Thats one of the
reasons I suggest that SWT and JFACE should be included in Suns runtime.
Obviously Sun and IBM would have to cooperate, and it would be a drastic
thing for them to do, but if they only sit there tending their own
interests, then Java will never go beyond servers and microdevices. What
I am suggesting is that companies like Sun and IBM should be more
ambitious about Java! Getting Java to a broader audience would boost
both their bussinesses.

And yes SWT has a native part just like AWT and SWING. Currently SWT
supports windows, gtk2, motif, os x and qnx - adding whatever platforms
Sun support should be within reach.

Why not? I've been using Swing for years, and see few problems with
it, and certainly no reason to switch to a totally different widget
set.

But even if you like SWING you must surely have considered why so few
ppl build standalone desktop apps based on SWING? If AWT or SWING had
any appeal to mainstream companies and programmers then Java on the
desktop would have happened long ago, but it dosen't and Java on the
desktop is never going to happen with AWT and SWING as the main offer.
Sun and IBM need to do something drastic.

AWT does, but has few components available.

...and while AWT in some respects is based on native widgets, many
of them (for instance TextArea and TextField) flicker, are slow, take
no clue from the system on default fonts, sizes, colours ect. and
are generally full of bugs. So in other words AWT is not gonna cut
it either.

 

[me]

Because SWT is IBM's offering. The company that produces it wants you
to get it direct from them so that you will read their website, get
the latest, and acknowledge them as benefactor.

and thats why I wan't them to take a broader view of Java and show
a little more ambition.

 

[me]

The problem with letting anyone else distribute your stuff is that
they won't necessarily be as vigilant as you about offering only the
latest and greatest. It becomes harder to propagate a fix. It becomes
impossible to retract a booboo.

so rather have ppl not use Java than risk they have a version with a bug?

It becomes more work for you to monitor them all and make sure they
are all offering the latest stuff unmodified.

Offering the latest stuff is not nescessary. Getting Java out the door
is more important, than users not having Java at all. Besides, Sun dont
have to offer everybody the permit to incorparate Java in their software.
Only the big platforms need it.

I write little utilities. Obsolete copies of them over 10 years old
are still floating around the web. Sometimes I get letters from
people who have finally tracked me down.

What Sun might do instead is distribute a digitally signed file, that
on installation, updates itself with any mandatory fixes from Sun's
site. Then Sun could safely allow obsolete copies to float around. In
the worst case they would trigger a complete new download when used.

But why build such a mechanism for only one piece of software? The
platforms I mention already have generic mechanisms for alerting the
user if serious bugfixes exist, and can download and install the fixes
in a way that mom and dad can use it. Most platforms already categorize
fixes as Urgent Security, Suggested.. etc.

 

[Nick]

Hi.

With all due respect...

[blah blah waffle]

But even if you like SWING you must surely have considered why so few
ppl build standalone desktop apps based on SWING? If AWT or SWING had
any appeal to mainstream companies and programmers then Java on the
desktop would have happened long ago, but it dosen't and Java on the
desktop is never going to happen with AWT and SWING as the main offer.
Sun and IBM need to do something drastic.

I couldn't disagree with you more. Many developers including myself are
using Swing. Although thin client is trendy a swing client is far more
efficient in terms of development, maintenance and final performance. Only
changes in data are downloaded and even with high bandwidth network
access it is still the most efficient. The internet browser craze is still
alive
and people are investing huge amounts reinventing and developing half
decent MVC solutions using STRUTS, for example. Layer on top of
layer, XML parsing, generating, and in the end it is a much slower
approach.

Anyway, just my 4 cents worth.

And I am awaiting a faster alternative to Swing. And if any emerges I
will immediately update my ui abstraction layer to use this new, better
library and all the better, all my programs will run faster and look better.

 

[Tor Iver Wilhelmsen]

And yes SWT has a native part just like AWT and SWING. Currently SWT
supports windows, gtk2, motif, os x and qnx - adding whatever platforms
Sun support should be within reach.

Swing doesn't itself have a native part, but uses the top-level native
components of AWT and the applet API. Caveat: JFileChooser might do
some tricks under Windows, I am not sure.

But even if you like SWING you must surely have considered why so few
ppl build standalone desktop apps based on SWING?

No, I assume a lot do - just not for "retail". Based on JavaOne
feedback there is a lot of development using Swing GUI, but most of it
is for "non-mainstream" customers. Cases in point: JBuilder and
Together Control Center from Borland.

 

[Jim Sculley]

me wrote:

And yes SWT has a native part just like AWT and SWING. Currently SWT
supports windows, gtk2, motif, os x and qnx - adding whatever platforms
Sun support should be within reach.

The obvious problem being that there are different levels of 'support'
for Windows GTK, Motif, OSX and QNX. For example, where is the browser
help component for Linux?

But even if you like SWING you must surely have considered why so few
ppl build standalone desktop apps based on SWING?

Not really. Why should I care what other people are or are not doing
with Swing? It does what *I* want it to do, and that's all that matters
to me.

If AWT or SWING had
any appeal to mainstream companies and programmers then Java on the
desktop would have happened long ago,

Since 95% of desktops run an OS fom a company that has been decidely
hostile toward Java, I think you are being overly optimistic about what
would have happened if more companies fully embraced Swing.

but it dosen't and Java on the
desktop is never going to happen with AWT and SWING as the main offer.

I'm running a variety of Swing apps. Java is already on the desktop.
Anyone willing to spend some time understanding the architecture of
Swing can create just about any application you can imagine.

...and while AWT in some respects is based on native widgets, many
of them (for instance TextArea and TextField) flicker, are slow, take
no clue from the system on default fonts, sizes, colours ect. and
are generally full of bugs. So in other words AWT is not gonna cut
it either.

You apparently haven't run many SWT apps on Linux. Plenty of slowness,
flicker, and cluelessness to be found. No widget library is immune from
performance problems or bad coding. SWT is as flawed as Swing in many
respects.

In the end it is a matter of personal preference. I prefer a widget
toolkit that gives me as much or as little control ovber every aspect of
the UI as possible. SWT doesn't do this. Swing does.

Jim S.

 

[tk]

I found SWING to be a step backwards. Harder to use than AWT, thus not a

solution.

Swing is a perfect solution for the product I'm working on. Swing can
definitely be overwhelming due to the
the nature of its extensive design-pattern use and its plethoria of
classes/methods.

You're right in that there's an awful lot to learn with it before you can
start getting some useful applications up
and running.

Swing promotes much better performance with the later releases of the SDK.

If you're looking to throw complex GUI applications up quickly, Swing is not
the answer. You do have to spend
alot of time in the trenches getting familiar with the hundreds of classes
and how they interact within the MVC
architecture.

However, the alternative frameworks in different languages (MFC, etc..) is
even worse.

 

[tk]

Why isn't SWT and JFACE included in Suns JRE? I would love to build
desktop apps in Java, but AWT and SWING just isn't good enough.
Using 1.4.2 skins with SWING is not the answer, I wan't something
thats fast and responsive and has a look and feel that integrates
thats fast and responsive and has a look and feel that integrates
completely with the underlying platform. Deploying SWT as a

It does integrate with the underlying platform thru the peer classes. And
for those special platform-specific
cases, use JNI. We have no problems porting our Swing apps to Windows
2000, XP and Solaris.

I think the "Tiger" project underway is going to be addressing many of these
performance/resource issues.
It may still be the saving grace for Swing.