Community
Participate
Working Groups
Build Identifier: I20100608-0911 See the steps to reproduce. Reproducible: Always Steps to Reproduce: 1. set up a Java project that uses a Java6 JRE 2. download DBCP 1.3 or older from http://commons.apache.org/dbcp/download_dbcp.cgi and add commons-dbcp-1.xxx.jar to the classpath; note: these DBCP versions are compiled against Java5 3. create a (concrete) class that extends org.apache.commons.dbcp.BasicDataSource The new class is not abstract and extends javax.sql.DataSource. Since the anchestor does not implement the method java.sql.Wrapper.isWrapperFor(Class<?>) (note: javax.sql.DataSource extends java.sql.Wrapper in Java6, while it did not in Java5), the new class is concrete but does not provide any implementation for that method. However the compiler does not give any error, while javac does. Moreover, if you declare a method test() in this new class, you can see the following behaviour: public void test() { isWr| <= invoke code assist here: no suggestions! DataSource ds = this; ds.isWr| <= invoke code assist here: isWrapperFor is suggested! }
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
