Java JRE (1.4.2) - doesn't work on 2000 server ???

[BertieBigBollox]

Installed Java JRE 1.4.2 on Windows 2000 server (with SP4 etc). Anyway,
I've got an app that uses Java and this part doesn't work at all. It
seems to pop up a windows temporarily and then nothing happens.

How can I troubleshoot Java? Is there any way I can test the
installation to see if Java is working?

I've previously got this all working on Windows 2000 Pro, but now I'm
trying 2000 server.

(BTW. Yes, I know theres a later version of Java JRE but for various
reasons we have to use v1.4.2).

 

[Sundar The Great]

The JRE 1.4.2 works on windows 200 Server machine. Its working in my
PC. I wonder why it doesnt work in urs!!

-Sundar

 

[BertieBigBollox]

The JRE 1.4.2 works on windows 200 Server machine. Its working in my
PC. I wonder why it doesnt work in urs!!

-Sundar

Got it working now. The app in questiin was playing up. Fixed by reboot.

 

[David H. Lipman]

From: <[email protected]>

| Installed Java JRE 1.4.2 on Windows 2000 server (with SP4 etc). Anyway,
| I've got an app that uses Java and this part doesn't work at all. It
| seems to pop up a windows temporarily and then nothing happens.
|
| How can I troubleshoot Java? Is there any way I can test the
| installation to see if Java is working?
|
| I've previously got this all working on Windows 2000 Pro, but now I'm
| trying 2000 server.
|
| (BTW. Yes, I know theres a later version of Java JRE but for various
| reasons we have to use v1.4.2).

Remove it ASAP !


If you are using any version of Sun Java that is prior to JRE Version 5.0 update 5,
then you are strongly urged to remove any/all versions that are prior to JRE/JSE
Version 5.0 update 5. There are vulnerabilities in them and they are actively being
exploited.

http://sunsolve.sun.com/search/document.do?assetkey=1-26-102171-1

Therefore, it is highly suggested that if there are any prior versions of Sun Java
to Version 5 on the PC that they be removed and Sun Java JRE/JSE Version 5.0 Update 7
be installed ASAP.

Simple check, look under...
C:\Program Files\Java

The only folder under that folder should be the latest version...

C:\Program Files\Java\jre1.5.0_07


http://www.java.com/en/download/manual.jsp

 

[BertieBigBollox]

From: <[email protected]>

| Installed Java JRE 1.4.2 on Windows 2000 server (with SP4 etc). Anyway,
| I've got an app that uses Java and this part doesn't work at all. It
| seems to pop up a windows temporarily and then nothing happens.
|
| How can I troubleshoot Java? Is there any way I can test the
| installation to see if Java is working?
|
| I've previously got this all working on Windows 2000 Pro, but now I'm
| trying 2000 server.
|
| (BTW. Yes, I know theres a later version of Java JRE but for various
| reasons we have to use v1.4.2).

Remove it ASAP !


If you are using any version of Sun Java that is prior to JRE Version 5.0 update 5,
then you are strongly urged to remove any/all versions that are prior to JRE/JSE
Version 5.0 update 5. There are vulnerabilities in them and they are actively being
exploited.

http://sunsolve.sun.com/search/document.do?assetkey=1-26-102171-1

Therefore, it is highly suggested that if there are any prior versions of Sun Java
to Version 5 on the PC that they be removed and Sun Java JRE/JSE Version 5.0 Update 7
be installed ASAP.

Simple check, look under...
C:\Program Files\Java

The only folder under that folder should be the latest version...

C:\Program Files\Java\jre1.5.0_07


http://www.java.com/en/download/manual.jsp

Like I said, unfortunately, we are forced to use Java JRE v1.4.2

 

[David H. Lipman]

From: <[email protected]>

|
| Like I said, unfortunately, we are forced to use Java JRE v1.4.2

Then you are at risk !

Like I stated, that version is vulnerable and is actively being Exploited !

 

[Eric Sosman]

David H. Lipman wrote On 07/26/06 17:00,:

From: <[email protected]>

|
| Like I said, unfortunately, we are forced to use Java JRE v1.4.2

Then you are at risk !

Like I stated, that version is vulnerable and is actively being Exploited !

You're leaving out the update levels, and that makes
a difference. Go back to the Web page you cited earlier
and read it again; you will find that some 1.4.2 versions
are vulnerable and some are fixed. You will also find
that some 1.5.0 versions are vulnerable and some are fixed;
neither "1.4.2" nor "1.5.0" is enough information to tell
whether a system is or isn't at risk.

For 1.4.2, versions 1.4.2_09 and earlier are described
as vulnerable, with fixes in 1.4.2_10 and later. Download
1.4.2 today, and you'll get 1.4.2_12.

For 1.5.0, versions 1.5.0_05 and earlier are described
as vulnerable, with fixes in 1.5.0_06 and later. Download
1.5.0 today, and you'll get 1.5.0_07.

