Bugzilla – Full Text Bug Listing
| Summary: | [1.5][compiler] Eclipse ignores constraints on type parameters and compiles; javac reports error | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | jones.noamle |
| Component: | Core | Assignee: | Srikanth Sankaran <srikanth_sankaran> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | daniel_megert, jones.noamle, Olivier_Thomann |
| Version: | 3.7 | Keywords: | core |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | stalebug | ||
|
Description
jones.noamle
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. It compiles fine with javac 1.7 (b120). Srikanth, please investigate. (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. (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. (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. (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. [...] > 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. 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. 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. |