Re: SQLJSON

On Sun, Jun 28, 2015 at 4:35 PM, Dave Cramer <pg(at)fastcrypt(dot)com> wrote:

> On 28 June 2015 at 16:32, Christopher BROWN <brown(at)reflexe(dot)fr> wrote:
>
>> Embedding the API will cause classloader conflicts for those who already
>> have the API in their classpath. Same goes for embedding the reference
>> implementation.
>>
>> The API, or the implementation ???
>

Both. Embedding dependencies is mildly convenient for someone getting
started with something but royally inconvenient for someone with a
complicated environment. Dependency management systems like Maven handle
this pretty well but even they can't deal with situations where classes are
embedded in a dependency (ex: javax.json.* embedded within the PG JDBC
driver).

> The service loader API can be problematic for OSGi users, as it isn't very
>> helpful for hot reloading of classes. The PostgreSQL JDBC driver currently
>> works well in such environments, it would be unfortunate to lose that
>> advantage through an attempt to help out another category of users.
>>
>> This shouldn't be the only way of selecting an implementation, and
>> bundling a given version of the API + RI shouldn't be the only build
>> option. I'm certainly not against making this Just Work, but here there's a
>> possibility that all this extra stuff could actually cause things to break .
>>
> so how do we make it "Just Work" ?
>

I don't think there's a way to do this without breaking backward
compatibility.

You definitely can't rely on specific dependencies on the classpath that
legacy users will not have. Bundling the dependencies doesn't work either
as it'd clobber existing ones on the classpath. Making things
dynamic/pluggable may be option for internal implementations but it breaks
anything with the required dependencies in the method signature. That means
we could have code that dynamically picks a JSON parser and uses it
internally, but we can't have a getJsonValue() method on a public
PGResultSet interface as the class wouldn't even load properly on an older
JVM[1].

In a lot of ways this is similar to the other thread we had about dropping
support for older JVMs. To natively support new features (like a native
getJsonValue()) we'd need to specify a min JDK version.

At this point I think we have to bite bullet and either drop support for
older versions (not likely) or offer multiple versions of the driver. The
latter could make modern assumptions about the classpath/environment to
support new features natively. That could include JsonValue and the new
Java 8 date/time types.

[1]: PGResultSet doesn't exist yet so that may be a bad example as
presumably any user of it would be a "new" user. PGStatement does exist
though so arguably we'd have the reverse problem there for a
setJsonValue(...) method.

Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/