Bug 351939 - Compilation error with generic classes and subclasses
Summary: Compilation error with generic classes and subclasses
Status: VERIFIED INVALID
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.7   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.8 M4   Edit
Assignee: Srikanth Sankaran CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-13 06:09 EDT by Nicolas HERVE CLA
Modified: 2011-12-06 08:19 EST (History)
5 users (show)

See Also:


Attachments
source code to reproduce the bug (1.44 KB, application/octet-stream)
2011-07-13 06:12 EDT, Nicolas HERVE CLA
no flags Details
source code to reproduce the bug (1.45 KB, application/octet-stream)
2011-07-13 06:43 EDT, Nicolas HERVE CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas HERVE CLA 2011-07-13 06:09:45 EDT
Build Identifier: 20100917-0705

The following source code compiles well on Helios (JDK 1.6) but not on Indigo (same computer). There are 3 classes in my project.

The error is :

The method doSomething(Class<? extends Task<Input>>) in the type BogusClass<T>.ExecutionContext is not applicable for the arguments (Class<BogusClass.ExecutionContext.SubTask>)	BogusClass.java

If the class BogusClass is not generic anymore, the bug disappears (removing the <T extends AnInterface>).


----

package indigo.compile.bug;
public interface AnInterface {
}

----

package indigo.compile.bug;
public abstract class Task<Input> {
	public Task() {
		super();
	}
}

----

package indigo.compile.bug;


public class BogusClass<T extends AnInterface> {
	public class ExecutionContext {
		public class SubTask extends Task<String> {

		}
		public <Input> void doSomething(
				Class<? extends Task<Input>> method) {
		}
		public void start() {
			doSomething(SubTask.class);
		}
	}
	public BogusClass() {
		super();
	}
}

----

Reproducible: Always

Steps to Reproduce:
1. create the 3 classes in a project and compile
2.
3.
Comment 1 Nicolas HERVE CLA 2011-07-13 06:12:09 EDT
Created attachment 199559 [details]
source code to reproduce the bug
Comment 2 Dani Megert CLA 2011-07-13 06:29:03 EDT
(In reply to comment #0)
> Build Identifier: 20100917-0705
This is a Helios build (probably (3.6.1).

The example code compiles fine for me when using Indigo (3.7).
Comment 3 Nicolas HERVE CLA 2011-07-13 06:38:24 EDT
It's my mistake, the build id is 20110615-0604. The previous one was the build id of the helios instance on which the code compiles well.
Comment 4 Nicolas HERVE CLA 2011-07-13 06:43:16 EDT
Created attachment 199564 [details]
source code to reproduce the bug
Comment 5 Nicolas HERVE CLA 2011-07-13 06:43:40 EDT
The previsous attachement was also the bad version :-(
Comment 6 Srikanth Sankaran CLA 2011-07-13 07:08:53 EDT
This minimal test case fails to compile with javac5,6,7 and
elicits nearly identical message:

// --------------------------8<------------------------
interface AnInterface {
}

abstract class Task<Input> {
}

public class X<T extends AnInterface> {
	public class ExecutionContext {
		public class SubTask extends Task<String> {
		}
		public <Input> void doSomething(
				Class<? extends Task<Input>> method) {
		}
		public void start() {
			doSomething(SubTask.class);
		}
	}
}
// --------------------------8<------------------------

What do you think is the bug here ?
Comment 7 Nicolas HERVE CLA 2011-07-19 04:07:17 EDT
I found the bug in my source code. In the minimal test case provided by Srikanth, the subclass SubTask is indirectly parameterized by T of class X. Thus the compiler is unable to know exactly what is SubTask.class. Having this subclass static or removing the generic parameterization on X will correct the bug.

Now the main question is : why was this working fine in eclipse 3.6 ? The compilation, and more importantly, the execution were fine.
Comment 8 Srikanth Sankaran CLA 2011-11-21 03:47:09 EST
(In reply to comment #7)
> I found the bug in my source code. In the minimal test case provided by
> Srikanth, the subclass SubTask is indirectly parameterized by T of class X.
> Thus the compiler is unable to know exactly what is SubTask.class. Having this
> subclass static or removing the generic parameterization on X will correct the
> bug.

Thanks for confirming this.

> Now the main question is : why was this working fine in eclipse 3.6 ? 

It is called a bug ? :)

>The
> compilation, and more importantly, the execution were fine.

Type unsafe code may not always produce visible problems. It is just that
there is some set of constraints under which it could produce problems.
Comment 9 Ayushman Jain CLA 2011-12-06 08:19:42 EST
Verified for 3.8M4 using build I20111202-0800.