What is the difference between Java JRE 5.x and 6.x (1.5.x / 1.6.x)???

[Arved Sandstrom]

Not usually, but of course, it's impossible to say with certainty.

If the user has been rigorous about keeping the older versions updated,
that definitely mitigates the risk. If the user has 1.2 or older, well,
they're SOL I guess, but it's their own fault. 1.3 and later get
security updates.

A malicious app would have to insist on using only an older version of
Java (doable with Java Web Start AIUI - not sure if possible with
applets), hope the user has that version installed (which cannot be
guaranteed), and depend on the user not having kept it up to date. The
target population would comprise casual users - professionals would be
much more likely to have kept things up to date and to have purged
obsolete versions, and less likely to run exploitative code. Casual
users are more likely to have current versions of Java, and to be
running the Java update service in the background, keeping their Java
patched. Plus there just aren't so many casual users.

Given the difficulty of getting Java to do anything harmful in the first
place, given the sandbox and how few Java exploits there ever were, that
would be an awful lot of malice invested in writing code for very little
chance of damage. It's so much easier for the frakheads to write
malware in languages other than Java.

The risk is negligible. It's a tempest in a teapot.

Has your research uncovered any such incidents?

I don't know if it was possible before in a Java applet to select JRE
version, but it is now (I think as of SE 6 Update 10).

AHS

 

[Martin Gregorie]

I don't know if it was possible before in a Java applet to select JRE
version, but it is now (I think as of SE 6 Update 10).

I recently saw a page that ties an applet to JRE 1.4.1 rather than
specifying >= 1.4.1. As a consequence it would not run against Java 6,
which I have installed, and (worse) tried to tell me that my JRE had to
be *upgraded* to 1.4.1

It's using this to see if the applet can be run:

<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
width ="200"
height="100" align="baseline"
codebase="http://java.sun.com/products/plugin/autodl/jinstall-1_4-
windows-i586.cab#Version=1,4,1,mn">
<PARAM name="code" value="ipas.test.TestMouseInput">
<PARAM name="codebase" value="./">
<PARAM name="type" value="application/x-java-applet;jpi-
version=1.4.1">
<PARAM name="scriptable" value="true">
<param name="id" value="rcipfrv82o5vlsjoj4ajjsn3s2">
No Java 2 SDK, Standard Edition v 1.4.1 support for APPLET!!
</OBJECT>

This is really stupid because it defined two hard-wired dependencies:
- JRE 1.4.1 as the only accepted JRE
- Windows as the only permitted OS

 

[Arved Sandstrom]

I recently saw a page that ties an applet to JRE 1.4.1 rather than
specifying >= 1.4.1. As a consequence it would not run against Java 6,
which I have installed, and (worse) tried to tell me that my JRE had to
be *upgraded* to 1.4.1

It's using this to see if the applet can be run:

<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
width ="200"
height="100" align="baseline"
codebase="http://java.sun.com/products/plugin/autodl/jinstall-1_4-
windows-i586.cab#Version=1,4,1,mn">
<PARAM name="code" value="ipas.test.TestMouseInput"> <PARAM
name="codebase" value="./">
<PARAM name="type" value="application/x-java-applet;jpi-
version=1.4.1">
<PARAM name="scriptable" value="true"> <param name="id"
value="rcipfrv82o5vlsjoj4ajjsn3s2">
No Java 2 SDK, Standard Edition v 1.4.1 support for APPLET!!
</OBJECT>

This is really stupid because it defined two hard-wired dependencies: -
JRE 1.4.1 as the only accepted JRE
- Windows as the only permitted OS

I believe I saw a mention of this on one page I stumbled across. J2SE 6
Update 10 has a new Java Plugin behaviour, but prior to that I think in
Internet Explorer only, going back to some version of J2SE 5, you could
hardcode a JRE version. I think it's this latter that you are describing.
The new Java Plugin behaves more sensibly, starting with the fact that
you give it options for JREs, including minimum acceptable (I believe)
and it'll pick the best one you've got.

AHS

 

