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

[sm5w2]

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?

 

[Arne Vajhøj]

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?

That should be in the release notes/new features for 1.6.

Big items are: script engine support, callable compiler, JDBC 4.0
and JAX-WS.

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

1.6 is an evolution from 1.5.

SUN releases new updates of 1.5 to fix bugs etc. just like most
other vendors do.

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

It depends somewhat on the releases of new versions and
SUN's support policies.

http://java.sun.com/products/archive/eol.policy.html claims to
have been updated in April. I don't know what the old version
said.

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

It would most likely be the exact same.

Very few applets will require version 6.

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

It depends on the benchmark.

For one of mine it shows an improvement of +10% for SUN JVM
when using -server.

Other benchmarks will show different results.

Arne

 

[sm5w2]

1.6 is an evolution from 1.5.

SUN releases new updates of 1.5 to fix bugs etc. just like most
other vendors do.

I can understand that sun updates Java.

I don't understand why sun maintains 2 different versions of the JRE.

Why would they not just tell everyone that version 5 is done, and they
must install version 6 to be current?

It would most likely be the exact same.

Very few applets will require version 6.

I'm running windows 98. I have installed version 1.6.0_07. Is it
"bad" (unstable) that I'm running 1.6.x on windows 98 - instead of
1.5.x ???

I think that Sun changed the installer so that I can't install a newer
update for 1.6.x. Why did they do that?

Is it true that if I don't un-install older JRE versions then my
system will be vulnerable to any exploits for the old versions even if
I have a newer version installed as well?

 

[Lew]

I can understand that sun [sic] updates Java.

I don't understand why sun [sic] maintains 2 different versions of the JRE.

Actually, despite their claims to have relegated 1.3 and 1.4 to obsolescence,
they maintain four and are developing a fifth.

As for why, it is extremely common for vendors to maintain more than one
version of a product. Microsoft Windows and Apple's OS are two very popular
examples. In fact, I can think of no successful software product that does
otherwise.

Why would they not just tell everyone that version 5 is done, and they
must install version 6 to be current?

They not only do that, they give them a couple of years to adjust to the idea.
It's called the "End-of-Life" process. However, the vendor cannot force the
customer to upgrade, so if Sun were to go autocratic like that, they likely
would find it to be ineffective.

I'm running windows [sic] 98. I have installed version 1.6.0_07. Is it
"bad" (unstable) that I'm running 1.6.x on windows [sic] 98 - instead of
1.5.x ???

That depends on what you want to do. Windows 98 is pretty unstable to begin
with, and not suitable for server-style applications.

I think that Sun changed the installer so that I can't install a newer
update for 1.6.x. Why did they do that?

I don't believe that they did that, therefore it is meaningless to ask why.

Is it true that if I don't un-install older JRE versions then my
system will be vulnerable to any exploits for the old versions even if
I have a newer version installed as well?

I doubt it. Of what exploits do you speak?

Because Sun maintains all four extant versions of Java and is developing a
fifth, bugs involving exploits tend to get fixed even for the older versions.
Are you concerned about some specific exploit that you believe has not been
fixed in the older versions? Which older versions?

 

[Arne Vajhøj]

I can understand that sun updates Java.

I don't understand why sun maintains 2 different versions of the JRE.

Why would they not just tell everyone that version 5 is done, and they
must install version 6 to be current?

Lots of software is certified to run on a specific Java version (or
certified to run on a specific app server version that is certified
to run on a specific Java version).

Upgrading may cost millions of dollars in test.

So SUN has an EOL policy where they support older versions
after newer versions has come out.

Other software companies do the same.

Let us take a piece of software that most people know: Windows.

Windows Vista was released in 2007. Windows 7 is supposed to show
up sometime 2009-2010.

But Windows XP has full support until 2009 and some support
(including security fixes) until 2014.

I'm running windows 98. I have installed version 1.6.0_07. Is it
"bad" (unstable) that I'm running 1.6.x on windows 98 - instead of
1.5.x ???

I think that Sun changed the installer so that I can't install a newer
update for 1.6.x. Why did they do that?

MS stopped security updates for Windows 98 in 2006.

I will consider it very risky to use Windows 98 for internet
usage.

Windows 98 is not supported for Java 1.6 according to:
http://java.sun.com/javase/6/webnotes/install/system-configurations.html

so I am not surprised that it does not work now. I am more
surprised that it has ever worked.

Windows 98 Second Edition and Windows ME are still supported
in Java 1.5, so latest update of 1.5 should be the way to go
for Windows 98 (assuming Second Edition).

