Re: SQLJSON
От | Vladimir Sitnikov |
---|---|
Тема | Re: SQLJSON |
Дата | |
Msg-id | CAB=Je-GqMiBcWhpPsm9nhOxte6pQ+V_O5XGjQsSp23vVsxak+g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: SQLJSON (Vitalii Tymchyshyn <vit@tym.im>) |
Список | pgsql-jdbc |
> So the JDBC+API+wrapped RI is a bundle that just works I wish some OSGi expect chimed in and told us if such bundling is workable in OSGi world. > If there are further inconveniences in making the API+RI bundle the default, please specify. 1) I just do not see why you feel "using several dependencies" to be a lot harder than "using all-in-one-bundle". I agree it is a bit more work, but it is not a rocket science. If user codes against JsonValue, then she expects to have that API in the class path. I would say "jdbc driver" as a provider of "JSR353" would violate the principle of least astonishment. 2) For instance: slf4j, log4j, logback do not have default bundles. 3) If each and every library bundles JSON API, we would get LinkageErrors or similar errors soon. It is just bad when distinct jar files contain "the same" class files. It is very painful when they end up to contain _different_ class files. 4) Consider the other side of a coin. What if we would want implementing IBM's JSONx later? (https://twitter.com/danharper7/status/514822464673951744). If we had some way of "adding custom getObject" via external dependencies, that would be much easier since we would not have to touch "core" part of the driver. If we hard-code JSR353 into the core "just for convenience of a single jar", then it won't help us adding new datatypes. Vladimir
В списке pgsql-jdbc по дате отправления: