JAVA 2 JRE and Applets

[Gil]

I'm going to come over as a bit of a newbie here, but I've been using
Java (mostly for applications, rather than applets) since 1997 and I'm
finding it hard to get to grips with what's going on.

Put simply, as a trivial example, here it is:

I have a very simple applet, built in an early javac at :
http://www.amazonsystems.co.uk/data/morn.htm

Up till recently, this has worked fine with all Windows (I haven't
tried Unix etc) versions of IE, Netscape and other common browsers
(presumably with Java 1 JREs). Since the advent of Java 2... I get a
variety of problems on various machines and browsers with JRE 1.3
onwards, such as Class not Found or Security Exception when accessing
via a proxy, all of which culminate in the extremely irritating status
message "notinited".

I would have expected a spot of forward compatibility, but I suppose
if what we're doing is improving security, then it's fair enough.

What isn't fair enough is that after a good deal of poking around in
Google groups, I haven't been able to find out what you do to make it
all work. Do I recompile the applets with a Java2 compiler, and if I
do will they still work with an old JRE as long as I don't use new
Java2 features? Do I have to find out (using Javascript or whatever)
what JRE is in the browser and nominate a different class for
different JRE generations? Is there a simple tweak that a Windows
user has to do to his options that gets round the proxy security
restriction? I've seen something for Linux, but not Windows.

If this is answered elsewhere, as it ought to be, then I'm happy just
to be redirected. On the other hand, I looked at the Sun site and
couldn't find the relevant data there.

TIA

Gil

 

[VK]

Pack your class together with all used images in jar file.
Call applet from the jar.
Get images from the jar using getCodeBase.
After that everything will fly w/o problems.

Your method with getDocumentBase never was right, but yes, just recently
the security patches did it non-workable in some circumstances.

P.S. Nice game, despite I did not get the rules, did not have time to
read thru

 

[Gil]

Pack your class together with all used images in jar file.
Call applet from the jar.
Get images from the jar using getCodeBase.
After that everything will fly w/o problems.

Your method with getDocumentBase never was right, but yes, just recently
the security patches did it non-workable in some circumstances.

P.S. Nice game, despite I did not get the rules, did not have time to
read thru

Thanks for the reply. (The game is a bit of a British joke, you make
up the rules as you go along, but no-one admits it)

A couple of supplementaries:

Will using a jar deal with the proxy security exception problem?

Will using a jar still work with old JREs - like the whole IE
community?

TIA

Gil

 

[Andrew Thompson]

....

Will using a jar still work with old JREs - like the whole IE
community?

No. IE 6 comes with no JRE at all, and it is becoming
common for other browser distributors to offer 'Java' and
'No Java' options. For further details..
http://www.physci.org/test/java/PlugIn.html

 

[Tim Tyler]

Will using a jar still work with old JREs - like the whole IE
community?

If the Microsoft JVM is installed, it can read classes from jar files -
and has been able to do so for a very long time, now.

 

[Gil]

If the Microsoft JVM is installed, it can read classes from jar files -
and has been able to do so for a very long time, now.

Thanks, Tim.

So, let me get this straight:

Thousands, even tens of thousands, of Java 1 applets stop working for
you when your browser gets Java2.

The Java 2 JRE cannot recognise a Java 1 applet and deal with it
differently.

There is no straightforward tweak which the end-user can apply to make
his browsing Java 1 compatible.

What the applet owner can do is to recompile the applet and package it
up in a jar so Java 2 browsers can see it, and it may (according to
Tim) be readable to the huge raft of Java 1 browsers.

..... and people complain about Micro$oft.


So, if I want my own applets to survive, then if Tim is wrong, I have
to repackage them and deploy them beside the old ones and figure out
some way of distinguishing a user's JRE in the HTML / Javascript that
calls the appropriate applet.

Is this possible? I know Javascript can see the plug-ins. Let's just
hope they can be uniquely identified.

I keep feeling there ought to be a FAQ about this somewhere...


I also have another quibble about this JAR business, in which VK says
I ought to package up the images and sound files with the classes:

The applet I'm currently working on, which works fine in Java 1
browsers / JREs, will eventually use about 300 jpg 640 x 480 px
images.

Any one user in any one session will probably need only a dozen of
these, and he'll use them one by one, so each new getImage() results
in a pause of a few seconds from image to image.

If I have to wrap up 300 640x480 images at 30K (compressed) each,
that's about a 9Meg download for the JAR, even if the user only needs
a few images. There MUST be another way.

I was sadly unaware of this discontinuity. I chose a java applet
because the analogous Flash solution carried the problem of having to
download the whole product before you saw the first image, and because
the programming possibilities were so much more flexible.

I consulted my two fat books on Java 2 in this regard. One barely
mentioned applets, and didn't talk about the new drawbacks at all. The
other gave a single trivial JAR example without reference to data
files packaged with the classes.

