Community
Participate
Working Groups
Build id: 200302060800 Linux RH 8.0 Trying to open a java file for editing with Java Editor fails and gives a pop-up window titled "Problems Opening Editor" with contents "I/O Exception." and OK-button. Nothing is printed to .log. I think the same effect is happening with few previous builds too (I20030205 and with most nigthly builds since 15th-jan.) Opening the same file with Text Editors works fine.
Ok, it fails when trying to open a Java file from an old project. If i create a new project and add a new class the Java editor works just fine.
Gets even more odd; Trying to copy&paste the file which won't open with Java Editor doesn't like to be copy-pasted. Also trying to copy&paste a file which opens with Java Editor doesn't have "Paste" active when trying to paste it to the same package where the no-go Java file is located.
Trying to do "Organize imports" with the no-go file gives an error-pop up, a message in a log and opens the file in text editor. !ENTRY org.eclipse.jdt.ui 4 10001 helmi 07, 2003 00:11:40.289 !MESSAGE Internal Error !STACK 1 org.eclipse.jdt.core.JavaModelException[-1]: java.util.zip.ZipException: Tiedostoa tai hakemistoa ei ole at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:112) at java.util.zip.ZipFile.<init>(ZipFile.java:72) at org.eclipse.jdt.internal.core.JavaModelManager.getZipFile(JavaModelManager.java:1057) at org.eclipse.jdt.internal.core.JarPackageFragmentRoot.getJar(JarPackageFragmentRoot.java:220) at org.eclipse.jdt.internal.core.JarPackageFragmentRoot.computeJarChildren(JarPackageFragmentRoot.java:90) at org.eclipse.jdt.internal.core.JarPackageFragmentRoot.computeChildren(JarPackageFragmentRoot.java:71) at org.eclipse.jdt.internal.core.PackageFragmentRoot.generateInfos(PackageFragmentRoot.java:442) at org.eclipse.jdt.internal.core.Openable.buildStructure(Openable.java:71) at org.eclipse.jdt.internal.core.Openable.openWhenClosed(Openable.java:394) at org.eclipse.jdt.internal.core.PackageFragmentRoot.openWhenClosed(PackageFragmentRoot.java:782) at org.eclipse.jdt.internal.core.Openable.open(Openable.java:346) at org.eclipse.jdt.internal.core.JarPackageFragment.openWhenClosed(JarPackageFragment.java:150) at org.eclipse.jdt.internal.core.Openable.openParent(Openable.java:369) at org.eclipse.jdt.internal.core.CompilationUnit.openParent(CompilationUnit.java:751) at org.eclipse.jdt.internal.core.WorkingCopy.openParent(WorkingCopy.java:398) at org.eclipse.jdt.internal.core.Openable.openWhenClosed(Openable.java:385) at org.eclipse.jdt.internal.core.Openable.open(Openable.java:346) at org.eclipse.jdt.internal.core.WorkingCopy.open(WorkingCopy.java:354) at org.eclipse.jdt.internal.core.CompilationUnit.getWorkingCopy(CompilationUnit.java:609) at org.eclipse.jdt.internal.core.CompilationUnit.getSharedWorkingCopy(CompilationUnit.java:581) at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider.createElementInfo(CompilationUnitDocumentProvider.java:850) at org.eclipse.ui.texteditor.AbstractDocumentProvider.connect(AbstractDocumentProvider.java:302) at org.eclipse.jdt.internal.corext.textmanipulation.TextBufferFactory.acquire(TextBufferFactory.java:85) at org.eclipse.jdt.internal.corext.textmanipulation.TextBuffer.acquire(TextBuffer.java:371) at org.eclipse.jdt.internal.corext.codemanipulation.ImportsStructure.aquireTextBuffer(ImportsStructure.java:538) at org.eclipse.jdt.internal.corext.codemanipulation.ImportsStructure.create(ImportsStructure.java:517) at org.eclipse.jdt.internal.corext.codemanipulation.OrganizeImportsOperation.run(OrganizeImportsOperation.java:527) at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:34) at org.eclipse.jdt.internal.core.JavaModelOperation.execute(JavaModelOperation.java:343) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:671) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1588) at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:2633) at org.eclipse.jdt.internal.ui.actions.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:32) at org.eclipse.jdt.internal.ui.util.BusyIndicatorRunnableContext$BusyRunnable.internalRun(BusyIndicatorRunnableContext.java:107) at org.eclipse.jdt.internal.ui.util.BusyIndicatorRunnableContext$BusyRunnable.run(BusyIndicatorRunnableContext.java:74) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:65) at org.eclipse.jdt.internal.ui.util.BusyIndicatorRunnableContext.run(BusyIndicatorRunnableContext.java:120) at org.eclipse.jdt.ui.actions.OrganizeImportsAction.run(OrganizeImportsAction.java:375) at org.eclipse.jdt.ui.actions.OrganizeImportsAction.run(OrganizeImportsAction.java:257) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:191) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:169) at org.eclipse.jface.action.Action.runWithEvent(Action.java:804) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:450) at org.eclipse.jface.action.ActionContributionItem.handleWidgetEvent(ActionContributionItem.java:398) at org.eclipse.jface.action.ActionContributionItem.access$0(ActionContributionItem.java:392) at org.eclipse.jface.action.ActionContributionItem$ActionListener.handleEvent(ActionContributionItem.java:72) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:77) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:897) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:1502) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1319) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1289) at org.eclipse.ui.internal.Workbench.run(Workbench.java:1272) at org.eclipse.core.internal.boot.InternalBootLoader.run(InternalBootLoader.java:845) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:461) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:247) at org.eclipse.core.launcher.Main.run(Main.java:703) at org.eclipse.core.launcher.Main.main(Main.java:539)
"Tiedostoa tai hakemistoa ei ole" means File or directory doesn't exists.
In Java perspective using "Hierarchical Layout" displays only directories (src/MyApp.ear/AccountEjb.jar). If you click directory name the little triangle (open/collapse) disappears from before the name. Changing back to Flat-layout brings back the little triangles and it's possible to navigate under the directory and find the packages and classes in it. But if trying to open the file with Java Editor you still get I/O-exception.
Could you provide your testcase ? I suspect some JAR is corrupted, and causes some trouble to our tooling (when editing, we will try to resolve references, so as to determine errors as you type). We would need the project causing grief and indications about how to set it up.
This has something to do with Java source folders setup. All the source code is located in few directories under src/MyEar.ear/FirstEJB.jar/, src/MyEar.ear/SecondEJB.jar/ etc. If i remove all Java source folders from Java Build Path->Source i can edit any Java file in Java Editor if browsed from Resource's Navigator. None of the Java-files are visible from Java Perpective (naturally). Here's the original trouble causing .classpath for the project: <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" output="src/IntraFrame.ear/openport-std.jar" path="src/IntraFrame.ear/openport-std.jar"/> <classpathentry kind="src" output="src/IntraFrame.ear/openport-ejb.jar" path="src/IntraFrame.ear/openport-ejb.jar"/> <classpathentry kind="src" path="src/IntraFrame.ear/Navigation-ejb.jar"/> <classpathentry kind="src" output="src/IntraFrame.ear/NewsCategory-ejb.jar" path="src/IntraFrame.ear/NewsCategory-ejb.jar"/> <classpathentry kind="src" output="src/IntraFrame.ear/News-ejb.jar" path="src/IntraFrame.ear/News-ejb.jar"/> <classpathentry kind="src" output="src/IntraFrame.ear/NewsRoleRestrictions-ejb.jar" path="src/IntraFrame.ear/NewsRoleRestrictions-ejb.jar"/> <classpathentry kind="src" output="src/IntraFrame.ear/NewsSection-ejb.jar" path="src/IntraFrame.ear/NewsSection-ejb.jar"/> <classpathentry kind="src" output="src/IntraFrame.ear/SiteNewsCategory-ejb.jar" path="src/IntraFrame.ear/SiteNewsCategory-ejb.jar"/> <classpathentry kind="src" output="src/IntraFrame.ear/SiteSection-ejb.jar" path="src/IntraFrame.ear/SiteSection-ejb.jar"/> <classpathentry kind="src" output="src/IntraFrame.ear/SiteSectionNews-ejb.jar" path="src/IntraFrame.ear/SiteSectionNews-ejb.jar"/> <classpathentry kind="src" output="src/IntraFrame.ear/Template-ejb.jar" path="src/IntraFrame.ear/Template-ejb.jar"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> ... few more J2EE-jars etc..
Is there code somewhere which assumes file system entries ending with .jar are always files and not directories? If you give a directory named "MyEjb.jar" to java.util.zip you'd most certainly get file does not exists-exception. > java.util.zip.ZipException: > Tiedostoa tai hakemistoa ei ole > at java.util.zip.ZipFile.open(Native Method)
This seems to be the case. I renamed directory IntraFrame.ear to IntraFrame, also renamed directory Navigation-ejb.jar to Navigation-ejb and things started working. Java Editor can open the classes inside Navigation-ejb.
Renamed the middle directory IntraFrame back to IntraFrame.ear, (kept name of NavigationEjb -directory as is) things worked fine. Renamed IntraFrame.ear/NavigationEjb to IntraFrame.ear/NavigationEjb.jar and things went broke. So it's seems that a directory ending with .jar is considered to be a normal jar-library and is tried to open (for the purpose of searching the classes in it).
I see. We got tricked into thinking the folder was actually a JAR based on its extension. Note that note all code was assuming so, but one path did actually not protected as it should have. Fixed in latest
Verified.
