Bug 193210 - [1.5][compiler] Internal compiler error java.lang.NullPointerException
Summary: [1.5][compiler] Internal compiler error java.lang.NullPointerException
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2.2   Edit
Hardware: PC Linux
: P3 critical (vote)
Target Milestone: 3.3.2   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 207433 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-06-18 17:35 EDT by Ross CLA
Modified: 2008-01-24 07:05 EST (History)
5 users (show)

See Also:
philippe_mulet: pmc_approved+


Attachments
Here is a zip file of our entire project folder. We grant you full use of this code for debugging Eclipse. Please consult with us if you want to use the code for any other purpose. (459.21 KB, application/zip)
2007-06-19 16:45 EDT, Ross CLA
no flags Details
Proposed patch (3.40 KB, patch)
2007-10-24 09:44 EDT, Philipe Mulet CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ross CLA 2007-06-18 17:35:02 EDT
Build ID: M20070212-1330

Steps To Reproduce:
I can only reproduce this on my java code base, although it occurs on every site including Windows Vista, Ubuntu, Red Hat and using Java 1.5 and 1.6 and different versions of Eclipse (including 3.3R4). We can't pin what file causes it, though, because it is inconsistent, but the error's the same.

More information:
We cannot figure out how to get around this bug, so coding and testing for our project is blocked, and we have a deadline in a month, which is why I gave this a high severity. The following is the error Eclipse gives us:

Internal compiler error java.lang.NullPointerException at 
 org.eclipse.jdt.internal.compiler.ast.FieldReference.resolveType
 (FieldReference.java:557) at 
 org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType
 (MessageSend.java:310) at 
 org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType
 (MessageSend.java:310) at 
 org.eclipse.jdt.internal.compiler.ast.ForeachStatement.resolve
 (ForeachStatement.java:353) at 
 org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStat
 ements(AbstractMethodDeclaration.java:432) at 
 org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements
 (MethodDeclaration.java:190) at 
 org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve
 (AbstractMethodDeclaration.java:403) at 
 org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve
 (TypeDeclaration.java:1047) at 
 org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve
 (TypeDeclaration.java:1088) at 
 org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve
 (TypeDeclaration.java:976) at 
 org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve
 (TypeDeclaration.java:1094) at 
 org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve
 (CompilationUnitDeclaration.java:353) at 
 org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:596) at 
 org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:411) at 
 org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile
 (AbstractImageBuilder.java:353) at 
 org.eclipse.jdt.internal.core.builder.BatchImageBuilder.compile
 (BatchImageBuilder.java:171) at 
 org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile
 (AbstractImageBuilder.java:290) at 
 org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build
 (BatchImageBuilder.java:59) at 
 org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:
 241) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build
 (JavaBuilder.java:169) at org.eclipse.core.internal.events.BuildManager
 $2.run(BuildManager.java:603) at org.eclipse.core.runtime.SafeRunner.run
 (SafeRunner.java:37) at 
 org.eclipse.core.internal.events.BuildManager.basicBuild
 (BuildManager.java:167) at 
 org.eclipse.core.internal.events.BuildManager.basicBuild
 (BuildManager.java:201) at org.eclipse.core.internal.events.BuildManager
 $1.run(BuildManager.java:230) at org.eclipse.core.runtime.SafeRunner.run
 (SafeRunner.java:37) at 
 org.eclipse.core.internal.events.BuildManager.basicBuild
 (BuildManager.java:233) at 
 org.eclipse.core.internal.events.BuildManager.basicBuildLoop
 (BuildManager.java:252) at 
 org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:
 285) at org.eclipse.core.internal.events.AutoBuildJob.doBuild
 (AutoBuildJob.java:154) at org.eclipse.core.internal.events.AutoBuildJob.run
 (AutoBuildJob.java:217) at org.eclipse.core.internal.jobs.Worker.run
 (Worker.java:58)

The code base has a heavy and complex use of generics. The odd thing is the error occurs in the code that has not changed much for months. Here is the code for the file it seems to break on for most of us:

