Bug 153168 - When building, if a needed JAR file is corrupt, you're not told which one
Summary: When building, if a needed JAR file is corrupt, you're not told which one
Status: VERIFIED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.0.1   Edit
Hardware: PC Windows XP
: P3 normal with 1 vote (vote)
Target Milestone: 3.6 M1   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-08 15:32 EDT by Mike Genovese CLA
Modified: 2009-08-03 08:46 EDT (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Genovese CLA 2006-08-08 15:32:24 EDT 
I think this is problem with the build mechanism in Eclipse.
RAD/RWD/WSAD product should show similar behaviour :

When building, if a needed JAR file is corrupt, you get an error of the form:

"Internal Error", with an entry in the ".log" file like:
java.lang.InternalError: jzentry == 0 
        at java.lang.Throwable.<init>(Throwable.java) 
        at java.lang.Throwable.<init>(Throwable.java) 
        at java.util.zip.ZipFile$2.nextElement(ZipFile.java) 
        at org.eclipse.jdt.internal.core.builder.ClasspathJar.findPackageSet(ClasspathJar.java) 
        at org.eclipse.jdt.internal.core.builder.ClasspathJar.isPackage(ClasspathJar.java:148) 
        at org.eclipse.jdt.internal.core.builder.ClasspathJar.findClass(ClasspathJar.java:124) 

Wouldn't it be better to actually get the name of the JAR file the build is having a problem with ?
Running RAD (or eclipse) with "-debug" will get you the information in the ".log" file, but one must KNOW to use it:

Unhandled exception caught in event loop.
Reason:
jzentry == 0,
 jzfile = 73862504,
 total = 10,
 name = C:\appl\as\tis\dslreg\lib\CommonHelper.jar,
 i = 2,
 message = invalid LOC header (bad signature)
Comment 1 Olivier Thomann CLA 2009-06-25 14:18:36 EDT 
It would be ugly to catch InternalError just to handle this case. This is a library issue. In this case, an internal error should not be thrown.
In the JDK6, a ZipError is now thrown in this case. But this cannot be used as long as the project has not moved to JDK6.
Closing as WONTFIX.
Comment 2 Frederic Fusier CLA 2009-08-03 08:46:33 EDT 
Verified for 3.6M1