Java applet speed (was Re: [oclug] Monitoring memory usage)
olaf.baumann at pobox.com
Sat Mar 5 17:37:11 EST 2005
On 22-Feb-05, at 10:27 AM, Frank Stratton - VE3YY wrote:
> Hi Adrian,
> I can't be certain, but it seems to be waiting on the server to
> deliver the
> code. Somewhere I read that it is possible to compress the code so
> that it
> takes less time to transmit and setup on the client side. The PHP
> stuff is
Java applets are delivered to the requesting client in jar (java
archive) format. jar files are simply a zip file with some metadata
included. You can think of them as mounted filesystems in your java
virtual machine--a place where the ClassLoader goes to search for
.class files and other resources.
Back in the old days, jar files were not compressed, I believe the
original need was to present a filesystem with more capabilities than
FAT could provide (case sensitivity, file name length, etc.). Not long
after, the jar format was compressed by default.
You normally create jar files with the jar command, but if you know how
to place the metadata, you could probably use any zip utility and
specify the compression level (or create the jar as normal, unzip it to
another directory, and zip with a maximum compression).
That said, it probably isn't your problem. As someone else pointed out
in this thread, launching an applet on a web page involves starting up
a JVM which is, don't forget, equivalent to booting a computer in some
> fast, in fact Internet Exploder has a problem setting up certain
> because half the time it fails to draw the form. I think that will be
Try in another browser to validate this.
> resolved over the Internet because of the time delay. Somewhere, I
> that Tomcat was faster at delivering the java applets. I've loaded
> from other websites and they don't take as long to execute, so I'm
> that it's at my server end.
Tomcat will not speed up serving of applets. The fastest way is to let
a web server like apache serve up the applet jar file just as a regular
resource and possibly tweak the expiry of the resource so that it can
be cached somewhere between the client and the server. Beware that
allowing caching will force you to be aware of the caching behavior in
order to know what version you are running in code/build/deploy/test
cycles (dump the build version to System.out when the applet starts so
you can see it in the logs).
> I haven't looked into it, but maybe, I can use PHP to drop the applets
> the client although that would seem to be a security issue.
Wrong tree to bark up. Let your browser cache it locally if it feels
it needs to. If you are concerned about security, look into digital
signatures for the applet.
How big is the applet jar file?
What speed of network connection between client and server?
What vintage is the client machine?
 except for some MSFT-specific cases I believe, best to be avoided
in any case
> -----Original Message-----
> From: Adrian Irving-Beer [mailto:wisq-oclug at wisq.net]
> Sent: February 22, 2005 9:15 AM
> To: fstratton at sympatico.ca; General Membership Discussion List
> Subject: Java applet speed (was Re: [oclug] Monitoring memory usage)
> On Mon, Feb 21, 2005 at 10:43:49PM -0500, Frank Stratton - VE3YY wrote:
>> Now as for Java, I've been learning Java and I have noticed that
>> some of my applets run a little slow. Not sure why, but figured that
>> it was an interface problem with Micro$oft Internet Exploder,
>> although it also was slow with Firefox. Maybe I don't have my Apache
>> web server configured correctly. Someone mentioned Tomcat, but I've
>> been avoiding that since I don't know if that will cure my problem.
>> Any thoughts?
> I can't comment on the speed issue, but AFAIK, I don't see how Tomcat
> on a server side is going to speed up Java on the client side, which
> is just a function of running on the client's machine, no?
> OCLUG general discussion list
> OCLUG at lists.oclug.on.ca
More information about the OCLUG