How to by pass downloading lower versions of Java Plugin ?

I have developed an applet which uses Java plug-in version 1.3.1. One of my friends is using 1.3.1.0.1a. I guess that this is the latest version. But program downloads 1.3.1 Java plug-in. How to bypass downloading lower versions of Java Plug-in if higher version is already installed on client machine ?

Can anyone of you help me in this regard ?

Thanks,

Murali

[393 byte] By [mkesiraju] at [2007-9-26 14:31:42]
# 1

I get the same thing. I think there is a bug with the 1.3.1_01a Plugin. Isn't it suppose to be backward compatible? I guess not. You shouldn't have to download older plugins. Having a 1.3.1_01a plugin with an older plugin will cause crashes as stated in the Release Notes and also in my experience.

Qquark at 2007-7-2 16:21:05 > top of Java-index,Desktop,Deploying...
# 2

I think this is a really critical problem.. every webpage that uses the OBJECT tag to invoke the plug-in has to have a hardcoded plug-in version specified, and users are inevitably going to access pages with differing plug-in versions.

Right now it appears each different plug-in reference will install another plugin and JRE right next to the others, instead of sorting it out and keeping just one version on the user's workstation. This in turn bombs the plug-in operation.

I am finding this pretty impossible to defend in arguing for plug-in use with our software product. Are any Sun employees reading this who can give a status update on this issue or correct any misunderstandings?

Thanks,

Kevin

kevina01 at 2007-7-2 16:21:05 > top of Java-index,Desktop,Deploying...
# 3

Found a possible solution by going through the bug reports. For your Mime Type use "application/x-java-applet;version=1.3" instead of "application/x-java-applet;jpi-version=1.3.1" or "application/x-java-applet;jpi-version=1.3.1_01a". All the 1.3.x plugins should be able to handle the first MIME. The ones with the "jpi-version' specifies Java to ONLY use 1.3.1 plugin or else if not found, it will try to install it for you.

Qquark at 2007-7-2 16:21:05 > top of Java-index,Desktop,Deploying...
# 4
Also Sun should consider changingthe default settings for the HTML converter. It puts in the "jpi-version" MIME. But it was easy to change the settings. But with the 1.4 plugin, HTML converter becomes obsolete anyway.
Qquark at 2007-7-2 16:21:06 > top of Java-index,Desktop,Deploying...
# 5
Thanks, I will try it out.Kevin
kevina01 at 2007-7-2 16:21:06 > top of Java-index,Desktop,Deploying...
# 6

OK, I am still getting duplicate JRE/Plug-ins installed side by side after trying this fix. Here are the steps I took (windows 2000, ie6):

1. uninstalled JRE 1.3.1

2. manually installed JRE 1.3.0 from sun site, verified it was installed and corresponding plug-in appears in control panel.

2. modified applet startup page to contain "1.3" as suggested:

PARAM NAME="type" VALUE="application/x-java-applet;version=1.3"

(left html-generator-created page containing object tag pointing to 1.3.1, as follows:)

if (_ie == true) document.writeln('<OBJECT classid="clsid:CAFEEFAC-0013-0001-0000-ABCDEFFEDCBA" WIDTH = 750 HEIGHT = 450 codebase="http://java.sun.com/products/plugin/1.3.1/jinstall-131-win32.cab#Version=1,3,1,0"><NOEMBED><XMP>');

3. ran applet page. it proposed downloading 1.3.1.

4. responded 'no' to install. applet page opens blank.

5. closed and retried applet page, responding 'yes' to 1.3.1 install. that install runs fine, applet starts, but both 1.3.1 and 1.3 JREs and plugins are present on the workstation.

6. uninstalled 1.3 JRE, leaving 1.3.1 JRE, retried applet page. small black box appears in applet's place, and something appears to be downloading very very slowly.

7. uninstalled 1.3.1 JRE, retried applet page, allowed normal plugin download install, applet worked fine.

I have not yet tried specifying an earlier JRE in the tag, and having a later JRE already on the workstation, although I would not be surprised to see duplicate JREs installed in this case as well..

We have had sporadic reports of people having workstations that simply would not run the applet when multiple JREs were present after the autodownload forced by this applet page. Also, IS departments are not going to like having standard environments updated whenever Sun wants, much less having defective configurations created. There really needs to be a way to prevent this problem.

Note: I did not modify the classID/codepath part of the html-generator page with the above suggestion about MIME type, since I did not see how it could be done.

Any ideas?

Also, a comment was made that the html-generator becomes obsolete in 1.4 plugin. When will this be, and does this change modify the way the OBJECT tag is written, so that this problem doesn't keep occuring?

Thanks,

Kevin

kevina01 at 2007-7-2 16:21:06 > top of Java-index,Desktop,Deploying...
# 7

I assume you are using IE. In that case try changing the CLSID in the <OBJECT> tag to 8AD9C840-044E-11D1-B3E9-00805F499D93. You can use Java 1.3.1_01x.

Or you can, starting with this version, just use the simple <APPLET> tag without all that custom brower identification code.

Qquark at 2007-7-2 16:21:06 > top of Java-index,Desktop,Deploying...
# 8

I will try the id but could you explain what it invokes and why it would help with this problem of multiple JREs getting installed?

Also, when you say with this version I can just use applet, what does that mean? I take it to mean the whole html-converter-output thing would be obsolete and old style applet tags would be all i have to deploy. is this so? and what product and version are you referring to? i'd assume plugin 1.4 but I'd like to be sure.

Thanks for your help.

Kevin

kevina01 at 2007-7-2 16:21:06 > top of Java-index,Desktop,Deploying...