Is it true that if I don't un-install older JRE versions then my
system will be vulnerable to any exploits for the old versions even if
I have a newer version installed as well?

Immediate answer: no, because applets will run in a specific
Java version usually the latest installed.

But thinking about it: maybe, I know that Java Web Start has the
ability to specify a given Java version.

Arne

 

[Arne Vajhøj]

Windows 98 is pretty unstable to
begin with, and not suitable for server-style applications.

Multithreading sucks in Windows 95/98/ME, so they are indeed
unusable for server usage.

But they can be used for Java.

I wrote all my first Java code on Windows 95. With dual
boot to NT 4.0 when I needed to test some multithreaded
stuff.

A long time ago.

Arne

 

[sm5w2]

I don't understand why sun [sic] maintains 2 different
versions of the JRE.

Actually, despite their claims to have relegated 1.3 and 1.4
to obsolescence, they maintain four and are developing a fifth.

As for why, it is extremely common for vendors to maintain
more than one version of a product.
However, the vendor cannot force the customer to upgrade,
so if Sun were to go autocratic like that, they likely
would find it to be ineffective.

What is the difference in telling some to upgrade from 1.6.7 to 1.6.10
vs telling them to upgrade from 1.5.15 to 1.6.10 ???

It's not like the end user of the JRE can actually "see" or "touch" or
otherwise directly experience the JRE, unlike the case where microsoft
maintains several different versions of Windows simultaneously.

I see the JRE a lot like flash or quicktime. You don't see different
streams or forks of those being maintained for several years
simultaneously.

I'm running windows [sic] 98. I have installed version
1.6.0_07. Is it "bad" (unstable) that I'm running 1.6.x
on windows [sic] 98 - instead of 1.5.x ???

That depends on what you want to do.

Why? What is the JRE designed for? Isin't the JRE designed for the
general user, desktop system? We're not talking about developer or
server situation.

Windows 98 is pretty unstable to begin with, and not
suitable for server-style applications.

Never said I had server situation in mind. Again, the JRE is for the
general user to experience java web or application content - no?

And win-98 was once unstable back in 1999 and 2000 when most systems
had 16 or 32 mb of ram and Microsoft low-balled the system specs (as
they usually do) and there were buggy hardware drivers (like for agp
video). Once you install win-98 on a P3 or P4 with 512 mb of memory
and the drivers got better, it's pretty stable.

I don't believe that they did that, therefore it is
meaningless to ask why.

Java 6 update 7 is the last version you can install on Win9x (they
have changed/modified installer starting with update 10).

I doubt it. Of what exploits do you speak?

The way I understand it, a web page can be written such that the web-
code can specify that a particular version of java or a particular
version of JRE should be used to render the web-content. So if there
is a known exploit for a particular version of JRE, a hacker can
create a web page that will force the victim's PC to use the older JRE
(if it's installed) to render the web-page, with the intent of forcing
the exploit to occur on the victim's PC, even if the victim has a
newer (and non-vulnerable) version of JRE installed.

For some reason, when each newer version of the JRE is installed, the
older versions remain installed too. Therefor many systems that have
their JRE's updated will always still have the older ones still
installed and operable even if the user think's they're not.

There are many known java / JRE exploits - I'm not referring to any
specific one.

Because Sun maintains all four extant versions of Java
and is developing a fifth, bugs involving exploits tend
to get fixed even for the older versions.

Yes, but for some reason, Sun has designed the JRE install packages to
NOT remove the previous JRE when a newer version is installed.
Therefore any system that gets an updated JRE will still have all
older JRE's present and functional on the system, and a malicious web-
page can force the use of the older JRE (or so I've been told) thereby
triggering any exploit that the older JRE is known to be vulnerable
to.

Are you concerned about some specific exploit that
you believe has not been fixed in the older
versions? Which older versions?

Again, I am not speaking about any specific older version or exploit.

I'm speaking about the general concept that older versions of the JRE
are NOT un-installed by the installer when a new JRE is installed.
For some reason Sun configured the installer this way (I don't know
why - many people wonder why).

And if a given system has one (or more) older versions of the JRE
residing on it, they are all functional, and malicious web-content can
exploit the existence of older versions of the JRE on any system even
if the system also has the most recent JRE.

 

[Arne Vajhøj]

I don't understand why sun [sic] maintains 2 different
versions of the JRE.

Actually, despite their claims to have relegated 1.3 and 1.4
to obsolescence, they maintain four and are developing a fifth.

As for why, it is extremely common for vendors to maintain
more than one version of a product.
However, the vendor cannot force the customer to upgrade,
so if Sun were to go autocratic like that, they likely
would find it to be ineffective.

What is the difference in telling some to upgrade from 1.6.7 to 1.6.10
vs telling them to upgrade from 1.5.15 to 1.6.10 ???

1.6.7 -> 1.6.10 is intended to be only bugfixes, which should
not break existing code.

1.5.15 -> 1.6.10 is intended to implement new functionality, which
may break existing code.

It's not like the end user of the JRE can actually "see" or "touch" or
otherwise directly experience the JRE, unlike the case where microsoft
maintains several different versions of Windows simultaneously.

No. But those that need have to support their software running
on Java knows and cares if they need to test and potentially
make changes to the code.

Why? What is the JRE designed for? Isin't the JRE designed for the
general user, desktop system? We're not talking about developer or
server situation.

No.

My guess is that Java usage is 95% server and 4.9% desktop apps
and 0.1% applets.

And win-98 was once unstable back in 1999 and 2000 when most systems
had 16 or 32 mb of ram and Microsoft low-balled the system specs (as
they usually do) and there were buggy hardware drivers (like for agp
video). Once you install win-98 on a P3 or P4 with 512 mb of memory
and the drivers got better, it's pretty stable.

FAT32 is not as good as NTFS.

The 9x kernel is not good for multithreading.

A lot of the new stuff does not work on 9x.

Arne

 

[sm5w2]

1.6.7 -> 1.6.10 is intended to be only bugfixes, which should
not break existing code.

1.5.15 -> 1.6.10 is intended to implement new functionality, which
may break existing code.

How many times does Sun release a new version because of web-based
vulnerabilities or exploits?

No.

My guess is that Java usage is 95% server and 4.9% desktop apps
and 0.1% applets.

Most people know java and the JRE because it's related to web-browsing
and it's an alternative to activeX (and they create java content for
those people that don't use IE but instead use Firefox etc etc).

So what about these questions:

1) why isin't older versions of JRE automatically un-installed by Sun
JRE installer?

2) can a system with older (and exploitable) versions of JRE be
exploited by specially-crafted web-code even if the system also has
the most current (and not vulnerable) version of the JRE?

 