I'll obviously chase this up myself, but would be grateful for any
more pointers.

TIA

Gil

 

[Tor Iver Wilhelmsen]

The Java 2 JRE cannot recognise a Java 1 applet and deal with it
differently.

Yes it can. It cannot, however, deal well with Swing 1.1.1 using the
Windows L&F because it has the same package hierarchy and thus ends up
using the wrong classes.

Nor will Sun's VM use Microsoft's CAB packaging format.

 

[Tim Tyler]

Thanks, Tim.

So, let me get this straight:

Thousands, even tens of thousands, of Java 1 applets stop working for
you when your browser gets Java2.

The Java 2 JRE cannot recognise a Java 1 applet and deal with it
differently.

There is no straightforward tweak which the end-user can apply to make
his browsing Java 1 compatible.

What the applet owner can do is to recompile the applet and package it
up in a jar so Java 2 browsers can see it, and it may (according to
Tim) be readable to the huge raft of Java 1 browsers.

.... and people complain about Micro$oft.

So, if I want my own applets to survive, then if Tim is wrong, I have
to repackage them and deploy them beside the old ones and figure out
some way of distinguishing a user's JRE in the HTML / Javascript that
calls the appropriate applet.

Is this possible? I know Javascript can see the plug-ins. Let's just
hope they can be uniquely identified.

I keep feeling there ought to be a FAQ about this somewhere...

The compatibility issues are covered in:

``Microsoft VM and Java 2 Applet Compatibility Issues''

http://java.sun.com/j2se/1.4.2/docs/guide/plugin/developer_guide/compatibility.html

This has Sun giving a partial list of why Applets that work in the MS
JVM fail to work correctly in the Sun JVM.

Don't get into JavaScript - if you can help it. If you want to call
different code depending on the VM version, use an interface and two
different classes - and instantiate them appropriately.

 

[Tim Tyler]

I also have another quibble about this JAR business, in which VK says
I ought to package up the images and sound files with the classes:

The applet I'm currently working on, which works fine in Java 1
browsers / JREs, will eventually use about 300 jpg 640 x 480 px
images.

Any one user in any one session will probably need only a dozen of
these, and he'll use them one by one, so each new getImage() results
in a pause of a few seconds from image to image.

If I have to wrap up 300 640x480 images at 30K (compressed) each,
that's about a 9Meg download for the JAR, even if the user only needs
a few images. There MUST be another way.

Don't put the images in the Jar file, if it makes no sense to
do so.

Instead, access them from a URL.

 

[Danny Woods]

What the applet owner can do is to recompile the applet and package it
up in a jar so Java 2 browsers can see it, and it may (according to
Tim) be readable to the huge raft of Java 1 browsers.

There's no need for this. Properly written applets work fine in both
Java 1 and Java 2 without any need to target the compile. I've
written a video player applet that was constrained by the need to
work on both Microsoft's and Sun's VMs, but that makes use of
the more sophisticated features of the latter (high quality, stereo
audio with javax.sound, and a non-broken DatagramSocket implementation
that makes RTP possible).

Aside from avoiding Java 2 code entirely (except in dynamically loaded
modules), I've had absolutely no trouble here.

I also have another quibble about this JAR business, in which VK says
I ought to package up the images and sound files with the classes:

I wouldn't say that this is meant to be an absolute rule, just a
guideline. For example, the player I mentioned above is about 100K
of JAR file. It'd be quite ludicrous to package up the video clips
as well, as these can easily reach over a megabyte in size.

Indeed, when it comes to real-time streams, it's simply impossible.

The applet I'm currently working on, which works fine in Java 1
browsers / JREs, will eventually use about 300 jpg 640 x 480 px
images.

Yours definitely sounds like an exception to the rule, then. Keep the
images on the server, and load as required.

