Re: SQLJSON - Mailing list pgsql-jdbc

From Markus KARG
Subject Re: SQLJSON
Date
Msg-id 014801d0b372$e1e158f0$a5a40ad0$@eu
Whole thread Raw
In response to Re: SQLJSON  (Steven Schlansker <stevenschlansker@gmail.com>)
List pgsql-jdbc
Understood. That's why I am deeply against any kind of bundling. :-)


-----Original Message-----
From: Steven Schlansker [mailto:stevenschlansker@gmail.com]
Sent: Dienstag, 30. Juni 2015 22:17
To: Markus KARG
Cc: List
Subject: Re: [JDBC] SQLJSON

Sorry, maybe I'm misunderstanding:  my complaint is that if the PG driver
packages version 1.0, but I use a feature added in a hypothetical 1.1, then
the 1.0 bundled in PG becomes a problem for me.

So what I am talking about is *forward* compatibility, not backward.

I'm not claiming this is a huge issue, I just wanted to point out that these
interfaces can and do evolve, so it is a false assumption that the version
baked into the PG driver will be good for all time.


On Jun 30, 2015, at 1:04 PM, Markus KARG <markus@headcrashing.eu> wrote:

> Being a JAX-RS EG member I need to chime in here: JAX-RS actually is
> fully backwards compatible, fully intentionally. We will never break
> any existing feature, and I think I am speaking for hardly every JSR
> EG when I say that most (if not all) JSR standards are always
> backwards compatible. The 22 different versions actually are no
> releases but development milestones not intended for productive use.
>
> All parts of Java EE have a restriction that nothing may break
> backwards compatibility ever. This not only is true of JAX-RS but most
> certainly also JSON-P and JSON-B. It is a guarantee the Java EE spec
> lead (Bill Shannon) gives for all parts of the Java EE platform. So we
> can really safely rely on that.
>
> -Markus
>
> On Jun 30, 2015, at 10:25 AM, Álvaro Hernández Tortosa
> <aht@8Kdata.com>
> wrote:
>
>>
>>   Thanks for asking for the double-check. No, indeed I'm still asking
>> to
> provide the class files for the API in the package. I feel that's the
> right way, and I don't see it would create conflicts unless JSR353
> would create a new version, something which I believe extremely
> unlikely until it merges with Java10 or JDBC5 comes out, point at
> which we would need to change things anyway.
>
> I do not believe this is as unlikely as you think.  For example, the
> javax.ws.rs JAX-RS spec has 22 different versions available on Maven
> Central.  Granted, many of these are milestone builds and not
> releases, but there are already two major versions, a patch available
> and a new minor version coming through the pipes.
>
> So assuming these spec jars will not change is provably false.  One of
> my fears is that if PG bundles JSR353 1.0, and I need JSR353 1.0.1, I
> now need to fight the driver packaging to upgrade a theoretically
unrelated package.
>
>>
>>   However, I don't want to insist more or suck more dev bandwitch,
>> that's
> my opinion and it's been stated more times than I wish, so I would now
> leave the decision to the rest of you :)
>>
>>   Regards,
>>
>>   Alvaro
>>
>>
>> --
>> Álvaro Hernández Tortosa
>>
>>
>> -----------
>> 8Kdata
>>
>>
>>
>> On 30/06/15 18:49, Vladimir Sitnikov wrote:
>>> ah. I meant to double-check with Álvaro if he is suggesting compile
>>> type dependency.
>>>
>>> If he means that we in fact are discussing the same thing, so no
>>> contradiction exists.
>>>
>>>> However, regarding POLA you say "compile dependency" which means
>>>> you suggest _not_ including javax.json into pgjdbc.jar
>>>>
>>>> Álvaro , Can you please tell us if "using compile type dependency
>>>> for
> both
>>>> javax.json and RI" suits you?
>>>>
>>> Vladimir
>>
>>
>>
>> --
>> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) To make
>> changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-jdbc
>
>
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) To make
> changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc




pgsql-jdbc by date:

Previous
From: "Markus KARG"
Date:
Subject: Re: Adding new dependencies for in-core
Next
From: Vitalii Tymchyshyn
Date:
Subject: Re: SQLJSON