package util.graph;

import java.util.Collection;
import java.util.Collections;
import java.util.List;
import java.util.Map;
import java.util.Set;

import util.ArrayCollection;
import util.Grouping;
import util.HashGrouping;
import util.IdentityHashGrouping;
import util.MultiMap;
import util.Tag;
import util.VariaticFunction;
import util.pair.PairedList;

public abstract class RecursiveExpressionGraph<
		G extends RecursiveExpressionGraph<G,V,L>,
		V extends RecursiveExpressionVertex<G,V,L>, L>
		extends ExpressionGraph<G,V,L> {
	protected final Grouping<V> mGrouping = new IdentityHashGrouping<V>();
	
	public RecursiveExpressionGraph() {super(4);}

	public void trimInsignificant() {
		super.trimInsignificant();
		Collection<V> trimmed = new ArrayCollection<V>();
		for (V rep : mGrouping.getRepresentatives())
			if (!getVertices().contains(rep))
				trimmed.add(rep);
		for (V rep : trimmed)
			mGrouping.ungroup(rep);
	}
	
	public V createPlaceHolder() {
		return makeHolderVertex();
	}
	public V createPlaceHolder(L label) {
		return makeHolderVertex(label);
	}
	
	protected abstract V makeHolderVertex();
	protected abstract V makeHolderVertex(L label);
	
	protected interface IVertex<G extends RecursiveExpressionGraph<G,V,L>,
			V extends IVertex<G,V,L>,L> extends ExpressionGraph.IVertex<G,V,L>,
			RecursiveExpressionVertex<G,V,L> {
		public void setParents(Set<V> parents);
		public Set<V> getParents();
		public PairedList<Tag,Object> getTags();
		public void setTags(PairedList<Tag,Object> tags);
	}
	
	protected static abstract class HolderVertex
			<G extends RecursiveExpressionGraph<G,V,L>,
			V extends IVertex<G,V,L>, L> extends ExpressionGraph.Vertex<G,V,L>
			implements IVertex<G,V,L> {
		protected V mReplacement = null;
		
		public HolderVertex(L label) {super(label);}
		
		public L getLabel() {
			return mReplacement == null ? super.getLabel()
					: mReplacement.getLabel();
		}
		
		public boolean hasChildren() {
			return mReplacement != null && mReplacement.hasChildren();
		}
		public boolean hasChildren(V... children) {
			return mReplacement != null && mReplacement.hasChildren(children);
		}
		public boolean hasChildren(List<? extends V> children) {
			return mReplacement != null && mReplacement.hasChildren(children);
		}
		public List<? extends V> getChildren() {
			return mReplacement == null ? Collections.<V>emptyList()
					: mReplacement.getChildren();
		}
		public V getChild(int i) {
			return mReplacement == null ? getChildren().get(i)
					: mReplacement.getChild(i);
		}
		public int getChildCount() {
			return mReplacement == null ? 0 : mReplacement.getChildCount();
		}
		
		public <E> E evaluate(VariaticFunction<L,E,E> evaluator) {
			return mReplacement == null ? evaluator.get(getLabel())
					: mReplacement.evaluate(evaluator);
		}
		public <E> E evaluateVertex(VariaticFunction<? super V,E,E> evaluator) {
			return mReplacement == null ? evaluator.get(getSelf())
					: mReplacement.evaluateVertex(evaluator);
		}
		
		public boolean isPlaceHolder() {return mReplacement == null;}
		
		public void replaceWith(V replacement) {
			if (mReplacement != null)
				throw new IllegalStateException();
			if (replacement.isPlaceHolder())
				throw new IllegalArgumentException();
			boolean hadParents = replacement.hasParents();
			mReplacement = replacement;
			replacement.addParents(mParents);
			mParents = replacement.getParents();
			mReplacement.getTags().addAll(mTags);
			mTags = mReplacement.getTags();
			getGraph().mGrouping.group(mReplacement, getSelf());
			Grouping<V> grouping = null;
			if (hadParents) {
				grouping = new HashGrouping<V>();
				if (mergeParents(grouping)) {
					applyGrouping(grouping);
					grouping = null;
				}
			}
			for (V similar
					: getGraph().mTracker.get(replacement.getChildCount())
					.get(replacement.getLabel())) {
				if (similar.equals(replacement))
					continue;
				if (grouping == null)
					grouping = new HashGrouping<V>();
				if (merge(replacement, similar, grouping)) {
					mergeParents(grouping);
					applyGrouping(grouping);
					break;
				}
			}
		}
		
		protected boolean mergeParents(Grouping<V> grouping) {
			List<MultiMap<L,V>> tracker = getGraph().mTracker;
			boolean anyChange = false;
			for (boolean changed = true; changed; ) {
				changed = false;
				for (int arity = 1; arity < tracker.size(); arity++)
					for (Set<? extends V> verts
							: tracker.get(arity).valueSets()) {
						if (verts.size() <= 1)
							continue;
						for (V left : verts)
							for (V right : verts) {
								if (grouping.isGrouped(left, right))
									continue;
								boolean same = true;
								for (int child = arity; child-- != 0; )
									if (!grouping.isGrouped(
											left.getChild(child),
											right.getChild(child))) {
										same = false;
										break;
									}
								if (same)
									changed |= grouping.group(left, right);
							}
					}
				anyChange |= changed;
			}
			return anyChange;
		}
		
		protected boolean merge(V left, V right, Grouping<V> grouping) {
			if (grouping.isGrouped(left, right))
				return true;
			if (left.isPlaceHolder() || right.isPlaceHolder())
				return false;
			if (left.getChildCount() != right.getChildCount())
				return false;
			if (!left.hasLabel(right.getLabel()))
				return false;
			grouping.group(left, right);
			for (int child = 0; child < left.getChildCount(); child++)
				if (!merge(left.getChild(child), right.getChild(child),
						grouping))
					return false;
			return true;
		}
		
		protected void applyGrouping(Grouping<V> grouping) {
			G graph = getGraph();
			List<MultiMap<L,V>> tracker = graph.mTracker;
			Set<V> vertices = graph.mVertices;
			Map<L,V> leaves = graph.mLeaves;
			Grouping<V> masterGrouping = graph.mGrouping;
			for (V rep : grouping.getRepresentatives())
				for (V friend : grouping.getGroup(rep))
					if (!rep.equals(friend)) {
						vertices.remove(friend);
						if (friend.isLeaf())
							leaves.remove(friend);
						tracker.get(friend.getChildCount())
								.removeValue(friend.getLabel(), friend);
						if (friend.unmakeSignificant())
							rep.makeSignificant();
						rep.addParents(friend.getParents());
						rep.getTags().addAll(friend.getTags());
						for (V associate : masterGrouping.getGroup(friend)) {
							associate.setParents(rep.getParents());
							associate.setTags(rep.getTags());
						}
						masterGrouping.group(rep, friend);
					}
		}
		
		public String toString() {
			return mReplacement == null ? super.toString()
					: mReplacement.toString();
		}
	}
	
	protected static abstract class LeafVertex
			<G extends RecursiveExpressionGraph<G,V,L>,
			V extends IVertex<G,V,L>, L>
			extends ExpressionGraph.LeafVertex<G,V,L> implements IVertex<G,V,L>
			{
		public LeafVertex(L label) {super(label);}
		
		public boolean isPlaceHolder() {return false;}
		public void replaceWith(V replacement) {
			throw new UnsupportedOperationException();
		}
	}
	
	protected static abstract class UniVertex
			<G extends RecursiveExpressionGraph<G,V,L>,
			V extends IVertex<G,V,L>, L>
			extends ExpressionGraph.UniVertex<G,V,L> implements IVertex<G,V,L> {
		public UniVertex(L label, V child) {super(label, child);}
		
		public boolean isPlaceHolder() {return false;}
		public void replaceWith(V replacement) {
			throw new UnsupportedOperationException();
		}
	}
	
	protected static abstract class MultiVertex
			<G extends RecursiveExpressionGraph<G,V,L>,
			V extends IVertex<G,V,L>, L>
			extends ExpressionGraph.MultiVertex<G,V,L> implements IVertex<G,V,L>
			{
		public MultiVertex(L label, V[] children) {super(label, children);}
		
		public boolean isPlaceHolder() {return false;}
		public void replaceWith(V replacement) {
			throw new UnsupportedOperationException();
		}
	}
}
Comment 1 Ross CLA 2007-06-18 18:04:14 EDT
We figured out a way around the bug, at least a temporary way, that may shed some light on its cause. We split our project into 3 projects based on our primary packages, with a dependency chain. Now it compiles and things run fine, at least for now. Hopefully this unpredictable bug won't come up again before it gets fixed.
Comment 2 Olivier Thomann CLA 2007-06-18 20:35:40 EDT
Could you please attach a test case that can be self-contained?
This will help us to track it down.
Thanks.
Comment 3 Ross CLA 2007-06-19 16:45:03 EDT
Created attachment 71799 [details]
Here is a zip file of our entire project folder. We grant you full use of this code for debugging Eclipse. Please consult with us if you want to use the code for any other purpose.

