Community
Participate
Working Groups
ClassFormatException in C:/jars/tudojar.jar|com/ibm/db2os390/sqlj/custom/DB2SQLJProfile.class. Please report this issue to JDT/Core including the problematic document org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.<init>(ClassFileReader.java:342) at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.<init>(ClassFileReader.java:121) at org.eclipse.jdt.internal.core.search.indexing.BinaryIndexer.indexDocument(BinaryIndexer.java:622) at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.indexDocument(JavaSearchParticipant.java:74) at org.eclipse.jdt.internal.core.search.indexing.IndexManager.indexDocument(IndexManager.java:314) at org.eclipse.jdt.internal.core.search.indexing.AddJarFileToIndex.execute(AddJarFileToIndex.java:197) at org.eclipse.jdt.internal.core.search.processing.JobManager.run(JobManager.java:392) at java.lang.Thread.run(Unknown Source)
This message was not issued in 3.2. Would it be possible to get the corresponding .class file for further investigation? Thanks.
If you don't provide this .class file (C:/jars/tudojar.jar|com/ibm/db2os390/sqlj/custom/DB2SQLJProfile.class), there is nothing I can do.
Created attachment 73490 [details] jdbc driver
Created attachment 73491 [details] licence for jdbc driver
Thanks for the data. However it looks like these files are corrupted. Even javap cannot read them. The magic number (0xCAFEBABE) is not there for the entry com/ibm/db2os390/sqlj/custom/DB2SQLJProfile.class. Since the file is corrupted, the binary indexer is right to reject it. We could silently do it instead of logging an error and log an error only in debug mode.
Philippe, Since corrupted .class files seem to be more common than expected, I think we should silently ignore them and log an error only in debug mode. What do you think ?
Being resilient is good. I would also vote for logging rather than raising an exception which looks more our bug. BTW - how do we handle this file when reconciling against it ? Do we ignore it as well ?
Right now we simply log the error. If the user doesn't look in the error view, it won't know that the indexer failed. We cannot open this .class file using the class file reader. It seems that the .class file is corrupted since the magic number (0xCAFEBABE) that starts any .class file is not there. So we cannot open it successfully in the class file editor, we cannot index it, etc. I would say that we should only log in debug mode or simply leaving it as is and then the user knows that something is wrong with this .class file.
*** Bug 205596 has been marked as a duplicate of this bug. ***
Created attachment 80059 [details] Proposed fix
Released for 3.4M3. No regression test added since this concerns only logging for corrupted .class files. The logging is preserved in debug mode, and ignore otherwise.
I changed the message for "ClassFormatException in .... This document seems to be a corrupted .class file. Please report this issue against the .class file vendor". Hopefully this is better than the previous message.
I released a new change. The error is logged even if the debug mode is off, but it is logged as a warning instead of an error. The message has been changed to: "The Java indexing could not index " + this.document.getPath() + ". This .class file doesn't follow the class file format specification. Please report this issue against the .class file vendor"
Verified for 3.4M3 using I20071029-0010