The one thing I would suggest to make things a little easier is to use
the -target 1.1 switch on javac to make sure that you don't generate
class files that the Microsoft VM can't understand. Even with this,
however, you'll need to be careful not to use features that were
introduced in Java 1.2 or later. Keep a copy of IE close to hand
(configured to use Microsoft's VM) and copy of Mozilla/Firebird
for the Java 2 side. Test frequently. And *do* expect
discrepancies between the capabilities of both VMs. They sometimes
have different ideas on what applets are and are not allowed to do,
but opening up a TCP socket back to your hosting server to retrieve
an image is something that's definitely ok under both.

Best of luck,

Danny.

 

[Andrew Thompson]

(e-mail address removed) (Gil) writes: .....
The one thing I would suggest to make things a little easier is to use
the -target 1.1 switch on javac to make sure that you don't generate
class files that the Microsoft VM can't understand. Even with this,
however, you'll need to be careful not to use features that were
introduced in Java 1.2 or later.

I thought te compiler would warn you about using 1.2
features in a applet using -targeting 1.1, or are you saying
that is not the case, Danny?

 

[Gil]

Happily, I don't think I'm going to run into issues related to post
Java 1.1 classes and language features. I'm a very conservative
programmer in that regard. I've also learned a lot about jars in the
last 48 hours.

I'll have a look at that Sun URL re IE compatibility.

But, if I may summarise what I think you're all telling me:

If I recompile my applets using a 1.1 compatibility switch, and pack
up all the classes in a jar, and dowload any images by a full URL,
rather than relative to codebase, then I won't get any trouble from
Java 2 JREs and it'll still work on IE's JRE and I won't get any
security exceptions from proxies.

Time for a few experiments, I think.

Thank you all for your help.

Gil

 

[Danny Woods]

I thought te compiler would warn you about using 1.2
features in a applet using -targeting 1.1, or are you saying
that is not the case, Danny?

I distinctly remember sneaking some non-1.1 features through the -target 1.1
switch in the past, so I've never trusted it to pick up use of these features.
I don't really think that this is what the switch is for, anyway. The
(somewhat sparse) documentation on the Sun site seems to indicate that it's
just about the bytecodes produced, not the classes used:

http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/javac.html#crosscomp-options

Regards,

Danny.

 

[Tim Tyler]

I thought te compiler would warn you about using 1.2
features in a applet using -targeting 1.1, or are you saying
that is not the case, Danny?

The compiler currently has no idea which packages, classes and methods
were available in Java 1.1 - so it doesn't warn you about using ones that
came in later.

 

[Gil]

If you want to call

different code depending on the VM version, use an interface and two
different classes - and instantiate them appropriately.

I don't think I really want to obey different code within the applet.
I was anticipating that I might have to deliver the code to the user
in two different forms by two different <APPLET> commands, depending
on the generation of the JRE, in which case, putting the decision in
the applet code would be too late, and I'd have to decide in
Javascript which <APPLET> command to obey.

Your idea will have merit, however, when I know I can rely on the
applet being loaded, whichever JRE is in charge, and want to, say,
fetch the images in a different fashion depending on the JRE.

Regards.

Gil

 

[Andrew Thompson]

I don't think I really want to obey different code within the applet.
I was anticipating that I might have to deliver the code to the user
in two different forms by two different <APPLET> commands, depending
on the generation of the JRE, in which case, putting the decision in
the applet code would be too late, and I'd have to decide in
Javascript which <APPLET> command to obey.

Not necessary. You can use the JavaVersionApplet
to redirect according to JRE version.
http://www.physci.org/test/JRE/ the source can be seen..
http://www.physci.org/codes/display.jsp?fl=/test/JRE/JavaVersionApplet
..java

 

[Gil]

to redirect according to JRE version.
http://www.physci.org/test/JRE/ the source can be seen..
http://www.physci.org/codes/display.jsp?fl=/test/JRE/JavaVersionApplet
.java

Thanks, Andrew, that looks useful.

I'm scratching around for my old Mornington Crescent source, so I can
start my experiments, but I'll keep everyone posted.

Regards.

Gil

 

[Gil]

Time for a few experiments, I think.

REPORT ON THE EXPERIMENTS

The project is delivery of a Myst-like adventure to a browser. Most of
the technical challenges, such as the adventure system, moving
sprites, ambient music, Save and Restore in IE (using cookies) have
been solved. It's just the cross-browser / cross-JRE stuff still to be
solved.

And, friends, the experiment can be viewed at a temporary, free,
website called:
http://www.nascr.net/~fff/bridge/pagej7.htm

This shows the chief features of the system in 5 scenes with a few
sprites.

(You may experience some irritation from the javascript associated
with the background music, because I haven't cross-browsered that yet
either.)

What I've changed:

The application was compiled using Sun's v 1.2.2 javac without the
-target, and jar'd using the same generation of jar utility.

The .jar is referenced in the APPLET tag by full URL - for some
reason, I couldn't get a relative URL to work.

All image and .au fetches are now done by full URL, without reference
to getCodeBase().

It still works fine for me in IE v5 direct dial-up.

In IE 5.5 via a proxy, it kind of works, though the Save / Restore
doesn't, while the Inventory does, so there may be a problem with
cookie stuff via the proxy.

It no longer works for Netscape 4.8 direct dial-up - can't tell why.
It says "Applet Bridge Can't init : NEW". Maybe it doesn't understand
archive = "...jar", but that's fine, I can get Javascript to sort that
out, and field the class files for any non-jar browsers.

It works in Netscape 7 with JRE 1.3.1-02 via a proxy, but again the
Save / Restore doesn't work. Inventory works in Netscape 7.

K-Meleon with JRE 1.3.1-02 via a proxy nearly works, but none of the
Javascript buttons seem to work at all.

I'll try Opera direct dial-up this weekend.

Any hints or further reports using different browsers welcome.

Thanks, all.

Gil