Community
Participate
Working Groups
I've seen this more than once in production builds, so there might more behind this than just some solar activity or such: ----------- Expected ------------ ----------\n 1. WARNING in /P1/src/Y.java (at line 1)\n public class Y extends p.X1 {\n ^^\n The type X1 has been deprecated and marked for removal\n ----------\n 2. WARNING in /P1/src/Y.java (at line 3)\n x2.m();\n ^^^\n The method m() from the type X2 has been deprecated and marked for removal\n ----------\n 3. WARNING in /P1/src/Y.java (at line 4)\n return x2.field;\n ^^^^^\n The field X2.field has been deprecated and marked for removal\n ----------\n ------------ but was ------------ ----------\n 1. WARNING in /P1/src/Y.java (at line 1)\n public class Y extends p.X1 {\n ^^\n The type X1 has been deprecated and marked for removal\n ----------\n 2. ERROR in /P1/src/Y.java (at line 2)\n Object foo(p.X2 x2) {\n ^^^^\n p.X2 cannot be resolved to a type\n ----------\n Failure to resolve should be taken lightly ... Happened in ep411I-unit-win32_win32.win32.x86_64_8.0 Locally (on linux with JRE 1.8) I cannot reproduce. Here's the call path that successfully finds p.X2: Util.getZipEntryByteContent(ZipEntry, ZipFile) line: 700 BinaryTypeFactory.rawReadTypeTestForExists(BinaryTypeDescriptor, boolean, boolean) line: 174 BinaryTypeFactory.rawReadType(BinaryTypeDescriptor, boolean) line: 141 BinaryTypeFactory.readType(BinaryTypeDescriptor, IProgressMonitor) line: 136 ClassFile.getJarBinaryTypeInfo() line: 236 ClassFile.existsUsingJarTypeCache() line: 148 NameLookup.seekTypesInBinaryPackage(String, IPackageFragment, boolean, int, IJavaElementRequestor) line: 1379 NameLookup.seekTypes(String, IPackageFragment, boolean, int, IJavaElementRequestor, boolean) line: 1347 NameLookup.findType(String, IPackageFragment, boolean, int, boolean, boolean) line: 949 NameLookup.findType(String, String, boolean, int, boolean, boolean, boolean, IProgressMonitor, IPackageFragmentRoot[]) line: 787 NameLookup.findType(String, String, boolean, int, boolean, IPackageFragmentRoot[]) line: 706 CancelableNameEnvironment(SearchableEnvironment).find(String, String, IPackageFragmentRoot[]) line: 156 CancelableNameEnvironment(SearchableEnvironment).findType(char[], char[][], char[]) line: 469 LookupEnvironment.fromSplitPackageOrOracle(IModuleAwareNameEnvironment, ModuleBinding, PackageBinding, char[]) line: 414 LookupEnvironment.lambda$1(IModuleAwareNameEnvironment, PackageBinding, char[], ModuleBinding) line: 289 617142462.apply(Object) line: not available LookupEnvironment.askForTypeFromModules(ModuleBinding, ModuleBinding[], Function<ModuleBinding,NameEnvironmentAnswer>) line: 384 LookupEnvironment.askForType(PackageBinding, char[], ModuleBinding) line: 288 PackageBinding.getTypeOrPackage(char[], ModuleBinding, boolean) line: 265 MethodScope(Scope).getPackage(char[][]) line: 2980 QualifiedTypeReference.getTypeBinding(Scope) line: 110 My guess would be some caching issue around ClassFile.existsUsingJarTypeCache() but I have no evidence to back this.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
