Community
Participate
Working Groups
Created attachment 140168 [details] Error snapshot Build ID: 20090619-0625 Steps To Reproduce: 1.Add a empty zip file to the project classpath 2.Type sys and press ctrl+space in a java file 3.Eclipse shows Problems during content assist and asking to disable Java proposals to avoid that message.It works fine when I am using zip file with some contents.
>1.Add a empty zip file to the project classpath Why should one do that?
Can reproduce on Eclipse SDK 3.5.
David, please investigate.
(In reply to comment #1) > >1.Add a empty zip file to the project classpath > Why should one do that? We have added empty zip file to our project to make sure that developer check-in the zip file in same location. It 's working fine in previous eclipse versions 3.4.1, 3.4.2. It would be great if i am getting fix for this issue. Thanks in advance.
>It 's working fine in previous eclipse versions 3.4.1, 3.4.2. David, what did we change here?
I reproduced the problem. I can see several exceptions in the .log. These exceptions occur when the compilation unit is opened in an editor. The same exceptions occur in 3.4. java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:203) at java.util.zip.ZipFile.<init>(ZipFile.java:234) at org.eclipse.jdt.internal.core.JavaModelManager.getZipFile(JavaModelManager.java:2419) at org.eclipse.jdt.internal.core.JarPackageFragmentRoot.getJar(JarPackageFragmentRoot.java:152) at org.eclipse.jdt.internal.core.JarPackageFragmentRoot.computeChildren(JarPackageFragmentRoot.java:78) at org.eclipse.jdt.internal.core.JavaProjectElementInfo.initializePackageNames(JavaProjectElementInfo.java:252) at org.eclipse.jdt.internal.core.JavaProjectElementInfo.getProjectCache(JavaProjectElementInfo.java:225) at org.eclipse.jdt.internal.core.JavaProjectElementInfo.newNameLookup(JavaProjectElementInfo.java:290) at org.eclipse.jdt.internal.core.JavaProject.newNameLookup(JavaProject.java:2253) at org.eclipse.jdt.internal.core.SearchableEnvironment.<init>(SearchableEnvironment.java:56) at org.eclipse.jdt.internal.core.SearchableEnvironment.<init>(SearchableEnvironment.java:63) at org.eclipse.jdt.internal.core.CancelableNameEnvironment.<init>(CancelableNameEnvironment.java:26) at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:158) at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:243) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.makeConsistent(ReconcileWorkingCopyOperation.java:190) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:89) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788) at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1242) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:126) I can not reproduce the code assist problem in 3.4. In 3.5 the timeout is reached (the timeout was added in 3.5 and is 5sec). That's why some proposals are missing. In 3.4 the code assist operation take less than 1 sec. Code assist indirectly call BasicSearchEngine.searchAllTypeNames() and this method seems to take most of the time of the code assist operation.
The empty zip file seems to be indexed each time the search request is done, I'm investigating...
Finally, this was not a problem in the index but in the SearchableEnvironment instead due to the fix for bug 250685 in the method findTypes(char[], boolean, boolean, int, ISearchRequestor, IProgressMonitor)... A loop was added making a search request with CANCEL_IF_NOT_READY_TO_SEARCH although the indexes will be never ready as it's not possible to build the one on the empty zip file. I've got a patch for this soon...
Created attachment 140942 [details] Proposed patch
David, could you please review?
Dani, as Olivier is in vacations this week, could you give a +1 to backport this fix for 3.5.1? Then, I can put the fix in the tomorrow's maintenance build... TIA
Created attachment 140951 [details] New proposed patch New patch after David's initial review... This patch also fixes similar potential issue for constructors completion...
I'm OK with fixing this for 3.5.1 and locally to this issue the patch looks good. However, we should wait for the outcome of the fix for bug 281871 which is also exactly in this area. From a client side I found it unexpected that the search index is never finished in the case of an unreadable JAR. I suggest to improve the Javadoc regarding this, especially the constants in IJavaSearchConstants should mention this.
Created attachment 141095 [details] Final patch This patch also fixes issue revealed in bug 281871. Note that as we want to avoid as much as possible to use the model for such operation, the fix gives twice a chance to the indexing to be ready and to perform the search request...
The patch looks good. Use model when indeesx are not ready has currently some limitation. The camel case match is currently not supported and member types are not found. These limitation looks acceptable because this is only when the indexes are not ready. And less proposals is better than no proposals.
(In reply to comment #15) > The patch looks good. > Thanks David Released for 3.6M1 in HEAD stream.
Released for 3.5.1 in R3_5_maintenance stream.
Verified for 3.6M1 using build I20090803-1300
Verified for 3.5.1 using build M20090826-1100
Verified.
