Bug 333503 - [1.5][compiler] Eclipse ignores constraints on type parameters and compiles; javac reports error
Summary: [1.5][compiler] Eclipse ignores constraints on type parameters and compiles; ...
Status: CLOSED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.7   Edit
Hardware: PC Windows XP
: P3 normal with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: Srikanth Sankaran CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords: core
Depends on:
Blocks:
 
Reported: 2011-01-04 13:32 EST by jones.noamle CLA
Modified: 2018-10-13 13:37 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jones.noamle CLA 2011-01-04 13:32:06 EST
Build Identifier: 20100917-0705

The following code compiles without warnings in eclipse, but fails compilation in javac (which is the correct thing to do).

More discussion here:
http://stackoverflow.com/questions/4596613/why-does-this-compile-the-code-seems-to-be-breaking-constaints-on-the-type-param




public class TestGenerics {
	public static class ParamedType<T> {}
	
	
	public class TesterClass<A extends ParamedType<B>, B> {
    	public TesterClass<A, B> func() {
    		return new TesterClass<A, B>();
    	}
    
    	public TesterClass<A, String> func2() {
    		return new TesterClass<A, String>();
    	}
    }
	
	public Object test() {
		// How can I use these type parameters? Doesn't .func2 now have an invalid return type?
		TesterClass<ParamedType<Integer>,Integer> testClass = new TesterClass<TestGenerics.ParamedType<Integer>, Integer>();
		
		//TesterClass<ParamedType<String>, Integer> res2 = testClass.func2(); // <-- will not compile
		Object res = testClass.func2(); // Compiles
		return res;
	}
}



javac  fails with:

TestGenerics.java:12: type parameter A is not within its bound
        public TesterClass<A, String> func2() {
                           ^
TestGenerics.java:13: type parameter A is not within its bound
                return new TesterClass<A, String>();
                                       ^
2 errors

Reproducible: Always

Steps to Reproduce:
1. Compile it with JDT - compiles.
2. Compile with javac (I used 1.6.0_23) - fails errors.
Comment 1 jones.noamle CLA 2011-01-04 13:58:45 EST
Note: Work done in EntireOne, Inc.

(In reply to comment #0)
> Build Identifier: 20100917-0705
> 
> The following code compiles without warnings in eclipse, but fails compilation
> in javac (which is the correct thing to do).
> 
> More discussion here:
> http://stackoverflow.com/questions/4596613/why-does-this-compile-the-code-seems-to-be-breaking-constaints-on-the-type-param
> 
> 
> 
> 
> public class TestGenerics {
>     public static class ParamedType<T> {}
> 
> 
>     public class TesterClass<A extends ParamedType<B>, B> {
>         public TesterClass<A, B> func() {
>             return new TesterClass<A, B>();
>         }
> 
>         public TesterClass<A, String> func2() {
>             return new TesterClass<A, String>();
>         }
>     }
> 
>     public Object test() {
>         // How can I use these type parameters? Doesn't .func2 now have an
> invalid return type?
>         TesterClass<ParamedType<Integer>,Integer> testClass = new
> TesterClass<TestGenerics.ParamedType<Integer>, Integer>();
> 
>         //TesterClass<ParamedType<String>, Integer> res2 = testClass.func2();
> // <-- will not compile
>         Object res = testClass.func2(); // Compiles
>         return res;
>     }
> }
> 
> 
> 
> javac  fails with:
> 
> TestGenerics.java:12: type parameter A is not within its bound
>         public TesterClass<A, String> func2() {
>                            ^
> TestGenerics.java:13: type parameter A is not within its bound
>                 return new TesterClass<A, String>();
>                                        ^
> 2 errors
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1. Compile it with JDT - compiles.
> 2. Compile with javac (I used 1.6.0_23) - fails errors.
Comment 2 Olivier Thomann CLA 2011-01-04 17:44:51 EST
It compiles fine with javac 1.7 (b120).
Srikanth, please investigate.
Comment 3 jones.noamle CLA 2011-01-13 04:53:55 EST
(In reply to comment #2)
> It compiles fine with javac 1.7 (b120).
> Srikanth, please investigate.

What do you mean "It compiles fine?" The correct behavior should be to fail with a type-related error, not to compile at all. From my checks with javac it indeed fails as expected. Only in eclipse it somehow passes type safety checks.
Comment 4 Olivier Thomann CLA 2011-01-13 08:30:20 EST
(In reply to comment #3)
> (In reply to comment #2)
> > It compiles fine with javac 1.7 (b120).
> > Srikanth, please investigate.
Sorry wrong bug report.
Comment 5 Srikanth Sankaran CLA 2011-01-17 01:22:57 EST
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > It compiles fine with javac 1.7 (b120).
> > > Srikanth, please investigate.
> Sorry wrong bug report.

Actually it does compile fine with javac 1.7 b123.
I'll look into what is going on here.

Why is this a critical bug ? If the code is compiling
with javac, but eclipse fails to compile, I can accept
the critical classification as it has the potential to
block a customer, but not the other way about.
Comment 6 jones.noamle CLA 2011-01-17 23:06:05 EST
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > (In reply to comment #2)
> > > > It compiles fine with javac 1.7 (b120).
> > > > Srikanth, please investigate.
> > Sorry wrong bug report.
> 
> Actually it does compile fine with javac 1.7 b123.
> I'll look into what is going on here.
> 
> Why is this a critical bug ? If the code is compiling
> with javac, but eclipse fails to compile, I can accept
> the critical classification as it has the potential to
> block a customer, but not the other way about.

I'm surprised that javac compiles it.
It's critical because it means that the compiler is happily building a wrong program. This program is not type-consistent.
In my opinion this sort of a problem is much worse than the opposite one (preventing compilation when it should work) because in that case the "customer" will immediately notice something is wrong, whereas in THIS case - potentially critical bugs will get compiled into production code.
Comment 7 Srikanth Sankaran CLA 2011-02-02 04:02:02 EST
[...]

> I'm surprised that javac compiles it.
> It's critical because it means that the compiler is happily building a wrong
> program. This program is not type-consistent.

Please see http://wiki.eclipse.org/Eclipse/Bug_Tracking for guidelines.
I don't think this qualifies as a critical defect.

I have not looked into this in detail, but given javac of a recent
vintage compiles it, I am inclined to think it is their behavior that
was suspect and has since been repaired.

I will analyze it in more detail and update here the findings.
Comment 8 Dani Megert CLA 2012-08-13 08:20:33 EDT
Suggest to close as INVALID or NOT_ECLIPSE.

Note that newer versions of javac also don't mimic the bug when using 1.6 as source and target.
Comment 9 Eclipse Genie CLA 2018-10-13 13:37:49 EDT
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.