Leveraging Lambda for JDBC 4.2

[Mark Rotteveel]

On 6-12-2012 18:40, Lance Andersen - Oracle wrote:
> Folks
>
> In order to make it a little easier for migration to the new JDBC releases I am planning to leverage default methods in Lambda.
>

>
> Optional methods will default to throwing a SQLFeatureNotSupportedException
>
> Required methods will default to throwing a UnsupportedOperationException allowing for this to be flagged by the JDBC test suite as a compliance issue
>
>
> Leveraging Lambda will allow existing code to compile on the new JDK without having to immediately add stubs or implementation.

For optional methods I like it, although I have some reservations. It 
makes creating a compliant driver easier, although as a driver developer 
it will make it harder to spot which optional method you forgot to 
implement (I just hope the IDEs with Java 8 support will support 
warnings for not overriding a default method).

However for required methods I think it is a really bad idea. One of the 
nice things about interfaces is that having a required method not 
implemented will be immediately and forcefully signaled to the driver 
developer by a compile time error (both in the IDE and at building the 
driver). Introducing a default method that throws 
UnsupportedOperationException will remove those handy signals.

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).

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).

Mark
-- 
Mark Rotteveel