Community
Participate
Working Groups
I20080401-0851 - new workspace - paste to Package Explorer: public class C implements None { public String toString(Arg a) { return null; } public String toString(Arg[] a) { return null; } } - create a second project - add /_pasted_code_/bin to the build of the second project (Java Build Path > Libraries > Add Class Folder...) - add a space to C and save => Warning in log: Warning Thu Apr 03 16:14:04 CEST 2008 The Java indexing could not index /_pasted_code_/bin/C.class. This .class file doesn't follow the class file format specification. Please report this issue against the .class file vendor
I'll take care of this.
Reproduced.
The problem comes from the decoding of the missing types attribute. I am working on it.
The problem comes from the encoding of the attribute. When the same "unresolved" type shows up more than once, the missing types recorded in the .class file didn't match the number of unique entries and "0" was recorded in the .class file. I wonder why the indexes are sorted. I don't see why this is useful. Philippe, any clue on this ?
Created attachment 95688 [details] Proposed fix
Released for 3.4M7. Added regression test in org.eclipse.jdt.core.tests.builder.ErrorsTests#test0107. Philippe, I kept the sorting of the indexes, but I don't really see why we need to do this.
I remove the sorting of indexes as it doesn't change anything at the .class file level.
In fact we don't need to resize since the iteration is done from 0 to numberOfMissingTypes when recording the indexes in the constant pool. The bug was the sorting of indexes which would put all the "0" indexes first. The sorting is now removed and I added a comment to specify why we don't need to resize.
Sorting is used to avoid producing structural changes on statement changes (where missing types would be inverted).
Released a new version that ensures the missing type names are sorting according to their constant pool names.
Verified for 3.4M7 using I20080429-0100