[Arne Vajhøj]

I don't know if it was possible before in a Java applet to select JRE
version, but it is now (I think as of SE 6 Update 10).

Just x.y.z or x.y.z update w ?

Arne

 

[Martin Gregorie]

I believe I saw a mention of this on one page I stumbled across. J2SE 6
Update 10 has a new Java Plugin behaviour, but prior to that I think in
Internet Explorer only, going back to some version of J2SE 5, you could
hardcode a JRE version. I think it's this latter that you are
describing. The new Java Plugin behaves more sensibly, starting with the
fact that you give it options for JREs, including minimum acceptable (I
believe) and it'll pick the best one you've got.

That sounds a lot more sensible.

I sent them a (considerably) more polite version of "why do you do these
brain-dead things when you could/should be using JWS". I'll be very
interested to see what, if anything, they have to say.

The really silly thing was that this was on a recruiting
page: it was meant to launch an aptitude testing applet. Putting
obstacles of this type in the way of potential recruits is not exactly
clever.

 

[Roedy Green]

What exactly is the difference between the JRE 5.x and 6.x (or 1.5.x
and 1.6.x) versions of the Sun Java Runtime Engine for windows?

Why does Sun maintain 2 different versions or streams or forks of the
JRE?

Is it true that version 5 was supposed to have an EOL this past
October - or was it always EOL in October 2009?

How would my "internet browsing experience" be different if my system
had the latest update of version 5 versus version 6?

Is it true that version 6 is somehow optimized or faster than 5?

Sun is always adding new functionality. for major new functions the
increment by .1. For bug fixes and the have minor versions.

Right now they have three main versions, JDK
1.4.2_19 1.5.0_17 and 1.6.0_11, each with the latest bug fixes.

In theory code is upward compatible, but for safety many only want to
run code on the JVM it was tested with. Sun supports the previous two
versions for the benefit of these corporate customers for whom
retesting a giant application would not be cost justified.

Version 1.6 starts up faster than 1.5. Version 1.6 has a number of
optimisations. For the fastest performance, use Jet.
See http://mindprod.com/jgloss/jet.html


for differences between versions see
http://mindprod.com/jgloss/jdk.html#DIFFERENCES
--
Roedy Green Canadian Mind Products
http://mindprod.com
PM Steven Harper is fixated on the costs of implementing Kyoto, estimated as high as 1% of GDP.
However, he refuses to consider the costs of not implementing Kyoto which the
famous economist Nicholas Stern estimated at 5 to 20% of GDP

 

[Bent C Dalager]

I recently saw a page that ties an applet to JRE 1.4.1 rather than
specifying >= 1.4.1. As a consequence it would not run against Java 6,
which I have installed, and (worse) tried to tell me that my JRE had to
be *upgraded* to 1.4.1

I find it oddly disturbing to note that we now appear to need a
SetVer.java :-/

Cheers,
Bent D

 

[Martin Gregorie]

I sent them a (considerably) more polite version of "why do you do these
brain-dead things when you could/should be using JWS". I'll be very
interested to see what, if anything, they have to say.

Follow up: they sent me a nice note thanking me for the heads-up. I
wonder what they'll do now and how long it will take.

 

[Martin Gregorie]

I find it oddly disturbing to note that we now appear to need a
SetVer.java :-/

Since a class file can find out what JVM version its running in, there's
no reason why the first action in main() or Applet.init() shouldn't be to
throw an exception if the JVM is earlier than the target JVM.

Or does it already do this?

 

[Bent C Dalager]

Since a class file can find out what JVM version its running in, there's
no reason why the first action in main() or Applet.init() shouldn't be to
throw an exception if the JVM is earlier than the target JVM.

The purpose of a Java setver facility would be to report different VM
versions to different software in order to induce such software to run
in newer VMs than it was designed for. Much like the old DOS setver
utility did. Essentially it causes the system to lie to the app about
the system's version number. In the case referenced above, the applet
would say "so what JVM version is this" and the 1.6 VM would go "ummm
.. . . depends . . . who is this asking . . . ah, right, for you I'm
1.4.1".