Thank you for your help, we really appreciate your promptness. Here is a zip file of our entire project folder. We grant you full use of this code for debugging Eclipse. Please consult with us if you want to use the code for any other purpose.

I've imported this folder as an existing project into a completely new workspace (Eclipse 3.2.2 using Java 5) and it still produced the error, so hopefully it does the same for you.

Before importing this folder, place these two jars in the lib folder:
http://math.nist.gov/javanumerics/jama/Jama-1.0.2.jar
http://www.sable.mcgill.ca/software/sootclasses-2.2.4.jar
You'll have to set the JRE system library in the build-path to a 1.5 one of course.

If you have any questions, please feel free to ask. Thanks again for the quick response!
Comment 4 Philipe Mulet CLA 2007-10-23 11:49:05 EDT
Reproduced in latest (3.4 stream).

java.lang.NullPointerException
at org.eclipse.jdt.internal.compiler.ast.FieldReference.resolveType(FieldReference.java:566)
at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:334)
at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:334)
at org.eclipse.jdt.internal.compiler.ast.ForeachStatement.resolve(ForeachStatement.java:392)
at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:429)
at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:198)
at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:399)
at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1084)
at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1154)
at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1013)
at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1163)
at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:365)
at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:623)
at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:392)
at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:362)
at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.compile(BatchImageBuilder.java:173)
at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:299)
at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:59)
at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:251)
at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:177)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:629)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:166)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:197)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:249)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:252)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:305)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:337)
at org.eclipse.core.internal.resources.Workspace.build(Workspace.java:330)
at org.eclipse.ui.actions.GlobalBuildAction$1.run(GlobalBuildAction.java:183)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Comment 5 Philipe Mulet CLA 2007-10-23 12:46:02 EDT
Offending field reference is:
"getGraph().mTracker" in RecursiveExpressionGraph.java
Comment 6 Philipe Mulet CLA 2007-10-23 13:05:44 EDT
This comes from the fact that we get an exception while attempting to resolve the field from ExpressionGraph, leaving unresolved field bindings in the field array (problem 1: in case of badness, unresolved fields should be discarded).

