Re: SQLJSON

On 28/06/15 22:54, Sehrope Sarkuni wrote:
> On Sun, Jun 28, 2015 at 4:35 PM, Dave Cramer <pg(at)fastcrypt(dot)com
> <mailto:pg(at)fastcrypt(dot)com>>wrote:
>
> On 28 June 2015 at 16:32, Christopher BROWN <brown(at)reflexe(dot)fr
> <mailto: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).
Sehrope, what do you mean by Maven can't deal with embedded classes
in the dependencies? It very well can :) The only problem would be, as
stated in a previous email, if different versions of the same class
would collide on transitive dependencies. But at least for the JSR353
IMHO that's extremely unlikely --and not worth to engineer around it.

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

JSR353 targets 1.6+. So if by older you mean 4 or 5 then yes, it
won't be supported.
>
> 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 to drop support for less than 1.6. Or at least, create different
versions (but that is indirectly happening now, with different JDBC API
levels). But not adding as of today JsonValue to a method signature
because we want to retain compatibility with 1.5 or less is not
something our users would understand.

Regards,

Álvaro

--
Álvaro Hernández Tortosa

-----------
8Kdata