| Java menu knowledge base
JRE FAQ
JRE / Netscape 6 Compatibility
Netscape 4.x and before used a java interpreter
from Symantec. As from Netscape 6, a Sun Microsystems java virtual machine
(known as the JRE or the "java plug-in") became available, which can,
if desired, be configured to replace the default Microsoft java virtual machine on
Internet Explorer as well. It is likely that the JRE will become more
widely used on Windows, while the Microsoft alternative will become
less widely used.
Due to the bitter java conflict between Sun and
Microsoft, and the changing fortunes of both sides in the courts,
many announcements are made by both companies about future
intentions - but these expressed intentions do not necessarily
become reality. If you read a new press release on java from
such sources, be very careful about how seriously you take it.
Remember that the companies involved are often upset and
angered by their respective misfortunes and they forget that most
of the java conflict is of comparatively little relevance to the end-user.
Problems and solutions when working with the Sun JRE
- General: the problems apply to ALL applets from ALL
manufacturers if you use the JRE. The Sun JRE has a number of significant
problems. If the JRE is, in the future, to become the dominant java interpreter,
it is in everyone's interests that Sun is lobbied hard to improve the JRE.
- Old problems now fixed: when the JRE first appeared,
Sun Microsystems included with it problems with applet sizes, performance issues and
alarming messages while applets were loading. These problems could affect
applets from any programmers, regardless of programming quality. In general, ensure that
you are using recent applet versions and recent JRE versions, and you
can avoid these old problems.
- Simultaneous signed/unsigned applets: if you are running
both signed and unsigned applets on a page, the JRE may fail to apply the certificate
to the correct applet. Once the certificate is accepted, all applets present
will race to grab the certificate. If the true signed applet loses the race, it
may fail to work at all. Solution 1: ensure signed applets load at a different
time to unsigned applets. Solution 2: contact imint.com for an individual
solution.
- Password problems: if you use an applet inside a password
protected area, the Symantec and Microsoft java interpreters "borrow" the password
acceptance from the browser, so you only need to log in once. However the JRE requires
an independent "java log-in", which means that a user will be required to enter
their password two or more times - i.e. once for the browser, and once (or more)
for the JRE. The bug has been assigned critical status at Sun for over a year,
and despite being marked as "fixed" there are numerous reports that it is not.
Suggested work-arounds: (i) when
an applet accesses server resources, experiment with an absolute extended URL which
uses the format protocol://user:password@domain.com/path; (ii) implement applets
so that they do not need additional external resources, as each new call to the server
may require a new password log-in.
- File access issues: to avoid file access issues, do not
use paths which contain spaces.
Problems and solutions when working with Netscape 6
- Parameter-reading bug (this was previously categorised as a JRE bug; it is in
fact a Netscape 6 bug): if you use the <APPLET> tag
and don't preload your parameters using a single client-side javascript document.write
statement for your whole applet implementation, then the JRE won't be able to read
parameters over a slow network like the internet - it will randomly cut off parameter
reading at a point determined by the network's current speed and congestion. This is a major bug which leads
to apparently random and extremely frequent applet failures. If you are running
Netscape 6 now, you can
click here to see an example of the bug. The recommended
avoidance strategy is to preload your parameters using a single client-side javascript document.write
statement.
|
|