It's an ugly hack to get around developers having been too paranoid
about which environments they want their software to run in.

Cheers,
Bent D

 

[Java Guy]

I've been trying to following this thread, but I'm not sure if one
fundamental question has been answered.

Can a malicious piece of java web-code force the use of an older (unsafe
but still present) version of the JRE even if a newer (safe) version of
the JRE in installed on the same system?

 

[Lew]

I've been trying to following this thread, but I'm not sure if one
fundamental question has been answered.

Can a malicious piece of java web-code force the use of an older (unsafe
but still present) version of the JRE even if a newer (safe) version of
the JRE in installed on the same system?

It was answered. The answer was "unlikely in practice". For further
information, GIYF.

 

[Arved Sandstrom]

Arved Sandstrom wrote: [ SNIP ]

I don't know if it was possible before in a Java applet to select JRE
version, but it is now (I think as of SE 6 Update 10).

Just x.y.z or x.y.z update w ?

Arne

You can get as specific as update. From
http://java.sun.com/javase/6/webnotes/6u10/plugin2/version-selection/index.html:
******************************
The new Java Plug-In provides a new platform- and browser-independent
mechanism for selecting a JRE version upon which to launch an applet: the
java_version applet parameter. This new parameter supports:

a.. Selection of a particular JRE version ("1.5.0_11")
b.. Selection of a particular JRE family ("1.5*")
c.. Selection of a particular JRE family or later ("1.5+")
AHS

 

[Arne Vajhøj]

Arved Sandstrom wrote: [ SNIP ]

I don't know if it was possible before in a Java applet to select JRE
version, but it is now (I think as of SE 6 Update 10).

Just x.y.z or x.y.z update w ?

You can get as specific as update. From
http://java.sun.com/javase/6/webnotes/6u10/plugin2/version-selection/index.html:
******************************
The new Java Plug-In provides a new platform- and browser-independent
mechanism for selecting a JRE version upon which to launch an applet: the
java_version applet parameter. This new parameter supports:

a.. Selection of a particular JRE version ("1.5.0_11")
b.. Selection of a particular JRE family ("1.5*")
c.. Selection of a particular JRE family or later ("1.5+")

In which case the original poster should worry.

Fully updated with all x.y.z version should mean that
it is safe to allow an applet to pick x.y.z version.

But fully updated with all x.y.z versions (have latest w)
but not having deleted the old w-1 mean that it is not safe
to allow an applet to pick x.y.z update w.

Arne

 

[Arne Vajhøj]

The purpose of a Java setver facility would be to report different VM
versions to different software in order to induce such software to run
in newer VMs than it was designed for. Much like the old DOS setver
utility did. Essentially it causes the system to lie to the app about
the system's version number. In the case referenced above, the applet
would say "so what JVM version is this" and the 1.6 VM would go "ummm
. . . depends . . . who is this asking . . . ah, right, for you I'm
1.4.1".

System.setProperty("java.specification.version", "1.4.1");

?

Arne

 

[Arved Sandstrom]

Arved Sandstrom wrote: [ SNIP ]
I don't know if it was possible before in a Java applet to select JRE
version, but it is now (I think as of SE 6 Update 10).
Just x.y.z or x.y.z update w ?

You can get as specific as update. From
http://java.sun.com/javase/6/webnotes/6u10/plugin2/version-selection/index.html:
******************************
The new Java Plug-In provides a new platform- and browser-independent
mechanism for selecting a JRE version upon which to launch an applet: the
java_version applet parameter. This new parameter supports:

a.. Selection of a particular JRE version ("1.5.0_11")
b.. Selection of a particular JRE family ("1.5*")
c.. Selection of a particular JRE family or later ("1.5+")

In which case the original poster should worry.

Fully updated with all x.y.z version should mean that
it is safe to allow an applet to pick x.y.z version.

But fully updated with all x.y.z versions (have latest w)
but not having deleted the old w-1 mean that it is not safe
to allow an applet to pick x.y.z update w.

