2

My team uses a lot of Java applications and applets (both internally created and from external sources).

Since the release of Java 7, which we are using for some applications, we have found a number of problems with external applications and applets which do not support Java 7 (although I don't know why - however, having spoken to the tech support at the organisations that provide these applications, they indicate that their applications are not compatible with Java 7).

Unfortunately, many of these applications state that they work on any (recent) version of Java (e.g. 1.5+). Obviously, it would be nice if the providers of these applets and applications would amend their code to specify which version of Java they can work on, rather than stating they can work with versions that they don't. However, what can I do in the interim?

Webstart Applications:

For these I create a batch file specifying which version of the JRE to use e.g.:

C:/"Program Files"/Java/jre6/bin/javaws http://www.website.com/path/to/app.jnlp

Is there a better way of doing this?

Web Applets:

I've not had any success with specifying for web applets. I know I could specify the JRE version for Internet Explorer (e.g. this question), but I don't want to force all web applets to use an old version of Java - I only want to specify on a case by case basis.

I had contemplated creating a batch file that would launch internet explorer with a particular JRE specified... something along the lines of

start iexplore [specify JRE] http://www.website.com/pageWithWebApplet.html

...but I don't know how to specify the JRE. Any ideas?

Alternatively, if there are better ways of doing this, I would love to know.

Community
  • 1
  • 1
amaidment
  • 6,942
  • 5
  • 52
  • 88
  • 3
    Do these apps declare that they won't work with Java 7, or do they just fail? Since Java 7 just came out, you can't expect developers to have predicted beforehand that it wouldn't be compatible. Past Java releases have always been extremely good about backward compatibility so it was reasonable to assume that any app that worked on an earlier JVM would run under Java 7. – Nate C-K Aug 31 '11 at 15:17
  • @Nate C-K - the jnlp files or the websites say they work with all recent versions of Java (e.g. 1.5+). The apps/applets fail to launch with Java 7. I agree that they cannot be expected to have predicted the non-compatibility with Java 7, but since these are large organisations and app/applets used by many clients on a daily basis, the issue should have been raised by now (or at least, I have now raised it!) and their code should be amended accordingly - that is the ideal solution. However, I need a way of getting things up and running before they do that... – amaidment Aug 31 '11 at 15:22
  • 1
    It is kind of idiotic to jump on a major release of anything without testing it before hand for things that are business critical. There is nothing really positive about Java 7 that is compelling to do all the work for making sure it is is working 100% with legacy applications. We won't be switching to it for at least a year. –  Aug 31 '11 at 16:07
  • @Jarrod - that misses the point... the essence of the problem is: a) I want to use apps/applets which definitely require a particular java version, b) those apps/applets do not specify *in code* that they require that particular java version (e.g. in the jnlp file). So to repeat the question... how can I, on a case by case basis, set up a configuration that will use the version of Java that is required by the apps/applets? – amaidment Aug 31 '11 at 16:13
  • 1
    Reasons for wanting to do so aside, it's a perfectly legitimate question that deserves an answer. (I'd answer it myself, but I don't know either.) – Nate C-K Aug 31 '11 at 19:30

1 Answers1

0

For an applet, you could try saving the page the applet is in, plus its JNLP file, edit the JNLP file to change version="1.6+" to version="1.6" (or whatever), change the HTML file so the applet points to the local version of the JNLP file but everything else points to the original site, put the modified files up on your intra-net, and point your web browsers at your intra-net's page when you want to use the applet. Since the applet's codebase still will be on the external website instead of on your intranet, untrusted applets will still be able to make network connections back to their originating host.

Of course, this assumes that the external website allows the relevant files to be downloaded when the HTTP referer isn't their site (that is, it allows "hotlinking" of its resources).

Matthew Cline
  • 2,312
  • 1
  • 19
  • 36