Re: SQLJSON

On 29/06/15 15:54, Dave Cramer wrote:
> So assuming the reference implementation allows us to do this, we can
> change the namespace of the RI and include it in our jar. Apparently
> Hibernate used this approach

This makes a lot of sense, really good idea.

+1

Álvaro

--
Álvaro Hernández Tortosa

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

>
> Dave Cramer
>
> dave.cramer(at)credativ(dot)ca
> http://www.credativ.ca
>
> On 29 June 2015 at 06:28, Sehrope Sarkuni <sehrope(at)jackdb(dot)com
> <mailto:sehrope(at)jackdb(dot)com>> wrote:
>
> On Mon, Jun 29, 2015 at 2:30 AM, Álvaro Hernández Tortosa
> <aht(at)8kdata(dot)com <mailto:aht(at)8kdata(dot)com>> wrote:
>
> On 28/06/15 22:54, Sehrope Sarkuni wrote:
>> 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.
>
>
> I was referring to dependencies being in the pgjdbc jar itself,
> not specified as an dependency in the pom. For example if we had a
> single version of the driver that was self-contained with the
> class files for the javax.json classes in their as well. Maven
> can't work around that as the classes would be within the pgjdbc
> depdendency.
>
> Honestly it's not really a Maven issue at all. There's no real way
> to work around classpath conflicts like that without
> unzipping/removing/rezipping the jar.
>
> Much better to either have them be externally specified (ex:
> Maven) or just assume they're there and leave it to the user to
> specify them. If users are manually managing dependencies it's up
> to them to ensure they're all included.
>
>> 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.
>
>
> Oh that's nice then. I haven't read through the spec for it but
> based on the release date assumed it was 1.7+. This might make
> things a bit easier.
>
>>
>> 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.
>
>
> I'm really liking the separate version approach. We're gonna have
> to do it anyway for JDBC 4.2 ... might as well support PG
> extensions in the same way.
> Regards,
> -- Sehrope Sarkuni
> Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
>
>