Arne

Except that (from the same link):

**************************************
When considering a request to launch an applet on a specific JRE version
(for example, a particular update release like "1.5.0_11"):

1.. The list of available JREs is consulted. If there is an exact match of
the version string, that JRE version is selected. Otherwise, if there are
one or more installed JREs in the same family, the latest version is
selected. Otherwise, the latest available JRE on the machine is selected.
2.. The selected JRE version is compared against the security baseline for
the family. If it is equal to or more recent than that version, no further
prompting is done and the applet is launched.
3.. Otherwise, the code for the applet is downloaded in a JVM instance of
the selected JRE version. If the applet is signed and the user accepts the
security dialog for the applet (or the code source has already been
trusted), no further prompting is done and the applet is launched.
4.. Otherwise, we are dealing with an unsigned applet on an "older" JRE
version. A dialog box is presented indicating that this applet is requesting
to run on top of an older JRE release, and asks the user whether he or she
wants to allow it to. If the user clicks "yes", the applet is launched. If
the user clicks "no", the applet is re-launched on top of the latest
available JRE version.

When considering a request to launch an applet on a particular family, the
most recent JRE from that family will be selected and the above steps
starting from (2) will be followed.

When considering a request to launch an applet on a particular family or any
later family, the latest available JRE will be used to launch the applet.

**************************************
So in your example it's quite unlikely that the applet code will get
automatically launched without the user having something to say about it.

AHS

 

[Arne Vajhøj]

Arved Sandstrom wrote:
[ SNIP ]
I don't know if it was possible before in a Java applet to select JRE
version, but it is now (I think as of SE 6 Update 10).
Just x.y.z or x.y.z update w ?
You can get as specific as update. From
http://java.sun.com/javase/6/webnotes/6u10/plugin2/version-selection/index.html:
******************************
The new Java Plug-In provides a new platform- and browser-independent
mechanism for selecting a JRE version upon which to launch an applet: the
java_version applet parameter. This new parameter supports:

a.. Selection of a particular JRE version ("1.5.0_11")
b.. Selection of a particular JRE family ("1.5*")
c.. Selection of a particular JRE family or later ("1.5+")

In which case the original poster should worry.

Fully updated with all x.y.z version should mean that
it is safe to allow an applet to pick x.y.z version.

But fully updated with all x.y.z versions (have latest w)
but not having deleted the old w-1 mean that it is not safe
to allow an applet to pick x.y.z update w.

Arne

Except that (from the same link):

**************************************
When considering a request to launch an applet on a specific JRE version
(for example, a particular update release like "1.5.0_11"):

1.. The list of available JREs is consulted. If there is an exact match of
the version string, that JRE version is selected. Otherwise, if there are
one or more installed JREs in the same family, the latest version is
selected. Otherwise, the latest available JRE on the machine is selected.
2.. The selected JRE version is compared against the security baseline for
the family. If it is equal to or more recent than that version, no further
prompting is done and the applet is launched.
3.. Otherwise, the code for the applet is downloaded in a JVM instance of
the selected JRE version. If the applet is signed and the user accepts the
security dialog for the applet (or the code source has already been
trusted), no further prompting is done and the applet is launched.
4.. Otherwise, we are dealing with an unsigned applet on an "older" JRE
version. A dialog box is presented indicating that this applet is requesting
to run on top of an older JRE release, and asks the user whether he or she
wants to allow it to. If the user clicks "yes", the applet is launched. If
the user clicks "no", the applet is re-launched on top of the latest
available JRE version.

When considering a request to launch an applet on a particular family, the
most recent JRE from that family will be selected and the above steps
starting from (2) will be followed.

When considering a request to launch an applet on a particular family or any
later family, the latest available JRE will be used to launch the applet.

**************************************
So in your example it's quite unlikely that the applet code will get
automatically launched without the user having something to say about it.

So they will get a popup "This applet want to run on an
old JRE - do you want to allow it?" - the same model as for
trusted applets.

That seems fine.

Arne