Community
Participate
Working Groups
From the Sun webservices pack, there's a jar named jaxb-xjc.jar. Inside this jar are a number of classes, however there is also a second folder containing classes which appears to have an incorrect package fragment. Whenever this is on a project's classpath, refactor operations often fail with a JavaModelException stemming directly from JDT's refusal to recognize "1.0" as a valid package fragment, or at least ignore that part silently. The file is 3 megs. I'll see if I can attach it or not.
The file can be retrieved here :http://www.java2s.com/Code/Jar/JKL/Downloadjaxbxjcjar.htm The error occurs when renaming a method when this jar is on the classpath. A stacktrace could look like the following: java.lang.reflect.InvocationTargetException at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:91) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) Caused by: Java Model Exception: Java Model Status [1.0.com.sun.tools.xjc.reader.xmlschema.bindinfo [in C:\JBoss\jboss-4.2.0.GA\client\jaxb-xjc.jar] does not exist] at org.eclipse.jdt.internal.core.JavaElement.newJavaModelException(JavaElement.java:502) at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:246) at org.eclipse.jdt.internal.core.Openable.openAncestors(Openable.java:504) at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:240) at org.eclipse.jdt.internal.core.SourceRefElement.generateInfos(SourceRefElement.java:107) at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:515) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:252) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:238) at org.eclipse.jdt.internal.core.BinaryMethod.getFlags(BinaryMethod.java:113) at org.eclipse.jdt.internal.corext.util.JavaModelUtil.isVisibleInHierarchy(JavaModelUtil.java:240) at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.uniteWithSupertypes(RippleMethodFinder2.java:407) at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.uniteWithSupertypes(RippleMethodFinder2.java:403) at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.createUnionFind(RippleMethodFinder2.java:384) at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.findAllRippleMethods(RippleMethodFinder2.java:196) at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.getAllRippleMethods(RippleMethodFinder2.java:168) at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.getRelatedMethods(RippleMethodFinder2.java:161) at org.eclipse.jdt.internal.corext.refactoring.rename.RenameMethodProcessor.initializeMethodsToRename(RenameMethodProcessor.java:236) at org.eclipse.jdt.internal.corext.refactoring.rename.RenameMethodProcessor.doCheckFinalConditions(RenameMethodProcessor.java:360) at org.eclipse.jdt.internal.corext.refactoring.rename.RenameVirtualMethodProcessor.doCheckFinalConditions(RenameVirtualMethodProcessor.java:143) at org.eclipse.jdt.internal.corext.refactoring.rename.JavaRenameProcessor.checkFinalConditions(JavaRenameProcessor.java:46) at org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring.checkFinalConditions(ProcessorBasedRefactoring.java:224) at org.eclipse.ltk.core.refactoring.CheckConditionsOperation.run(CheckConditionsOperation.java:85) at org.eclipse.ltk.core.refactoring.CreateChangeOperation.run(CreateChangeOperation.java:121) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800) at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:87) ... 1 more Root exception: Java Model Exception: Java Model Status [1.0.com.sun.tools.xjc.reader.xmlschema.bindinfo [in C:\JBoss\jboss-4.2.0.GA\client\jaxb-xjc.jar] does not exist] at org.eclipse.jdt.internal.core.JavaElement.newJavaModelException(JavaElement.java:502) at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:246) at org.eclipse.jdt.internal.core.Openable.openAncestors(Openable.java:504) at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:240) at org.eclipse.jdt.internal.core.SourceRefElement.generateInfos(SourceRefElement.java:107) at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:515) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:252) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:238) at org.eclipse.jdt.internal.core.BinaryMethod.getFlags(BinaryMethod.java:113) at org.eclipse.jdt.internal.corext.util.JavaModelUtil.isVisibleInHierarchy(JavaModelUtil.java:240) at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.uniteWithSupertypes(RippleMethodFinder2.java:407) at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.uniteWithSupertypes(RippleMethodFinder2.java:403) at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.createUnionFind(RippleMethodFinder2.java:384) at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.findAllRippleMethods(RippleMethodFinder2.java:196) at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.getAllRippleMethods(RippleMethodFinder2.java:168) at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.getRelatedMethods(RippleMethodFinder2.java:161) at org.eclipse.jdt.internal.corext.refactoring.rename.RenameMethodProcessor.initializeMethodsToRename(RenameMethodProcessor.java:236) at org.eclipse.jdt.internal.corext.refactoring.rename.RenameMethodProcessor.doCheckFinalConditions(RenameMethodProcessor.java:360) at org.eclipse.jdt.internal.corext.refactoring.rename.RenameVirtualMethodProcessor.doCheckFinalConditions(RenameVirtualMethodProcessor.java:143) at org.eclipse.jdt.internal.corext.refactoring.rename.JavaRenameProcessor.checkFinalConditions(JavaRenameProcessor.java:46) at org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring.checkFinalConditions(ProcessorBasedRefactoring.java:224) at org.eclipse.ltk.core.refactoring.CheckConditionsOperation.run(CheckConditionsOperation.java:85) at org.eclipse.ltk.core.refactoring.CreateChangeOperation.run(CreateChangeOperation.java:121) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800) at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:87) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
So ultimately the question here is whether sun's jaxb-xjc.jar is out of spec, or is JDT throwing JME's when it shouldn't? Is this a valid jar or not?
"1.0" is clearly not a valid package name. Even javac agrees with this: d:\tests_sources>javac 1.0/*.java 1.0\X.java:1: <identifier> expected package 1.0; ^ 1 error I don't have access to this file. I would need to see if this is actually part of the package name. If yes, we need to see what we can do to support this when it comes from binary types. This is illegal inside source types, but once the type is a binary type, I don't think we need to valid it. It could be obfuscated. This also mean that such type cannot be referenced from user code.
I believe (but don't know for certain) that inside "1.0" was some other source folders, for example: com.sun.codemodel.writer.ZipCodeWriter.class 1.0.com.sun.codemodel.CodeWriter.class And that those inside the 1.0 folder do not claim that their package is "1.0.com.sun.codemodel" but rather that their package is "com.sun.codemodel". Looking inside jaxb-xjc.jar, for example, and looking at the class 1.0/com/sun/tools/xjc/AbortException.class, I can see the class declaration bytecode and it clearly does not incldue "1.0" in the package name. So basically they've put source files in a 1.0 folder but have not made 1.0 part of the package name. The actual file can be downloaded here: http://www.java2s.com/Code/JarDownload/jaxb-xjc.jar.zip (size: 2.7m)
(Use case: renaming a method inside one of the classes in the workspace). I've also noticed this seems to take a lot longer than it should. My project has over 300 jars on its classpath (the logic of that could clearly be debated ;)) however since I'm refactoring / renaming a method of a class inside a workspace project, is it really necessary to scan / validate against all the binary jars on the classpath?
This is a duplicate. Snjezana has already posted this bug in a more coherent manner *and* applied a patch. *** This bug has been marked as a duplicate of bug 293861 ***
