On Wed, May 02, 2001 at 10:51:56AM -0500, Joi Ellis wrote:
> On Wed, 2 May 2001, Nathan Meyers wrote:
> 
> > The AWT seemed like a good idea at the time, but it has aged poorly.
> > Even the most careful programmers have a hard time designing an app or
> > applet that looks decent in all environments.  And the two toolkits
> > in this case - the Windows GUI and Motif - are so different that the
> > problem is a nightmare for a Java GUI of any complexity. Add a couple of
> > other problems - the lowest-common-denominator capabilities of the AWT,
> > and the requirement that applet tags specify fixed pixel dimensions -
> > and you see that applet programmers have been hobbled from the beginning.
> > It's not about being lazy, it's about being screwed.
> 
> *laugh*  Oh, now you want to get into applet issues?  I was talking
> basic applications when I was writing before.  I do *all* my work as
> Swing Applications.  I don't touch the non-portable AWT stuff and I don't
> do applets, specifically because they aren't portable.

I'm glad you enjoy that luxury, but it was a discussion of applets that
started this thread. Like it or not (and I sure don't like it!), the
Web has become a standard for delivery of online services and applets
are still a widely used way of delivering client-side logic. Despite the
sclerotic state of browser Java environments, there are many providers
of online services who can only deliver services through JDK1.1 applets
- NO Java 2 plugin, NO application installation to the client.  If you
can't do it with JDK1.1 applets, the alternative is ActiveX controls.

Joi, you're welcome to rail against the stupidity of it all, and I sure
won't disagree! I've spent many miserable hours trying to live within
this awful constraint.  But you and I don't get to decide this one. The
online bank and it's "lazy" programmers are the norm, not the exception.


> If you insist on using non-portable stuff, don't blame the non-portable
> stuff for your own decisions.
> 
> > The stupid and ruinous food fight between Sun and Microsoft pretty much
> > destroyed client-side Java for generations of developers and users. Swing
> > is a good toolkit, but it's also a squandered opportunity thanks to the
> > Java wars. We can rant all we want about the "lazy" programmers publishing
> > applets, but they're just trying to make the best of a bad situation
> > they didn't create. The problem is much deeper and harder to solve.
> 
> We can all thank Microsoft for this mess.  They tried their usual 
> 800-pound gorilla tricks but they took on someone with just as many lawyers.
> Big mistake for a bully who normally picks on much smaller prey.
> 
> Only Windows users are suffering from this problem, the rest of us are doing
> fine without Microsoft's support.

I guess you and I have different customers. I don't get to choose the
runtime environment, the customers do, and they're always right. Maybe Sun
thought it would be able to make the J2RE pervasive in the environment
most people use... if so, well, OOPS! Those of us who have to deliver
real stuff to real users running the world's most pervasive OS are
paying the price. All fights, even big ones between computer companies,
have a million and one opportunities for compromise. Nobody took those
opportunities, and the result is that modern Java implementations are not
reliably available in client environments. You call this a "big mistake"
by Microsoft, but it sure looks like a Microsoft win to me.

Nathan Meyers
[EMAIL PROTECTED]


> 
> -- 
> Joi Ellis                    Software Engineer
> Aravox Technologies          [EMAIL PROTECTED], [EMAIL PROTECTED]
> 
> No matter what we think of Linux versus FreeBSD, etc., the one thing I
> really like about Linux is that it has Microsoft worried.  Anything
> that kicks a monopoly in the pants has got to be good for something.
>            - Chris Johnson
> 


----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to