P4
FULL PRODUCT VERSION :
java version "1.7.0_02"
Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Windows 7 Pro 64-bit SP 1
EXTRA RELEVANT SYSTEM CONFIGURATION :
None relevant.
A DESCRIPTION OF THE PROBLEM :
When com.sun.nio.zipfs.ZipFileSystemProvider.newFileSystem(*) gets a ZipError, it hides the real error and returns a generic UnsupportedOperationException if the file does not have a ".zip" or ".jar" exception. Hardcoded assumptions like this are horrible and unnecessary. Even worse, the original ZipError is not chained to the new exception as a cause, so the real reason for the exception is totally lost.
Our specific example is our applications project file that is essentially a ZIP, but with our own application specific extension. Migrating to the new nio FileSystems results in lost error resolution, which worked just fine in the old zip file handling we had in place, unless we hack by copying the file so we can rename the extension before opening it.
Please stop hardcoding implementation assumptions. I've run into a few unnecessary cases lately.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
- Change the extension of a zip/jar file to something other than ".zip" or ".jar".
- Try to open it using FileSystems.newFileSystem in a manner that would cause a ZipError (using a non-zip/jar file would probably work, too, but doesn't make the point)
- Experience the horror of getting a generic UnsupportedOperationException with nothing to hint at the real reason for the failure.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
A thrown ZipError.
ACTUAL -
A thrown UnsupportedOperationException with no cause.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
doesn't matter.
REPRODUCIBILITY :
This bug can be reproduced occasionally.
CUSTOMER SUBMITTED WORKAROUND :
Copy the file and change the extension prior to opening it.
java version "1.7.0_02"
Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Windows 7 Pro 64-bit SP 1
EXTRA RELEVANT SYSTEM CONFIGURATION :
None relevant.
A DESCRIPTION OF THE PROBLEM :
When com.sun.nio.zipfs.ZipFileSystemProvider.newFileSystem(*) gets a ZipError, it hides the real error and returns a generic UnsupportedOperationException if the file does not have a ".zip" or ".jar" exception. Hardcoded assumptions like this are horrible and unnecessary. Even worse, the original ZipError is not chained to the new exception as a cause, so the real reason for the exception is totally lost.
Our specific example is our applications project file that is essentially a ZIP, but with our own application specific extension. Migrating to the new nio FileSystems results in lost error resolution, which worked just fine in the old zip file handling we had in place, unless we hack by copying the file so we can rename the extension before opening it.
Please stop hardcoding implementation assumptions. I've run into a few unnecessary cases lately.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
- Change the extension of a zip/jar file to something other than ".zip" or ".jar".
- Try to open it using FileSystems.newFileSystem in a manner that would cause a ZipError (using a non-zip/jar file would probably work, too, but doesn't make the point)
- Experience the horror of getting a generic UnsupportedOperationException with nothing to hint at the real reason for the failure.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
A thrown ZipError.
ACTUAL -
A thrown UnsupportedOperationException with no cause.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
doesn't matter.
REPRODUCIBILITY :
This bug can be reproduced occasionally.
CUSTOMER SUBMITTED WORKAROUND :
Copy the file and change the extension prior to opening it.