Now the exception seems to occur because of a reentering call into field lookup while still connecting type hierarchies (and resolving single type imports).

SourceTypeBinding.fields() line: 607	
ParameterizedTypeBinding.fields() line: 336	
ParameterizedTypeBinding.getField(char[], boolean) line: 518	
CompilationUnitScope(Scope).findField(TypeBinding, char[], InvocationSite, boolean) line: 878	
CompilationUnitScope.findSingleStaticImport(char[][]) line: 519	
CompilationUnitScope.findSingleImport(char[][], boolean) line: 502	
CompilationUnitScope.resolveSingleImport(ImportBinding) line: 696	
ClassScope(Scope).getTypeOrPackage(char[], int) line: 2393	
ClassScope(Scope).getType(char[]) line: 2141	
ParameterizedSingleTypeReference.internalResolveType(Scope, ReferenceBinding, boolean) line: 98	
ParameterizedSingleTypeReference.resolveType(ClassScope) line: 222	
ParameterizedSingleTypeReference(TypeReference).resolveTypeArgument(ClassScope, ReferenceBinding, int) line: 191	
ParameterizedSingleTypeReference.internalResolveType(Scope, ReferenceBinding, boolean) line: 145	
ParameterizedSingleTypeReference.resolveType(ClassScope) line: 222	
ParameterizedSingleTypeReference(TypeReference).resolveSuperType(ClassScope) line: 114	
ClassScope.findSupertype(TypeReference) line: 1123	
ClassScope.connectSuperInterfaces() line: 921	
ClassScope.connectTypeHierarchy() line: 967	
ClassScope.connectMemberTypes() line: 809	
ClassScope.connectTypeHierarchy() line: 974	
CompilationUnitScope.connectTypeHierarchy() line: 290	
LookupEnvironment.completeTypeBindings() line: 218	
Compiler.internalBeginToCompile(ICompilationUnit[], int) line: 603	
Compiler.beginToCompile(ICompilationUnit[]) line: 357	
Compiler.compile(ICompilationUnit[]) line: 371	
BatchImageBuilder(AbstractImageBuilder).compile(SourceFile[], SourceFile[], boolean) line: 362	
BatchImageBuilder.compile(SourceFile[], SourceFile[], boolean) line: 175	
BatchImageBuilder(AbstractImageBuilder).compile(SourceFile[]) line: 299	
BatchImageBuilder.build() line: 59	
JavaBuilder.buildAll() line: 253	
JavaBuilder.build(int, Map, IProgressMonitor) line: 172	
BuildManager$2.run() line: 629	
SafeRunner.run(ISafeRunnable) line: 37	
BuildManager.basicBuild(int, IncrementalProjectBuilder, Map, MultiStatus, IProgressMonitor) line: 166	
BuildManager.basicBuild(IProject, int, ICommand[], MultiStatus, IProgressMonitor) line: 197	
BuildManager$1.run() line: 249	
SafeRunner.run(ISafeRunnable) line: 37	
BuildManager.basicBuild(IProject, int, MultiStatus, IProgressMonitor) line: 252	
BuildManager.basicBuildLoop(IProject[], IProject[], int, MultiStatus, IProgressMonitor) line: 305	
BuildManager.build(int, IProgressMonitor) line: 337	
Workspace.build(int, IProgressMonitor) line: 330	
GlobalBuildAction$1.run(IProgressMonitor) line: 183	
Worker.run() line: 55	

