FULL PRODUCT VERSION :
"1.8.0_66"
ADDITIONAL OS VERSION INFORMATION :
[Version 6.3.9600]
A DESCRIPTION OF THE PROBLEM :
Installing a new jdk/jre is getting to be an almost impossibly lengthy, complicated, and error-prone chore for the following four reasons:
1. The installer does not preserve the logging.properties file in the public jres (32- and 64-bit).
2. The installer does not preserve/remember any foreign libraries in C:\Program Files\Java\jre1.8.0_66\lib\ext and C:\Program Files (x86)\Java\jre1.8.0_66\lib\ext.
3. The installer does not copy down or otherwise preserve/remember the logging.properties files in the previous jdk.
4. The installer does not copy down or otherwise preserve/remember the foreign libraries in the two previous lib\ext directories in the previous jdks (32- and 64-bit).
Sure, it is possible to write one's own installer that copies all the logging properties files and foreign libraries to a temp directory, calls the Oracle/Java installer, and then writes the saved files back when the installation is complete, but Oracle/Java changes the directory names so frequently, without any warning, that such an installer has to modified for almost every jdk/jre installation.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Just run the installers for 32- and 64-bit versions; they just overwrite all the logging.properties files and preserve nothing in the jre/lib/ext directories.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I expect:
1. The four logging.properties from the previous jres and jdks are preserved the put in the newly installed jres (both public and private).
2. All the foreign libraries in jre/lib/ext in the public and private jres are preserved and put in the newly installed jres (both public and private).
ACTUAL -
When the 32- and 64-bit installers run they destroy literally years of work when they obliterate the logging properties files.
Virtually no homegrown Java program will run after installing the 32- and 64-bit jres because all the foreign libraries are gone.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
None. But no Java program will run that requires a foreign library in the jre/lib/ext directory, and no Java program will output a log because of the senseless restrictions in the logging properties files that ship with installers.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
Write one's own installer that copies all the logging properties files and foreign libraries to a temp directory, calls the Oracle/Java installer, and then writes the saved files back when the installation is complete, but Oracle/Java changes the directory names so frequently, without any warning, that such an installer has to modified for almost every jdk/jre installation.
Furthermore, there are no command-line parameters published for the jdks and jres shipped by Oracle/Java, so any installer one writes can't fully automate the installation process because the new base directory names have to be typed into the installers' UI.
"1.8.0_66"
ADDITIONAL OS VERSION INFORMATION :
[Version 6.3.9600]
A DESCRIPTION OF THE PROBLEM :
Installing a new jdk/jre is getting to be an almost impossibly lengthy, complicated, and error-prone chore for the following four reasons:
1. The installer does not preserve the logging.properties file in the public jres (32- and 64-bit).
2. The installer does not preserve/remember any foreign libraries in C:\Program Files\Java\jre1.8.0_66\lib\ext and C:\Program Files (x86)\Java\jre1.8.0_66\lib\ext.
3. The installer does not copy down or otherwise preserve/remember the logging.properties files in the previous jdk.
4. The installer does not copy down or otherwise preserve/remember the foreign libraries in the two previous lib\ext directories in the previous jdks (32- and 64-bit).
Sure, it is possible to write one's own installer that copies all the logging properties files and foreign libraries to a temp directory, calls the Oracle/Java installer, and then writes the saved files back when the installation is complete, but Oracle/Java changes the directory names so frequently, without any warning, that such an installer has to modified for almost every jdk/jre installation.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Just run the installers for 32- and 64-bit versions; they just overwrite all the logging.properties files and preserve nothing in the jre/lib/ext directories.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I expect:
1. The four logging.properties from the previous jres and jdks are preserved the put in the newly installed jres (both public and private).
2. All the foreign libraries in jre/lib/ext in the public and private jres are preserved and put in the newly installed jres (both public and private).
ACTUAL -
When the 32- and 64-bit installers run they destroy literally years of work when they obliterate the logging properties files.
Virtually no homegrown Java program will run after installing the 32- and 64-bit jres because all the foreign libraries are gone.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
None. But no Java program will run that requires a foreign library in the jre/lib/ext directory, and no Java program will output a log because of the senseless restrictions in the logging properties files that ship with installers.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
Write one's own installer that copies all the logging properties files and foreign libraries to a temp directory, calls the Oracle/Java installer, and then writes the saved files back when the installation is complete, but Oracle/Java changes the directory names so frequently, without any warning, that such an installer has to modified for almost every jdk/jre installation.
Furthermore, there are no command-line parameters published for the jdks and jres shipped by Oracle/Java, so any installer one writes can't fully automate the installation process because the new base directory names have to be typed into the installers' UI.