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: