Has Sun Given Up on the Desktop?

[Lori Piquet]

Is Swing as bad as they say? Do you avoid writing desktop apps with Swing
because of real or perceived performance issues? Which is it: real or
perceived? Do you think Sun is remiss in its support of Java on the desktop?

(Link to come shortly.)

Lori Piquet
Editor-in-chief
DevX

[Uwe W. Radu]

>Is Swing as bad as they say?
> Which is it: real or perceived?

Pretty much. Just check out some of the flagship apps, such as Borland's
JBuilder, which pushes Swing about as far as it will go. They're very sluggish
applications, both in terms of overall response, as well as little GUI things,
such as mousing over menus or toolbars and feeling like trying to run in
honey. The GUI is not quite crisp and keeping up with experienced users.

The other main problem is startup lag. Java apps have a lot of startup overhead,
including the constant time to load the JVM, which becomes particularly noticeable
with small to medium-sized apps. Let's face it, such apps are the bread and
butter of corporate development: tons of custom programs to massage data
or display odd reports to this or that manager or department. These apps
might be run so frequently that having any significant lag can become very
annoying after a while.

[Mike Mitchell]

On 11 Sep 2002 18:18:30 -0700, "Uwe W. Radu" <uradu@cdc.net> wrote:

>The other main problem is startup lag. Java apps have a lot of startup overhead,
>including the constant time to load the JVM, which becomes particularly noticeable
>with small to medium-sized apps. Let's face it, such apps are the bread and
>butter of corporate development: tons of custom programs to massage data
>or display odd reports to this or that manager or department. These apps
>might be run so frequently that having any significant lag can become very
>annoying after a while.

Can't the exact same criticism be levelled at .Net also? Surely the
CLR is very similar to the JVM? And I've heard elsewhere that VB.Net
apps are very lethargic compared with natively-compiled VB6 ones. The
IDE as well.

MM

[Eddie Burdak]

Mike,

Mike Mitchell wrote:
> Can't the exact same criticism be levelled at .Net also? Surely the
> CLR is very similar to the JVM? And I've heard elsewhere that VB.Net
> apps are very lethargic compared with natively-compiled VB6 ones.
The
> IDE as well.

From the little I've played I'd say there about as bad/good as each
other

Eddie

[Rob Abbe]

Sun has not given up on the desktop. The performance in 1.4.1 is not bad
at all. It is more than adequate for business applications. Webstart is
also very nice and an indicator that Sun still wants a place on the desktop.

"Lori Piquet" <lpiquet@devx.com> wrote:
>Is Swing as bad as they say? Do you avoid writing desktop apps with Swing
>because of real or perceived performance issues? Which is it: real or
>perceived? Do you think Sun is remiss in its support of Java on the desktop?
>
>(Link to come shortly.)
>
>Lori Piquet
>Editor-in-chief
>DevX
>
>

[drhender]

Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
>On 11 Sep 2002 18:18:30 -0700, "Uwe W. Radu" <uradu@cdc.net> wrote:
>Can't the exact same criticism be levelled at .Net also? Surely the
>CLR is very similar to the JVM? And I've heard elsewhere that VB.Net
>apps are very lethargic compared with natively-compiled VB6 ones. The
>IDE as well.

You are speaking without knowledge, my friend. It is true that the CLR parallels
the JVM, but you make a couple of incorrect assumptions. First of all, you
imply that the starting of the JVM-like beast is where the performance hit
is taken. Not so; the real performance hit is taken when the JIT compiler
converts the non-os specific code (.class or .jar files on Java and the .ism
files under .Net) to OS-specific binary-code. Your second assumption is
that like Java, the CLR must do this every time you start the application.
This is not the case. Unlike Java, the output of the JIT compiler can be
saved to disk so that it doesn't have to be jit'ed every time the application
is started. (Look up NGEN on Microsoft's MSDN site for details.) The result
is that an application's startup is drastically reduced.

One might argue that this is no longer write-once, run-anywhere, but since
the CLR has the option of returning to the .ism files to jit the code. Besides,
I don't know if you've noticed, but Redmond doesn't seem to be all that interested
in the write-once, run-anywhere concept anyway. Why would they be? Afterall
they are more interested in selling Windows that allowing a developer to
write software that runs on other platforms as well as it does on Windows.
Doing so would provide an exit from the Windows monopoly on the desktop
that they currently enjoy.

[Lori Piquet]

Sorry. I forgot to post the link last night.
Here it is (but I'm glad the conversation has taken off anyway):
http://www.devx.com/free/hotlinks/20...te091102-1.asp

Lori Piquet

"Lori Piquet" <lpiquet@devx.com> wrote in message
news:3d7f8ad2$1@10.1.10.29...
> Is Swing as bad as they say? Do you avoid writing desktop apps with Swing
> because of real or perceived performance issues? Which is it: real or
> perceived? Do you think Sun is remiss in its support of Java on the
desktop?
>
> (Link to come shortly.)
>
> Lori Piquet
> Editor-in-chief
> DevX
>
>

[Marc Latham]

"Lori Piquet" <lpiquet@devx.com> wrote:
>Is Swing as bad as they say? Do you avoid writing desktop apps with Swing
>because of real or perceived performance issues? Which is it: real or
>perceived? Do you think Sun is remiss in its support of Java on the desktop?
>
>(Link to come shortly.)
>
>Lori Piquet
>Editor-in-chief
>DevX
>
>
As a developer and application designer I avoid writing or specing applications
that use Java for 2 reasons 1) the applications run in intrepreted mode and
are as slow as molassas 2) The base of developers writing in Java is so small
that it is hard to get good developers at a reasonable cost.