Comment 7 Philipe Mulet CLA 2007-10-23 13:13:56 EDT
It feels that we shouldn't even attempt to resolve the import to a field in the context of a type hierarchy resolution (i.e. only a member type could be relevant there).
Comment 8 Philipe Mulet CLA 2007-10-24 09:44:56 EDT
Created attachment 81059 [details]
Proposed patch

The patch mimics the method support for reentrance into fields after resolving static imports. Basically, when building fields, reset the flags telling that fields were sorted&complete; in case the question got asked during hierarchy resolution, while the field bindings hadn't been created yet.
Comment 9 Philipe Mulet CLA 2007-10-25 09:29:35 EDT
Simpler testcase:
p/X.java [
package p;
import static r.Y.Z;
import q.*;
public class X<T> extends Z<T> {
   Z<T> getZ() { return null; } 
	void bar() {
		System.out.println(getZ().value);
	}
}

]
q/Z.java [
package q;
import r.Y;
public class Z<T> extends Y<T> {
}

]
r/Y.java [
package r;
public class Y<T> extends V<T>{
	interface Z {}
}

]
r/V.java [
package r;
public class V<T> {
	public Runnable value;
}

]
Comment 10 Philipe Mulet CLA 2007-10-25 09:36:03 EDT
Added StaticImportTest#test055-056
Comment 11 Philipe Mulet CLA 2007-10-25 09:50:34 EDT
*** Bug 207433 has been marked as a duplicate of this bug. ***
Comment 12 Philipe Mulet CLA 2007-10-25 10:03:06 EDT
Released for 3.4M3
Released for 3.3.2
Fixed
Comment 13 Philipe Mulet CLA 2007-10-25 10:05:56 EDT
Ross - sorry it took so long to get to it.
The fix should soon be available in a 3.2.2 integration build (official 3.3.2 is scheduled for february 2008).

