Leveraging Lambda for JDBC 4.2

[Mark Rotteveel]

On 6-12-2012 19:50, Lance Andersen - Oracle wrote:
> The problem that  you have is for APIs such as JDBC to improve the API, you need to add methods where they naturally reside.  This causes problems for people that their code will no longer compile on the new version of Java
>
> Leveraging a default method solves that issue and a compliant from many in the past.  It is the lessor of two evils really.

I understand the dilemma and I do agree that default methods have their 
uses (especially for optional methods or for methods that can be 
expressed in terms of other methods defined in the interface). But 
throwing away the usefulness of an interface as a contract for the 
implementer by providing a default, while at the same time still 
requiring that the method be implemented, seems like a bad idea to me 
(and a bad example of the use of default methods as well).

Also when (as a user of JDBC) you only use the JDBC API and don't need 
compile time access to the actual driver implementation, then there is 
no problem, as you talk to the interface. Then - as I mentioned 
previously - the difference is between getting an AbstractMethodError or 
an UnsupportedOperationException.

>> I also think throwing UnsupportedOperationException doesn't fit with other use in Java. In general this exception is used either as an equivalent of SQLFeatureNotSupportedException, eg in the collections framework, or if some state prevents the operation, for example (in AWT) to signal that something cannot be done because of missing keyboard, display or mouse (HeadlessException), or in NIO for readonly buffers/filesystems (ReadOnlyBufferException cq ReadOnlyFileSystemException).
>
> Need a way to distinguish from optional vs required methods.  SQLFeatureNotSupportedException is similar but different as it is there due to optional features.  Open to a different Exception but the JDBC spec will be clear on this.

The semantic difference between a SQLNotImplementedException (or 
something like that) and SQLFeatureNotSupportedException would be 
subtle; I also think it isn't a very useful distinction to the users of 
the JDBC API. I guess in that light UnsupportedOperationException is 
good enough.

>>
>> On the other hand: not having a method implemented in a class which was compiled to an earlier version of the interface is allowed until you actually call that method (which will then throw an AbstractMethodError), which to be honest is about as informative as an UnsupportedOperationException. Replacing compile time errors with errors in the JDBC testsuite is IMHO bad.
>>
>> And now we are on the JDBC testsuite: I don't know if you actually ever tried to get your hands on a recent JDBC testsuite, but as an independent, open source developer it is next to impossible. Any potential source for more information either leads to dead links on sun.com which redirect to useless or general links on oracle.com, or to sites that say you can get access as a non-profit, but then don't actually bother to say how (eg for the Java 7 SE TCK, see http://jcp.org/aboutJava/communityprocess/final/jsr336/index.html).
>
> to get access to the test suite or any other TCK you need to apply for a scholarship if you are a not for profit and meet the criteria http://www.oracle.com/technetwork/java/index-137188.html  Commercial use is $35K/year

Thanks, I will look into that.

Mark
-- 
Mark Rotteveel