As a user I avoid using java based apps because they are so slow, their open
time on the same hardware/ os is twice or more that of native apps. The
oracle GUI database administration tools are a perfect example. Their tools
before java were fast after java I have switched to other tools to access
my oracle databases because I don't have time to wait on them to run.

Also as a developer I don't want to ship my source code in an open format,
I spend 2 years writing something and then have some big corporation steal
it and use it no thanks. The best way to prevent code theft is not to expose
the code. Also from a supportability issue if the users can open the code
and modify it how the heck am I supposed to support them when the code they
are running may not even match the original distribution.

[Uwe W. Radu]

> One might argue that this is no longer write-once, run-anywhere

Only in the sense that it's not that exact same code that actually hits the
CPU when executing. But then again, why is that important? The spirit of
write-once-run-anywhere is portability, and that particular cat can be skinned
more than one way. I actually like the (optional) approach taken by .NET
of compile-at-install: you only compile the code once to native at installation
time, and from then on use the native code. The critical thing then is to
provide the class libraries and compiler on all target platforms, which is
not all that different from providing a VM on all those platforms.

[Uwe W. Radu]

> Surely the CLR is very similar to the JVM?

No, not really. There is no VM in .NET (though planned, I hear), only a JIT
compiler. Secondly, .NET apps can be compiled two ways, either at run-time,
or at installation time. I'd say common usage once .NET hits the masses will
probably favor the second approach for obvious performance reasons.

> And I've heard elsewhere that VB.Net apps are very
> lethargic compared with natively-compiled VB6 ones.

Not "very" but still noticeably, especially at first run. But they're still
more responsive than comparable Swing apps.

> The IDE as well.

That is completely immaterial since the IDE isn't .NET itself (to my knowledge),
unlike JBuilder, which is all Java. VS.NET is simply a beast and probably
still not terribly optimized; they probably just rushed it out the door to
have a delivery.

[Bruce Attah]

"Uwe W. Radu" <uradu@cdc.net> wrote:
>
>I actually like the (optional) approach taken by .NET
>of compile-at-install: you only compile the code once to native at >installation
time, and from then on use the native code. The critical thing >then is to
provide the class libraries and compiler on all target platforms, >which
is not all that different from providing a VM on all those platforms.

I agree. It has always seemed obvious to me that this is the way Java should
be distributed, but Sun doesn't seem to like the idea, for some reason. Back
in the dark ages, Pascal was originally succesful because it was distributed
as a "P-code" compiler and a P-code virtual machine. Great portability was
a big attraction, but then it gained a reputation for slowness, and C became
more popular. Sun should learn from history. Portability at the source code/intermediate
code level, coupled with speed on actual delivery is the way to win.

What's more, if they think about it, the Java-to-native compiler-installer
could have a few bells and whistles attached that would attract developers.
What if the compiler implemented protocols to check the byte-code somehow
(the signature concept could be fed a course of steroids, since installation
is a relatively infrequent thing) to ensure that it was what it said it was,
or check that the user was suitably registered or otherwise qualified before
installing anything? Users and developers would both love this.

[Uwe W. Radu]

> Portability at the source code/intermediate code level,
> coupled with speed on actual delivery is the way to win.

Actually, I like the Delphi/Kylix type of portability even more, but that's
another story <g>. There's something to not being sandboxed that just appeals
to me. In the absence of that, the .NET approach is the next best thing.
So far I like most things about .NET, especially since it's been spawned
by a veteran Pascal/Delphi guy. But let's not forget that we're still at
the "bait" stage of Microsoft's two-pronged strategy, when they still have
to look good. It's the "switch" that I'm afraid of. Hopefully Mono on Linux
will provide a usable independent fork by then.

[MarkN]

"Lori Piquet" <lpiquet@devx.com> wrote:
>Is Swing as bad as they say?
No. It is not perfect and could be better. What isn't?