[Arne Vajhøj]

How many times does Sun release a new version because of web-based
vulnerabilities or exploits?

My guess is that all or almost all updates contain security
fixes, but you can check in the release notes.

Most people know java and the JRE because it's related to web-browsing
and it's an alternative to activeX (and they create java content for
those people that don't use IE but instead use Firefox etc etc).

If we talk about the population in general yes. But if we talk
about Java programmers then the huge majority work on server side
stuff.

So what about these questions:

1) why isin't older versions of JRE automatically un-installed by Sun
JRE installer?

I believe that Java 1.x update N+1 do overwrite 1.x update N, which
should make sense to everyone. I am not sure though, because I don't
use automatic update.

Java 1.x+1 does not overwrite Java 1.x, because some users do want
both versions.

2) can a system with older (and exploitable) versions of JRE be
exploited by specially-crafted web-code even if the system also has
the most current (and not vulnerable) version of the JRE?

See previous answer.

Arne

 

[Wesley MacIntosh]

My guess is that Java usage is 95% server and 4.9% desktop apps
and 0.1% applets.

They'll have a JDK installed though, rather than just a JRE (since the
-server switch doesn't work with the java.exe that comes with the JRE,
but does with the one that comes with the JDK).

 

[sm5w2]

I believe that Java 1.x update N+1 do overwrite 1.x update N, which
should make sense to everyone. I am not sure though, because I don't
use automatic update.

Even with manual update, I don't think it does remove the previous
version.

See previous answer.

Please just answer "yes" or "no" or "I don't know" to question #2.

 

[Arved Sandstrom]

Multithreading sucks in Windows 95/98/ME, so they are indeed unusable
for server usage.

But they can be used for Java.

I wrote all my first Java code on Windows 95. With dual boot to NT 4.0
when I needed to test some multithreaded stuff.

A long time ago.

Arne

One of the main problems with Windows 9.x/ME was the memory model -
namely, fixed system resources. Basically we're talking User and GDI
resources here. So once you had enough applications open, and many (but
not an extravagant) amount of windows and controls and files open, you
hit the wall. IIRC it was relatively easy to lock up Windows 98 with lots
of apps open, none of them particularly large or powerful programs...and
the amount of HD or RAM you had was basically irrelevant.

The main reason I switched over from Windows 98 to 2000 was to change to
the NT memory model. My development projects at the time were pounding on
system resources.

AHS

 

[Arne Vajhøj]

Even with manual update, I don't think it does remove the previous
version.

http://java.sun.com/javase/6/docs/technotes/guides/jweb/otherFeatures/jre_install.html

