Community
Participate
Working Groups
20011206, 20011211: It seems that AllTypesSearchEngine returns anonymous classes in some rare cases. I'm not sure if this is intended. 1. Get a hold of Sun's Java Mail 1.2 API implementation. 2. Create an empty project. 3. Add mail.jar as external jar to build path. 4. Press on 'Open a type in the Editor'. 5. Observe the log file ('type name is empty'). I'm putting a workaround for this until it's clear what's going on, see bug #6385. The anonymous classes returned are javax.mail.Folder$1 javax.mail.Service$1 It's also strange that I never observed this problem before using the Java Mail API.
Are they only located in binaries ?
I only have a jar file of the mail API. I don't know if the same behaviour would would happen with source files. BTW, the anonymous classes I mentioned are the only ones in the whole jar file.
I tried it with the sources (to find a workaround) but experienced exactly the same behavior.
The problem with javax/mail/Service$1.class and javax/mail/Folder$1.class is that these two .class file are not compiled according to the VM specs. An anonymous class should have two entries equals to 0 in the corresponding inner info. For these two classes there is no entry equals to 0. My point of view is that the compiler that compiled these two classes is boggus. On one hand the classfile reader should not add extra checking for invalid class files. But on the other hand all the clients of the classfile readers should not add hacks to protect their code. I think the less worst is to add extra checking in the class file reader. The name of these two classes are empty. I will double-check the consistency of the local classes inside this jar file. It will be much mode difficult to add a proper check if the local classes are not properly built. We need the source of this package in order to be able to recompile it with javac and check the result. It is quite scary to see that .class files provided by Sun cannot be trusted and are not consistent according to the VM specs written by Sun. It could be interesting to get the previous version of the Java Mail API. I think the jar I got was for the version 1.2. Maybe the 1.1 doesn't have the problem.
yes, what I sent you was Mail API 1.2.
It looks like all inner classes in this jar are not properly built according to the VM specs. The class file reader is unable to distinguish the anonymous and the local classes. I don't see a way to fix this. I really need to investigate which compiler compiled this jar archive.
I added an extra check in the class file reader. This handles these invalid .class files. Hopefully we won't have such cases in the future. I found an old classes.zip (JDK 1.1.x) which contains several inner classes with the same bug (for example java.util.ListResourceBundle$1). This .class file has been fixed in the rt.jar provided with JDK1.3. So this sounds like an old javac bug. Released in HEAD.
20020115-I: I thought I could remove the workaround(6385) for this bug, but the anonymous types are still there. Please verify with setting break points in TypeSelectionDialog:154 or removing the workaround by setting filteredList = typeList. Shouldn't this bug be reopened?
Claude, I removed the workaround and I see no anonymous types returned. Do you still have the problem with the mail.jar you sent me? If yes, could you please verify that you have the right version of ClassFileReader? The isAnonymous() method should read: public boolean isAnonymous() { if (this.innerInfo == null) return false; char[] sourceName = this.innerInfo.getSourceName(); return (sourceName == null || sourceName.length == 0); }
I can confirm that the ClassFileReader has this method. I still get empty type names when I have a project with mail.jar as external jar and do an open type.
I think I know what's happening: the index was not recomputed, thus even if you got the fix, it still returns anonymous types. Could you please, exit the workspace and delete the .index files in <workspace>\.metadata\.plugins\org.eclipse.jdt.core, and restart it? This will force all the indexes to be recomputed. Please let me know if this fixes the problem and I will change the internal index version so that they are automaticaly recomputed.
I used a pretty recent workspace to launch eclipse and connected to my old workspace with the mail.jar and it works fine. I didn't need to remove the index files.