>Do you avoid writing desktop apps with Swing
>because of real or perceived performance issues?
No. I like the fact that I can deploy my app or client on any platform.
It gives my clients and customers choice as to how they spend their money.

>Which is it: real or
>perceived?
Mostly percieved. Some of it is real. But I would say the good out weighs
the bad (Most people complain about unimportant things, things solved or
solved by 3 party tools and things solved by good programming techniques).
If there comes a better Java GUI tool I will use it. SWT might be that
tool (for the apps I do).

>Do you think Sun is remiss in its support of Java on the desktop?
Maybe a little. Those building Java (which is more than Sun) have seemed
(as everyone else has - MS, ...) concentrated more on browser based UIs.
I think they (and everyone else) over estimated the worth and usefulness
and maintainability (...) of browswer based UIs. For example, IBM shipped
WSAD without a built in GUI builder for Swing or SWT. Users had to use VAJ
(or something else) for that. IBM has put shipping WAS 5 on hold till next
month to get WSAD 5 out the door this month. WSAD 5 includes a GUI builder.
Hmmm.

I think the problem here (as evident in your questions) is that Java != Sun.
Java is greater than Sun.

[MarkN]

It kills me when people say Java is slow. Java is being used where speed
is important like the financial arena.

As for the base of Java programmers - Well avoid .Net because the base is
smaller. You under estimate the number of Java programmers. Java programmers
typically are paid more because crappy Java apps are really crappy. Most
good ones can't be whipped out. The same is true for .Net. VB was ok for
whipping out apps. But when it comes time to maintain or modify ... . BTW,
I am being paid as much and more for my MS programming than my Java programming.

As for slow Java apps - try Eclipse 2.0.
The question really is - Is it fast enough? Usually yes. So if you are
concerned with program speed you should be programming in Assembly. You're
not? The tool you are using must be fast enough.

The reason I think Oracle Java UIs aren't that good (actually they really
aren't that bad) is because they don't make money at it, not because they
are done in Java. This is the reason things like printer drivers are so
bad. Don't forget Oracle runs on at least one more platform than SQL Server
and they need to have a UI for each.

As for code theft - use an obfuscator. Don't be fooled into thinking your
code in other languages can't be stolen without some extra effort on your
part. The best deterant to software theft - don't sell it.

As for users changing the code - don't ship the .java files. There are native
compilers for Java too. I don't see the problem here. Linux users can
change the code. It doesn't seem to cause a problem there.


"Marc Latham" <mlatham23@yahoo.com> wrote:
>
>"Lori Piquet" <lpiquet@devx.com> wrote:
>>Is Swing as bad as they say? Do you avoid writing desktop apps with Swing
>>because of real or perceived performance issues? Which is it: real or
>>perceived? Do you think Sun is remiss in its support of Java on the desktop?
>>
>>(Link to come shortly.)
>>
>>Lori Piquet
>>Editor-in-chief
>>DevX
>>
>>
>As a developer and application designer I avoid writing or specing applications
>that use Java for 2 reasons 1) the applications run in intrepreted mode
and
>are as slow as molassas 2) The base of developers writing in Java is so
small
>that it is hard to get good developers at a reasonable cost.
>
>As a user I avoid using java based apps because they are so slow, their
open
>time on the same hardware/ os is twice or more that of native apps. The
>oracle GUI database administration tools are a perfect example. Their tools
>before java were fast after java I have switched to other tools to access
>my oracle databases because I don't have time to wait on them to run.
>
>Also as a developer I don't want to ship my source code in an open format,
>I spend 2 years writing something and then have some big corporation steal
>it and use it no thanks. The best way to prevent code theft is not to expose
>the code. Also from a supportability issue if the users can open the code
>and modify it how the heck am I supposed to support them when the code they
>are running may not even match the original distribution.

[Alexander Jerusalem]

"Marc Latham" <mlatham23@yahoo.com> wrote:
>As a developer and application designer I avoid writing or specing applications
>that use Java for 2 reasons 1) the applications run in intrepreted mode
and
>are as slow as molassas

They run in interpreted mode only if you specifically tell the VM to do so.
By default Java applications are compiled just in time.

>Also as a developer I don't want to ship my source code in an open format,
>I spend 2 years writing something and then have some big corporation steal
>it and use it no thanks. The best way to prevent code theft is not to expose
>the code. Also from a supportability issue if the users can open the code
>and modify it how the heck am I supposed to support them when the code they
>are running may not even match the original distribution.

I'm sorry but I have to ask that: Have you ever in your life written or seen
a Java application? Just to remind you, Java is a compiled language. You
need not ship your source code and you can even obfuscate the byte code so
that it cannot be reengineered.

Regards