🚀 go-pugleaf

In a word, yes... you were wrong.  Sorry to be so sour, but the swing/plugin
has been a pain in my ass for quite some time.  As far as I can tell, the
situation is this: different plugin versions do not cohabitate well and
there is only long range evaluation efforts on Sun's radar screen - this
includes plugin support for multiple JDK's on the same machine.  Next; the
version of swing in jdk 1.2 seems to have much less capability and more bugs
than the _beta_ versions of 1.1.x - particularly re: html components.  So if
you want decent swing functionality, use 1.1.1, which seems to require JDK
1.1.7 or better, but NOT JDK 1.2.  That means you'll need plugin 1.1.x plus
having to deploy (maybe manually) a swingall.jar to replace the one that
comes with the plugin.  Of course, if the user already has plugin 1.2, then
they will have to uninstall it first and then install 1.1.x.

I hate to say it (and, _please_!!!!!, if someone has a solution to these
problems, let the rest of us in on it), Java as a
GUI client is breathing it's last.  The conspiracy theorist in me says that
Sun is purposely making swing and client deployed apps/applets more
difficult to build, since software on the client does not necessarily
require server hardware - their bread and butter.  No, this is not intended
as flame bait.

---
Regards,
-Joe

Alex B. Humphreys wrote:

> I've set my Jbuilder (2.01) to run using the jdk and swingall that come
> with the Java Plug-In (so that when I deploy it is should be smooth
> sailing).  But when I deploy it, I need to include a DIFFERENT swingall
> (which is older) in the classpath or else I get a NoClassDefFound on
> JApplet or Metal LookandFeel.  How can I compile my program so it
> includes the necessary swing classes and can run with the installed Java
> Plug-In swingall (rather than making people download a 2Mg swingall)?
>
> I'm aware that swing isn't the best solution on the web, but I had hoped
> that the java plug-in would help to remedy the situation.  Was I wrong?
>
> Thanks
> Alex