Bug 83083 - [1.5][compiler] NPE while checking bounds of type variable
Summary: [1.5][compiler] NPE while checking bounds of type variable
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 normal with 1 vote (vote)
Target Milestone: 3.1 M7   Edit
Assignee: Kent Johnson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 81916 87138 (view as bug list)
Depends on:
Blocks: 79976 88167
  Show dependency tree
 
Reported: 2005-01-18 07:10 EST by Markus Keller CLA
Modified: 2005-05-11 09:13 EDT (History)
2 users (show)

See Also:


Attachments
Jar file with class B (695 bytes, application/octet-stream)
2005-01-19 11:45 EST, Frederic Fusier CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Keller CLA 2005-01-18 07:10:16 EST
I20050112-1200 + jdt.core v_531b:

In a workspace with an 1.5 jdk, search for declarations of method "add(E)".
=> Log:

Error 2005-01-18 13:03:33.481 An internal error occurred during: "Java Search".
java.lang.NullPointerException
at
org.eclipse.jdt.internal.compiler.lookup.TypeVariableBinding.boundCheck(TypeVariableBinding.java:73)
at
org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.resolve(ParameterizedTypeBinding.java:595)
at
org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:53)
at
org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.superclass(BinaryTypeBinding.java:773)
at
org.eclipse.jdt.internal.compiler.lookup.ClassScope.detectHierarchyCycle(ClassScope.java:972)
at
org.eclipse.jdt.internal.compiler.lookup.ClassScope.detectHierarchyCycle(ClassScope.java:934)
at
org.eclipse.jdt.internal.compiler.ast.SingleTypeReference.getTypeBinding(SingleTypeReference.java:42)
at
org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType(TypeReference.java:141)
at
org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveSuperType(TypeReference.java:104)
at
org.eclipse.jdt.internal.compiler.lookup.ClassScope.findSupertype(ClassScope.java:1066)
at
org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectSuperclass(ClassScope.java:725)
at
org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectTypeHierarchy(ClassScope.java:861)
at
org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.connectTypeHierarchy(CompilationUnitScope.java:243)
at
org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:195)
at
org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:864)
at
org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:928)
at
org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1030)
at
org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:94)
at
org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:196)
at
org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:382)
at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:512)
at org.eclipse.jdt.internal.ui.search.JavaSearchQuery.run(JavaSearchQuery.java:132)
at
org.eclipse.search2.internal.ui.InternalSearchUI$InternalSearchJob.run(InternalSearchUI.java:93)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:66)
Comment 1 Frederic Fusier CLA 2005-01-18 07:51:39 EST
I cannot reproduce in my current working workspace., but got it in another one...
Seems to be a transient issue. I continue to investigate...
Comment 2 Markus Keller CLA 2005-01-18 08:34:50 EST
I reproduced it in a fresh workspace with a single fresh java project whose
project-specific compiler compliance level was set to 5.0.
Comment 3 Frederic Fusier CLA 2005-01-18 08:54:49 EST
This was due to the fact that in my tests, I had JDK 1.5 source files. It only
happens for with Binary types...
I can now reproduce it easily...
Comment 4 Frederic Fusier CLA 2005-01-19 04:47:38 EST
*** Bug 81916 has been marked as a duplicate of this bug. ***
Comment 5 Frederic Fusier CLA 2005-01-19 11:44:44 EST
After loooong time, I was able to reduce the test case and have this NPE without
using Search (thanks Jerome for provided help :-))...

Project hierarchy for test case is:
b83083
  a
    C.java
      package a;
      import p.B;
      public class C extends B {
	public void foo(Object obj) {}
      }
  p
    B.java
      package p;
      public class B<E> extends A<E> {}
    A.java
      package p;
      public class A<E> {
	public void foo(E e) {}
      }

Now export class B in a jar (let say b83083.jar), remove class from package and
put b83083.jar file in class path.

Project looks now as follow:
b83083
  a
    C.java
  p
    A.java
  b83083.jar

and its .classpath is
<?xml version="1.0" encoding="UTF-8"?>
<classpath>
	<classpathentry kind="src" path="src"/>
	<classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/1.5.0"/>
	<classpathentry kind="lib" path="D:/usr/OTI/bugs/external/b83083.jar"/>
	<classpathentry kind="output" path="bin"/>
</classpath>

Now try to edit class C => you get the exception...
Comment 6 Frederic Fusier CLA 2005-01-19 11:45:59 EST
Created attachment 17279 [details]
Jar file with class B

Just to avoid to create class B, jar and remove...
Comment 7 Frederic Fusier CLA 2005-01-20 06:44:35 EST
While implementing bug 75642, I've wrongly changed the fact that bindings were
not resolved for method string patterns with no qualified parameters (typically
"add(E)"...).
I've put back this behavior and released in HEAD. This would hide this issue
while performing this peculiar search.
Comment 8 Philipe Mulet CLA 2005-01-24 12:57:55 EST
Added GenericTypeTest#test469. Problem lies in type hierarchy computation which
comes across an unitialized type variable during bound check.
Comment 9 Kent Johnson CLA 2005-03-06 14:21:51 EST
*** Bug 87138 has been marked as a duplicate of this bug. ***
Comment 10 Kent Johnson CLA 2005-04-29 16:32:40 EDT
Enabled GenericType test.

No longer check bounds in binary type resolution... incremental build will 
detect the errors.
Comment 11 Olivier Thomann CLA 2005-05-11 09:13:29 EDT
Verified in I20050510-0010