In short, the fixes have been available for a while
now. There is every reason to go check your Java version,
but no reason to panic. Nor is there an imperative to
abandon 1.4.2 (or even 1.3.1!) in response to these issues;
all are addressed in the current update levels for all
three JRE versions. If you're running a vulnerable JRE
you should certainly upgrade, but you can stick with the
familiar Java version if you want.

(Disclaimer: I work for Sun, but do not speak for Sun.)

 

[David H. Lipman]

From: "Eric Sosman" <[email protected]>


|
| You're leaving out the update levels, and that makes
| a difference. Go back to the Web page you cited earlier
| and read it again; you will find that some 1.4.2 versions
| are vulnerable and some are fixed. You will also find
| that some 1.5.0 versions are vulnerable and some are fixed;
| neither "1.4.2" nor "1.5.0" is enough information to tell
| whether a system is or isn't at risk.
|
| For 1.4.2, versions 1.4.2_09 and earlier are described
| as vulnerable, with fixes in 1.4.2_10 and later. Download
| 1.4.2 today, and you'll get 1.4.2_12.
|
| For 1.5.0, versions 1.5.0_05 and earlier are described
| as vulnerable, with fixes in 1.5.0_06 and later. Download
| 1.5.0 today, and you'll get 1.5.0_07.
|
| In short, the fixes have been available for a while
| now. There is every reason to go check your Java version,
| but no reason to panic. Nor is there an imperative to
| abandon 1.4.2 (or even 1.3.1!) in response to these issues;
| all are addressed in the current update levels for all
| three JRE versions. If you're running a vulnerable JRE
| you should certainly upgrade, but you can stick with the
| familiar Java version if you want.
|
| (Disclaimer: I work for Sun, but do not speak for Sun.)
|

Since you work for Sun...

Explain why the bloody software has to go and download a new version and NOT remove teh old
version. The problem here is the the affected platform has many versions. Besides the fact
that it wastes space, the malware knows that the vulnerable versions are not removed auto
amtically and even though tyou are running the current version, the malware (such as the
Vundo trojan and Virtuomunde Adware) will seek out the vulnerable versions to exploit.

 

[Eric Sosman]

David H. Lipman wrote On 07/26/06 20:01,:

From: "Eric Sosman" <[email protected]>
| [...]
| (Disclaimer: I work for Sun, but do not speak for Sun.)
|

Since you work for Sun...

Explain why the bloody software has to go and download a new version and NOT remove teh old
version.

Well, that would be one of those areas where I *really*
don't speak for Sun ...

The problem here is the the affected platform has many versions. Besides the fact
that it wastes space, the malware knows that the vulnerable versions are not removed auto
amtically and even though tyou are running the current version, the malware (such as the
Vundo trojan and Virtuomunde Adware) will seek out the vulnerable versions to exploit.

.... but I'll speculate, with the understanding that this is
*only* speculation and *not* any kind of Official Say-So.
(If people think I'm being overcautious with the disclaimers,
just look at the nature of David's follow-up question and
how quickly it was fired off.)

If I'm trying to maintain a production system, upgrades
and patches and stuff are a big source of worry. I may have
great faith that Sun and IBM and BEA and Oracle have all
tested their products and their product upgrades with care,
but I'm also aware that they probably haven't tested the
exact combination of components from all four that I happen
to be using. And then there are the home-grown applications
my own shop's programmers have turned out ... What's going
to happen when I discover that upgrading both the Sun piece
and the BEA piece causes the Oracle piece to run just a wee
bit faster, thus exposing an unsuspected race condition in
the home-grown app that books all our sales?

Unforeseen version interactions are a fact of life, an
unfortunate fact but a fact nonetheless. So I test all the
new stuff as best I can on a non-production machine, and then
I cross my fingers, hold my breath, and apply the upgrade to
my production system -- and one thing I've made *really* sure
of is that I have a quick and reliable way to return to the
status quo ante if anything goes wrong.

I would be *really* *not* *pleased* if the upgrade were
to wipe out the old version automatically! It may only happen
once in a hundred times that I need to do an emergency roll-
back in the middle of the night, but on that hundredth time I
*really* need to be able to do it just as smoothly and quickly
as I can. I do *not* want to go back to some vendor's web site
and start hunting for downloads of obsoleted versions and then
hoping I can recall how I answered the installation script's
questions; I want the old stuff still sitting on the system,
unaltered and ready to roll as soon as I change an environment
variable or re-target a symlink or flip a registry key or
whatever.

Not everyone has (or needs) quite such a mind set; some
people are perfectly happy to just click "Do to me whatever
you like" on a vendor's product maintenance page, and watch
the pretty lights while the new stuff installs automagically.
(My impression is that these are the same people who have
never heard of backups.) If I were designing Java's upgrade
procedures -- which I'm not; this is all speculation, right? --
I would consider it more important to allow a careful person
to do his job carefully than to make it easy for a carefree
person to be careless.

