Bugzilla – Full Text Bug Listing
| Summary: | No compiler error given when using a JRE 1.6 runtime and extending an implementation of DataSource compiled against Java5 | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Mauro Molinari <mauromol> |
| Component: | Core | Assignee: | Srikanth Sankaran <srikanth_sankaran> |
| Status: | VERIFIED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | mihey77, Olivier_Thomann |
| Version: | 3.6 | ||
| Target Milestone: | 3.7 M4 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Mauro Molinari
I'll try to reproduce. I get the same problem with javac:
c:\tests_sources>javac -classpath c:\java_tools\commons-dbcp-1.3\commons-dbcp-1.3.jar X.java
c:\tests_sources>java -classpath c:\java_tools\commons-dbcp-1.3\commons-dbcp-1.3.jar;c:\java_tools\commons-pool-1.5.5\commons-pool-1.5.5.jar;. X
Exception in thread "main" java.lang.AbstractMethodError: X.isWrapperFor(Ljava/lang/Class;)Z
at X.main(X.java:5)
where javac's version is javac 1.6.0_20-ea.
Srikanth, could you please investigate?
My test case is:import java.sql.Wrapper;
public class X extends org.apache.commons.dbcp.BasicDataSource {
public static void main(String[] args) throws Exception {
System.out.println(((Wrapper) new X()).isWrapperFor(X.class));
}
}
(In reply to comment #2) > I get the same problem with javac: Strange... I remember javac gave me the compiling errors (I was using 1.6.0_18, I think)... This is how I realized about this problem on my project (which I was migrating to compile against 1.6 instead of 1.5). Actually, with 1.6.0_21 I can compile, too, but I'm almost sure that there was a javac version with which I couldn't. I'm not sure if it was an earlier version (e.g.: 1.6.0_18) or the NetBeans validator (which is based on javac 7). (In reply to comment #5) > Actually, with 1.6.0_21 I can compile, too, but I'm almost sure that there was > a javac version with which I couldn't. I'm not sure if it was an earlier > version (e.g.: 1.6.0_18) or the NetBeans validator (which is based on javac 7). I can compile this with javac 7(b100) too. Mauro, should I close this as INVALID ? Hmmm... this is strange. I'm almost sure that I was told about the problem by some compiler and/or IDE when I opened this bug. Anyway, whatever is the behaviour of javac, I think that it actually is a problem if the compiler does not warn you of what you are doing, since you will almost certainly run into runtime errors. I don't know if the Java specification say something about this... It would surprise me a bit to know that this is the expected behaviour... (In reply to comment #7) > Hmmm... this is strange. I'm almost sure that I was told about the problem by > some compiler and/or IDE when I opened this bug. Anyway, whatever is the > behaviour of javac, I think that it actually is a problem if the compiler does > not warn you of what you are doing, since you will almost certainly run into > runtime errors. I don't know if the Java specification say something about > this... It would surprise me a bit to know that this is the expected > behaviour... Since org.apache.commons.dbcp.BasicDataSource is a concrete class, the eclipse compiler assumes that there is no unfulfilled contract from the super class that the current class must implement. Given javac also behaves the same way, I am inclined to leave it as it is - as otherwise we can go on second guessing and double checking everything. The code assist oddity cited in comment#0 logically follows from there. Olivier, what is your take on this ? I am not happy with the second guessing and double checking a general fix implies. This may also have a performance impact. Do you think it is warranted that we should hardcode a fix based on the super type being org.apache.commons.dbcp.BasicDataSource ?? (In reply to comment #9) > Olivier, what is your take on this ? I am not happy with the second > guessing and double checking a general fix implies. This may also have > a performance impact. If we start to consider binary types as source types in term of check for missing implemented method, there is clearly a performance impact. If a class file is compiled, all needed methods are supposed to be there. How often do we end up in such a mixed settings where some classes are compiled using previous versions of some interfaces? This will never happen in a consistent environment where all classes are compiled using the same binaries. For me, it makes sense that javac compiles as well. I don't see why they would check implemented methods for binary types. As it stands, I am not tempted to penalize all cases to fix what I consider as a configuration issue. > Do you think it is warranted that we should hardcode a fix based on > the super type being org.apache.commons.dbcp.BasicDataSource ?? I clearly don't like that solution. Hard-coded names are evil. Agree with assessment in comment# 10 Verified using I20101207-0250 (4.1 I-build) *** Bug 327881 has been marked as a duplicate of this bug. *** (In reply to comment #7) > Hmmm... this is strange. I'm almost sure that I was told about the problem by > some compiler and/or IDE when I opened this bug. At least bug #327881 highlights a possible way to reproduce the problem I mentioned in my original report.. so, I was not totally crazy :-D |