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
2010-09-10 06:43:35 EDT
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 |