Community
Participate
Working Groups
Build Identifier: M20100211-1343 Depending on what string we are searching for, the filtering in the "Open type" dialog box often fails with the error: An internal error occurred during: "Items filtering". Class file name must end with .class Complete stack trace is below. This is I believe the same as bug #251504, which is closed as fixed, but it does still seem to be an issue. java.lang.IllegalArgumentException: Class file name must end with .class at org.eclipse.jdt.internal.core.PackageFragment.getClassFile(PackageFragment.java:182) at org.eclipse.jdt.internal.core.search.TypeNameMatchRequestorWrapper.createTypeFromJar(TypeNameMatchRequestorWrapper.java:146) at org.eclipse.jdt.internal.core.search.TypeNameMatchRequestorWrapper.acceptType(TypeNameMatchRequestorWrapper.java:108) at org.eclipse.jdt.internal.core.search.BasicSearchEngine$3.acceptIndexMatch(BasicSearchEngine.java:1111) at org.eclipse.jdt.core.search.SearchPattern.acceptMatch(SearchPattern.java:299) at org.eclipse.jdt.core.search.SearchPattern.findIndexMatches(SearchPattern.java:2124) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.findIndexMatches(MatchLocator.java:264) at org.eclipse.jdt.internal.core.search.PatternSearchJob.search(PatternSearchJob.java:97) at org.eclipse.jdt.internal.core.search.PatternSearchJob.execute(PatternSearchJob.java:63) at org.eclipse.jdt.internal.core.search.processing.JobManager.performConcurrentJob(JobManager.java:276) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.searchAllTypeNames(BasicSearchEngine.java:1122) at org.eclipse.jdt.core.search.SearchEngine.searchAllTypeNames(SearchEngine.java:815) at org.eclipse.jdt.internal.ui.dialogs.FilteredTypesSelectionDialog.fillContentProvider(FilteredTypesSelectionDialog.java:556) at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog$FilterJob.filterContent(FilteredItemsSelectionDialog.java:2182) at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog$FilterJob.internalRun(FilteredItemsSelectionDialog.java:2124) at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog$FilterJob.doRun(FilteredItemsSelectionDialog.java:2096) at org.eclipse.ui.dialogs.FilteredItemsSelectionDialog$FilterJob.run(FilteredItemsSelectionDialog.java:2083) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Reproducible: Always Steps to Reproduce: 1. Open the "Open type" dialog 2. Type in a few letters to start filtering 3. See failure
*** This bug has been marked as a duplicate of bug 286379 ***
This bug looks to be slightly different from bug 286379. If you could give the workspace or the contents in the folder <workspace>/.metadata/plugins/org.eclipse.jdt.core, that could help debug the problem. Please reopen this bug.
Reopened as requested. As per advice given in bug 286379, I just deleted all the contents of the jdt.core folder in an effort to work around this. I expect it will come back though, and when it does I'll provide the .index files.
the wished directory-content is to big (17mb as zip) how i can give you the content?
>the wished directory-content is to big (17mb as zip) >how i can give you the content? Did you try the BigFile option when attaching it?
Can you use the big file option on the attachment page ?
Created attachment 164971 [details] the wished directory-content i hope it helps you to find this annoying problem
Did you still get the problem after having deleted all indexes files and restarted your eclipse session? Also, do you have any other plugins installed on top of Eclipse?
As in our current Eclipse (3.5.2) also in the testet Eclipse 3.6m6 it seems to work for a while after deleting all index-files. But after a (short) while and after using a workingSet-Setting in the OpenType-Dialog this error often reoccures. All of our team have this problem since (i think 3.4). Some of us does now using OpenResource instead of OpenType because of this.
Could you please attach your configuration details? Help>About Eclipse SDK>Installation Details>Configuration. Thx.
Thanks for the zip. I am looking at it. Can you also give the stack trace that you get with 3.6M6? In 3.6M6, the error message has the name of the offending file too. You could just give the .log file in the .metadata directory.
I looked at the index files in the attached folder and didn't find anything suspectable. I am assuming that this folder is taken when the problem occurred. If not, please let me know. I do have one theory for this problem - there would have been clash in the index files names that is used by JDT/Core index manager. One of the jar's corresponding index file name is probably clashing with the project's index file name. To validate this theory, can you please get the logs by turning on the debug options for eclipse. Here are the instructions to get the debug options Create a file called .options in the eclipse folder with the following lines in it. ###### org.eclipse.jdt.core/debug=true org.eclipse.jdt.core/debug/indexmanager=true ###### Then run eclipse as %eclipsec.exe -debug
We will give you the configuration, .log file and will configure the debug-options before, but this all at monday, because the collegue who tests this behavior has doday holidy.
Created attachment 165231 [details] EclipseConfigurationDetails
Created attachment 165232 [details] log we could not find any Logs (whether in the eclipse workspace, in the temp-directory or in the eclipse installatin directory) after adapting der options for eclipse we got the attached debug.log
Thanks for the requested info. I am trying to analyze them. The .log file that I was referring should be present in the .metadata folder in the workspace. If you could reproduce the problem, this file should be generated.
sorry, in this case there is no .log file in the .metadata-directory..
OK, Could you give the complete stack trace with 3.6M6? I am looking for something like the one you had given in this bug description.
we now don't get any stack-trace output - we only have the failure-message-box and no .log-file in .metadata!
(In reply to comment #19) > we now don't get any stack-trace output - we only have the failure-message-box > and no .log-file in .metadata! And you still get the same stack trace than in comment 0?
wie don't get any log-file and therefore not any stack trace, but we write on this issue because we testet 3.6 and the openType problem still occured and therefore i posted this on https://bugs.eclipse.org/bugs/show_bug.cgi?id=286379#c39 and in comment#40 someone said we should reopen this issue here..
> wie don't get any log-file and therefore not any stack trace, > but we write on this issue because we testet 3.6 and the openType problem > still occured and therefore i posted this on > https://bugs.eclipse.org/bugs/show_bug.cgi?id=286379#c39 > and in comment#40 someone said we should reopen this issue here.. I agree with the fact that the bug is reopened, I just wonder how, if you still observe the problem (hence I guess getting the exception described in comment 0) that no .log file was created. There's an inconsistency here I'm trying to understand... Looking at your configuration, could you confirm that using 3.6M6, while using the Open Type dialog, you still get an exception but no .log file is present in the C:\elbtest\.metadata directory? TIA
I am unable to find any problems with the index files or anything wrong with the debug output. Can you give a workspace that I will be able to reproduce from my end?
Removing target as this could not be reproduced so far.
we will make an screenshots-video that shows you the failure. but we suggest you to make an patch that extends the debug-output and we would then test again with this patch. is that an idea?
(In reply to comment #25) > we will make an screenshots-video that shows you the failure. > but we suggest you to make an patch that extends the debug-output and we would > then test again with this patch. is that an idea? We could get started with the screenshots-video -- The screenshots video could help us to determine what the patch could need.
(In reply to comment #25) > we will make an screenshots-video that shows you the failure. > but we suggest you to make an patch that extends the debug-output and we would > then test again with this patch. is that an idea? Before the video, a thing which could simply help us would be to answer the questions I asked in comment 22: > > Looking at your configuration, could you confirm that using 3.6M6, while using > the Open Type dialog, you still get an exception but no .log file is present in > the C:\elbtest\.metadata directory? > > TIA As I said in that comment, there's an inconsistency in the fact that an exception is raised and that there's no .log file in your .metadata directory. I've verified the JDT/UI code and it does not "eat" the exception, hence if one occurs, it *should* be logged and a .log file created...
Created attachment 165423 [details] here is the video that shows the fact
(In reply to comment #28) > Created an attachment (id=165423) [details] > here is the video that shows the fact As I was guessing there's no exception in this video, only an Open Type error dialog saying that the selected type is not found... This is due tot the fact that the offending type is in the Open Type dialog cache but not in the selected working set. Remove all the types in this cache (by selecting one and press 'Delete' until all the type names are removed) and you won't get this error dialog again... :-)
"...dialog saying that the selected type is not found..." -> but it is(!) in the defined working-set! "Remove all the types in this cache (by selecting one and press 'Delete' until all the type names are removed) and you won't get this error dialog again... :-)" -> and we know this tip and do this often, but it helps just for a short while and the problem comes back
(In reply to comment #30) > "...dialog saying that the selected type is not found..." > -> but it is(!) in the defined working-set! Thomas, Maybe it is. But watching the video, I don't see why this belongs to this bug report. This bug report is about: java.lang.IllegalArgumentException: Class file name must end with .class Since the beginning (when the bug was reopened), we are not talking about the same thing. I didn't see any comment about the types not being opened when they belong to a certain working set. This explains the misunderstanding of not having anything inside the .log file. Could you please open a new bug report for this issue? In this case, you will need to provide a small workspace that defines working sets and that reproduces this issue. Thanks.
Sorry, that's not an invalid, but really a duplicate (see bug 286379 comment 7 stack trace which is absolutely identical...) *** This bug has been marked as a duplicate of bug 286379 ***
I think the problem quoted and the error dialog box that came up in the video are because of the same inherent problem -- an improper map between the index files and the components. I couldn't see the contents of the dialog box very clearly. I want to have a good look of the contents in the OpenType dialog box and of the error dialog box. Can you give good images of them?
Created attachment 165528 [details] screenshot of the error here is the screenshot of the error
Maybe a similar but not the same issue (no exception), so please stop reopening this bug and file a new one as Frédéric and Olivier already requested. >Created an attachment (id=165528) [details] [diff] >screenshot of the error Dominik (or Thomas), this looks like the image of a small workspace. Could you just zip it and attach to the new bug report (maybe you need to use the Big File option when attaching). *** This bug has been marked as a duplicate of bug 286379 ***
we can't give you our workspace. a) it's no small workspace and contains many tousends of files. b) it's closed source we will open a new bug, but a workspace we can't supply, because our is big and wie do not know what situation is source of this problem.
Verified. Old problem is still ok in M7.
