Leveraging Lambda for JDBC 4.2

[Lance Andersen - Oracle]

On Dec 6, 2012, at 1:37 PM, Mark Rotteveel wrote:

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

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

Best
Lance


> 
> Mark
> -- 
> Mark Rotteveel

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com