In an ideal world, system maintenance would be easy --
heck, in an ideal world it would be unnecessary! But even
though maintenance is harder than it might be, given the
current state of technology I don't think it's an awful lot
harder than it must be.

 

[David H. Lipman]

From: "Eric Sosman" <[email protected]>

|
| David H. Lipman wrote On 07/26/06 20:01,:|>> [...]
|>> (Disclaimer: I work for Sun, but do not speak for Sun.)
|>>|
| Well, that would be one of those areas where I *really*
| don't speak for Sun ...
||
| ... but I'll speculate, with the understanding that this is
| *only* speculation and *not* any kind of Official Say-So.
| (If people think I'm being overcautious with the disclaimers,
| just look at the nature of David's follow-up question and
| how quickly it was fired off.)
|
| If I'm trying to maintain a production system, upgrades
| and patches and stuff are a big source of worry. I may have
| great faith that Sun and IBM and BEA and Oracle have all
| tested their products and their product upgrades with care,
| but I'm also aware that they probably haven't tested the
| exact combination of components from all four that I happen
| to be using. And then there are the home-grown applications
| my own shop's programmers have turned out ... What's going
| to happen when I discover that upgrading both the Sun piece
| and the BEA piece causes the Oracle piece to run just a wee
| bit faster, thus exposing an unsuspected race condition in
| the home-grown app that books all our sales?
|
| Unforeseen version interactions are a fact of life, an
| unfortunate fact but a fact nonetheless. So I test all the
| new stuff as best I can on a non-production machine, and then
| I cross my fingers, hold my breath, and apply the upgrade to
| my production system -- and one thing I've made *really* sure
| of is that I have a quick and reliable way to return to the
| status quo ante if anything goes wrong.
|
| I would be *really* *not* *pleased* if the upgrade were
| to wipe out the old version automatically! It may only happen
| once in a hundred times that I need to do an emergency roll-
| back in the middle of the night, but on that hundredth time I
| *really* need to be able to do it just as smoothly and quickly
| as I can. I do *not* want to go back to some vendor's web site
| and start hunting for downloads of obsoleted versions and then
| hoping I can recall how I answered the installation script's
| questions; I want the old stuff still sitting on the system,
| unaltered and ready to roll as soon as I change an environment
| variable or re-target a symlink or flip a registry key or
| whatever.
|
| Not everyone has (or needs) quite such a mind set; some
| people are perfectly happy to just click "Do to me whatever
| you like" on a vendor's product maintenance page, and watch
| the pretty lights while the new stuff installs automagically.
| (My impression is that these are the same people who have
| never heard of backups.) If I were designing Java's upgrade
| procedures -- which I'm not; this is all speculation, right? --
| I would consider it more important to allow a careful person
| to do his job carefully than to make it easy for a carefree
| person to be careless.
|
| In an ideal world, system maintenance would be easy --
| heck, in an ideal world it would be unnecessary! But even
| though maintenance is harder than it might be, given the
| current state of technology I don't think it's an awful lot
| harder than it must be.
|

Based upon what you stated...

The there should NOT be an automatic stub installed to download and install a new version.
I hate it, really hateit, when software decides that it should install a stub to check for
updates. It is a waste of memory and resources and causes confusion to the LAN user.

Additionally the software defaults to an unlimited cache. That's certainly a wasted. I was
just at a Dell PC Today that had no less that 6 different versions of Sun Java installed and
according the "Add/Remove Programs" applet, the average version consume 140MB. That's
~.84GB.

All that is needed is a cache of between 10 ~ 50MB. I set the cache to 10MB on all my
managed platforms.

 

[BertieBigBollox]

From: <[email protected]>

|
| Like I said, unfortunately, we are forced to use Java JRE v1.4.2

Then you are at risk !

Like I stated, that version is vulnerable and is actively being Exploited !

Unfortunately, we're tied to what version of Java the application
software that uses it supports. At the moment, they only actively
support v1.4.2 although it probably does work with v1.5.

This is a pretty common problem with software integration. I remember
having to use Solaris 2.5.1 for years even though Solaris 2.8 was
available just because our software worked on 2.5.1 and was never
tested on 2.8.

However, with regards to being exploited - this is a closed secure
network so there shouldn't be a problem with hacking etc.

 

[David H. Lipman]

From: <[email protected]>


| Unfortunately, we're tied to what version of Java the application
| software that uses it supports. At the moment, they only actively
| support v1.4.2 although it probably does work with v1.5.
|
| This is a pretty common problem with software integration. I remember
| having to use Solaris 2.5.1 for years even though Solaris 2.8 was
| available just because our software worked on 2.5.1 and was never
| tested on 2.8.
|
| However, with regards to being exploited - this is a closed secure
| network so there shouldn't be a problem with hacking etc.

I hope it is a "closed" network. Good Luck !