Re: SQLJSON

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

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> wrote:

> On Mon, Jun 29, 2015 at 2:30 AM, Álvaro Hernández Tortosa <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/
>
>