says:

<quote>
Patch-in-place configuration

The patch-in-place mode implies that when a version of the JRE exists on
a machine, any updates belonging to the same JRE family will be done in
place, meaning, the existing JRE will be patched with changes. A JRE is
installed in patch-in-place mode by default. The default installation
directory is c:/Program Files/Java/jre<n> where n is the Java SE minor
version number (for example, n = 6 for version 1.6.0_10).

For example, if a user has previously installed JRE 6u10 in the
c:/Program Files/Java/jre6 directory, and now attempts to install JRE
6u14, the version 6u14 installer does not create a new directory.
Instead, it updates the pre-existing c:/Program Files/Java/jre6
directory with the new 6u14 content. The user is left with the 6u14 JRE
only. The 6u10 JRE no longer exists.
Static configuration

When a JRE is installed in the static mode, it will not be updated in
place by newer versions. A later version of the same JRE family will be
installed in a separate directory. This mode ensures that vendors, who
require a specific version of the JRE for their product, can be certain
that the JRE will not be overwritten by a newer version.

Some of the characteristics of a static JRE installation are as follows:

* A static JRE installation (example: 6u15) will ignore a previous
patch-in-place installation of another JRE (example: 6u10)
* A static JRE installation is never overwritten by another JRE version
* When a newer JRE version is present (example: 6u15), older JRE
versions ( example: 6u12) are installed in static mode only
* A patch-in-place JRE can be overwritten by a static JRE
installation of the same version. The user will be left with one static
JRE installation.

The default installation directory of a static JRE is of the form
c:/Program Files/Java/jre<version>. For example, by default, a static
JRE for Java SE 6u10 will be installed in the directory c:/Program
Files/Java/jre1.6.0_10.
</quote>

But it seems to be a new feature in 1.6u10.

So it is fixed, but only very recently.

Please just answer "yes" or "no" or "I don't know" to question #2.

See previous answer.

Arne

 

[Arne Vajhøj]

They'll have a JDK installed though, rather than just a JRE (since the
-server switch doesn't work with the java.exe that comes with the JRE,
but does with the one that comes with the JDK).

Correct. Even though it is possible to run some server apps
with JRE, then they practically always use JDK. Besides the
reason you give, there are also some server apps that rely
on tools.jar.

Arne

 

[Arved Sandstrom]

I don't understand why sun [sic] maintains 2 different versions of
the JRE.

Actually, despite their claims to have relegated 1.3 and 1.4 to
obsolescence, they maintain four and are developing a fifth.

As for why, it is extremely common for vendors to maintain more than
one version of a product.
However, the vendor cannot force the customer to upgrade, so if Sun
were to go autocratic like that, they likely would find it to be
ineffective.

What is the difference in telling some to upgrade from 1.6.7 to 1.6.10
vs telling them to upgrade from 1.5.15 to 1.6.10 ???

It's not like the end user of the JRE can actually "see" or "touch" or
otherwise directly experience the JRE, unlike the case where microsoft
maintains several different versions of Windows simultaneously.

I see the JRE a lot like flash or quicktime. You don't see different
streams or forks of those being maintained for several years
simultaneously.

Well, yes you do, actually. Adobe has a stated policy of maintaining the
current and previous major releases for example. Check out Apple's
Support website and you'll see that they don't abandon older versions of
Quicktime that hastily either.

It's often much easier for the vendor to create a new major version for
new features, and break compatibility with older content, than it is to
try to maintain 100% compatibility with all content ever created. As
another example, there's a lot of PDFs out there that can't be displayed
with the latest Acrobat Reader. Flashplayer and Quicktime are likewise
not completely backwards-compatible.

So what's usually done is to support a reasonable number of major
releases simultaneously.

[ SNIP ]

And win-98 was once unstable back in 1999 and 2000 when most systems had
16 or 32 mb of ram and Microsoft low-balled the system specs (as they
usually do) and there were buggy hardware drivers (like for agp video).
Once you install win-98 on a P3 or P4 with 512 mb of memory and the
drivers got better, it's pretty stable.

Regardless of how much RAM you have, you can't escape the basic
limitations of Windows 98. A person running Windows 2000 on exactly the
same box can do a great deal more than you can.

[ SNIP ]

For some reason, when each newer version of the JRE is installed, the
older versions remain installed too. Therefor many systems that have
their JRE's updated will always still have the older ones still
installed and operable even if the user think's they're not. [ SNIP ]
And if a given system has one (or more) older versions of the JRE
residing on it, they are all functional, and malicious web-content can
exploit the existence of older versions of the JRE on any system even if
the system also has the most recent JRE.