Given you seem to be testing extensively Java5 constructs, I would offer to post a patch so you can enjoy better developing with these (please report any issue you'd find with it). Are you interested ?
Comment 14 Ross CLA 2007-10-25 15:49:31 EDT
We would love a patch. We have all these hacks in our infrastructure to get around the problem. Thanks for fixing it! I have a tendency to push compilers. javac won't compile it either, but for different reasons. It doesn't like narrowed return types, but it also seems to have a problem with generic constructors (as in the constructor method is generic, not the class).
We may have found another bug, but it's in the type checking, and a logic bug, not an exception being thrown. I haven't posted anything because I can't tell if it's a bug or not. In some ways it makes sense and in other ways it doesn't. I'm positive that it would be type-safe, but the details of the semantics for generics may not accept it. Should I post the "bug" anyways?
Again, thanks for taking the effort to fix this bug, since we may be the only ones with crazy enough constructs to cause it, heheh.
Comment 15 Philipe Mulet CLA 2007-10-26 07:28:22 EDT
If you have suspicions, please log more bugs against JDT/Core (using [1.5][compiler] as a prefix in the title).

If it ends up not being an issue, we will close it; no big deal (better safe than sorry).

Actually, the patch I can offer it for Eclipse 3.3, is that ok ? Or do you need it for 3.2 ?
Comment 16 Philipe Mulet CLA 2007-10-26 08:57:02 EDT
Released fix in 3.2 maintenance branch.
Comment 17 Frederic Fusier CLA 2007-10-26 10:34:26 EDT
(In reply to comment #16)
> Released fix in 3.2 maintenance branch.
> 
Patch on top of 3.2.2 is now available at: 
http://www.eclipse.org/jdt/core/r3.2/index.php#UPDATES
Comment 18 Philipe Mulet CLA 2007-10-26 10:59:07 EDT
FYI - in forthcoming 3.4M3 (end of next week), you should be able to compile clean the original testcase you attached to this bug. 
I am seeing quite numerous unchecked warnings, but on the surface they seem legite.
Comment 19 Frederic Fusier CLA 2007-10-26 12:14:48 EDT
(In reply to comment #12)
> Released for 3.3.2
> Fixed
> 
Patch on top of 3.3.1 is now available at: 
http://www.eclipse.org/jdt/core/r3.3/index.php#UPDATES
Comment 20 Ross CLA 2007-10-26 19:21:57 EDT
After figuring out how to install it, the patch for 3.2 is working,
even for the current version of our project.
I think I have 3.3 at home, so I can test that patch later.
As to the warnings, we change our warning settings from the default, so that's probably where those come up.
I have a deadline in 3 weeks, after that I'll get around to posting the other possible bug I mentioned before.
Thanks for the help! This should make things much smoother for us.
Comment 21 Maxime Daniel CLA 2007-10-29 09:45:22 EDT
Verified for 3.4 M3 using build I20071029-0010.
Comment 22 Ross CLA 2007-10-29 14:51:46 EDT
Both patches are working for all of us, and we are greatful!
Comment 23 Philipe Mulet CLA 2007-10-30 07:11:24 EDT
Glad it worked. Keep us posted of the next problems you find (in new bug reports).
Comment 24 Jerome Lanneluc CLA 2007-11-22 10:33:37 EST
NPE is quite severe in compiler. The fix is trivial.
Comment 25 Philipe Mulet CLA 2007-11-23 09:20:41 EST
+1 for 3.3.2
Comment 26 Frederic Fusier CLA 2008-01-24 07:05:47 EST
Verified for 3.3.2 using build M20080123-0800.