Java applet speed (was Re: [oclug] Monitoring memory usage)

[Olaf Baumann]

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[1].  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 
ways.


> fast, in fact Internet Exploder has a problem setting up certain 
> conditions
> 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 
> read
> that Tomcat was faster at delivering the java applets.  I've loaded 
> applets
> from other websites and they don't take as long to execute, so I'm 
> assuming
> 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 
> on
> 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?

>
> Frank
>

-- 
Olaf
[1] 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
> http://www.oclug.on.ca/mailman/listinfo/oclug
>