Regardless of Sun's installation philosophies, it's an easily solved
problem. Stick with the latest version your OS supports, and delete
everything else. This of course presupposes that the Java applets and
apps that you run will work with that version.

Refer to http://www.java.com/en/download/faq/remove_olderversions.xml

But as has been pointed out, if older versions are supported, and many of
them still are, they're getting security updates.

AHS

 

[sm5w2]

See previous answer.

I'm sorry, I didn't see the previous answer. Can you repeat it here?

 

[sm5w2]

Regardless of Sun's installation philosophies, it's an easily solved
problem. Stick with the latest version your OS supports, and delete
everything else.

I agree that that is the solution.

But it's still the case that most people who even bother to download
updates to the JRE don't know that the older version(s) will remain
installed.

And my fundamental question remains: If older versions of the JRE
exist on a given system, then is that system vulnerable to known
exploits for the older version(s) - even if a newer (and not
vulnerable) version of the JRE is also installed?

 

[Lew]

And my fundamental question remains: If older versions of the JRE
exist on a given system, then is that system vulnerable to known
exploits for the older version(s) - even if a newer (and not
vulnerable) version of the JRE is also installed?

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?

 

[sm5w2]

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.

What I mean is this.

Say that a system has any non-specific version of JRE installed (sake
of argument, say it has 1.5.06). A vulnerability is discovered for
1.5.06 (let's call it Exploit_06). Sun releases JRE version 1.5.07
that is not vulnerable to Exploit_06.

A user downloads the off-line install package for JRE 1.5.07 and runs
it. JRE 1.5.07 is now installed. It's been the experience of many
observers of the computer security and malware scene that the previous
version of the JRE (1.5.06 in this case) was NOT un-installed. Now
the system has both versions (1.5.06 and 1.5.07) installed. The user
probably doesn't know that.

Now let's say that malicious web-code is devised and deployed to
trigger the Exploit_06 vulnerability. The user exposes his system to
the malicious code. The popular thinking in security circles is that
the malicious code can specify or instruct the host PC to use a
specific version of the JRE if it's installed on a system. Naturally,
it must be within the normal code base or instruction set of Java for
such a command or instruction to exist.

If such a mechanism does exist, then it would seem to be a huge
vulnerability to allow web-code to specify that a particular version
of the JRE should be used to execute the code, but this can really
only be leveraged if the default behavior of the JRE installer code is
to NOT un-install previous versions (ie previous patch or update sub-
version) of the JRE.

I don't know if I've gotten a clear answer here as to whether or not
the default behavior of the end-user on-line or off-line JRE installer
will un-install any previous patch-level sub-version. In my example
above, will the 1.5.07 installer remove the previous 1.5.06
installation? Will the 1.5.17 installer remove 1.5.16 or even all
previous 1.5.x versions?

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)

What if we're talking about malicious web-code (and NOT an app) ?

hope the user has that version installed (which cannot be
guaranteed)

No it can't be, but the mal-code is dependent on the presence of the
specific vulnerable version so it might as well try to ask for it if
the exploit is going to succeed.

and depend on the user not having kept it up to date.

Again, even if the user has an up-to-date JRE version, does the
presence of an installed-and-still-functional older version make the
presence of the newer version irrelevant?

(again, as I describe it, 1.5.09 is a newer "version" when compared to
1.5.08. You people may not consider them to be different versions,
and if not then I don't know what you call them).

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.

??

You have got to be kidding. I bet if you look at the average home or
SOHO PC, that it will have an old version of Java installed, that it
will not be doing any automatic java updates, and there are MILLIONS
more "casual" users than "professional" computer users or developers.

Has your research uncovered any such incidents?

There are 26 historical security advisories for Sun Java JRE 1.5.x:

http://secunia.com/advisories/product/4228/?task=advisories

There are 11 historical security advisories for Sun Java JRE 1.6.x:

http://secunia.com/advisories/product/12878/?task=advisories

Many or most of those 37 advisories rank high (4 out of 5) on the
criticality scale.

Some examples of discussions about those vulnerabilities:

http://isc.sans.org/diary.html?storyid=2934

"As we’ve confirmed that exploits such as the one described in this
diary are in the wild, take a minute or two and confirm that you’re
running the latest version."

http://www.vnunet.com/vnunet/news/2172403/java-exploits-brewing

"Attackers have released exploit code targeting two previously patched
flaws in Sun Microsystems' Java Runtime Environment (JRE) and Java
Software Development Kit (SDK)."

See also:

http://www.securiteam.com/securitynews/6M00E0ANFO.html