Re: SQLJSON
От | Steven Schlansker |
---|---|
Тема | Re: SQLJSON |
Дата | |
Msg-id | EE2F8341-FC4A-4E5F-8848-D749EE9F8B67@gmail.com обсуждение исходный текст |
Ответ на | Re: SQLJSON ("Markus KARG" <markus@headcrashing.eu>) |
Ответы |
Re: SQLJSON
|
Список | pgsql-jdbc |
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 по дате отправления: