Re: SQLJSON

Yes, it would appear there is a preponderance of evidence that including
the API and the RI in the driver would be a bad thing. It's my opinion that
this would not be a good idea.

Thanks everyone for your opinions and patience discussing this thread.

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

On 1 July 2015 at 03:15, Christopher BROWN <brown(at)reflexe(dot)fr> wrote:

> Hello,
>
> JSR 353 does not address things like JSON schemas (there is no standard at
> this time, but this may change, and there are many non-standard
> implementations) or binary encoding formats (again, no current standard,
> but several implementations). So there is scope for the API to change,
> with forward-compatibility issues especially if there are classloader
> conflicts.
>
> Bundling the API by default may indeed cause harm if the application
> already has JSONP in the classpath (highly likely in Java EE environments,
> and already the case in many OSGi environments). I wouldn't mind making
> things easy for users by bundling it if it had no side effects for other
> users, but it WILL, and that'll happen with the current API, not just
> potential forward-compatibility issues. It's not a neutral packaging
> issue, and those that are against it are not just motivated by ivory-tower
> engineering. Indeed, instead of a clear linkage error, users who don't
> read the famous manual and who don't really know about how classloading
> works, will have much greater difficulty understanding and resolving such
> problems.
>
> As Markus informed us by forwarding Lance Andersen's opinion (he's the
> JDBC spec lead):
> http://www.postgresql.org/message-id/007701d0b2b6$4cc930b0$e65b9210$@eu
>
> ...it is expected that the client application provide the classes, not the
> driver. This can be done by overloading the getObject() methods (not the
> default one; if this is change, then the change should only be activated by
> a connection property to maintain backwards compatibility). Furthermore,
> in the case of injected drivers (JNDI, Spring, other pools), you won't even
> have PostgreSQL in the classpath, so to use JSONP, you'll need to add the
> API in your classpath... but because your JSONP classes are not loaded from
> the same source as the driver-bundled ones, the JVM will consider them as
> different, and it just won't work, even with identical class names.
>
> So, why deviate from JDBC standard practice, why trip up those that
> already have an application server or an imposed enterprise framework
> providing such classes, why make life difficult for those who actually read
> the documentation (I'm talking about just the "getting started" and
> possibly even "how to define a PostgreSQL JDBC URL...", not even dreaming
> of a developer reading beyond that), or even that category of users who
> just use brute force to stick a load of ".jars" together "until it works",
> when in fact for the reasons outlined above (and well-stated by many other
> posters here) even with such good intentions, for a large proportion of
> such users, it in fact won't just work?
>
> I understand the intention, but there's a lot of real-world feedback here
> explaining why, except in the most trivial of situation, it won't just hurt
> "smart" developers, but also hurt a large proportion of those it is
> intended to help?
>
> --
> Christopher
>
>
> On 1 July 2015 at 00:38, Dave Cramer <pg(at)fastcrypt(dot)com> wrote:
>
>> Do we really think there will be an update to JSR 353 ??
>>
>> if not then there is little harm in bundling it
>>
>> Dave Cramer
>>
>> dave.cramer(at)credativ(dot)ca
>> http://www.credativ.ca
>>
>> On 30 June 2015 at 18:30, Vitalii Tymchyshyn <vit(at)tym(dot)im> wrote:
>>
>>> I dont understand how users can "not realize they need another
>>> dependency" if their application is going to use Json.
>>> How they think they are going to use it without having it in classpath?
>>>
>>> Best regards, Vitalii Tymchyshyn
>>>
>>> Вт, 30 черв. 2015 07:34 Álvaro Hernández Tortosa <aht(at)8kdata(dot)com> пише:
>>>
>>>>
>>>> On 30/06/15 09:57, Vladimir Sitnikov wrote:
>>>> >> so that you don't need to parse it manually, which is a pain for
>>>> many users
>>>> > A) Can you please list pain points in literal?
>>>>
>>>> I did that already:
>>>> http://www.postgresql.org/message-id/558FC12E.8010107@8Kdata.com
>>>>
>>>> In brief: users don't realize they need another dependency. Then
>>>> they find their code breaks with a RuntimeException. Frustration
>>>> appears, and there is no compelling reason not to have the dependency in
>>>> the driver. User gets angry. I agree with the user anger.
>>>>
>>>> Imagine JSR353 wasn't an external class. Imagine the driver wanted
>>>> to return a PGJsonValue class. Now you compile the code and then remove
>>>> the .class from the JAR file. The end result is more or less the same:
>>>> hey, to use this driver you have to anyway include another dependency.
>>>> Which is weird: a dependency on something you are returning......
>>>>
>>>> But again: *what* is the problem adding this dependency? Classpath
>>>> collision is extremely unlikely, I won't bet on it, so why not help the
>>>> user even more? Why not make it more user friendly, why do we prefer
>>>> less user friendly?
>>>>
>>>>
>>>> > I think we've already agreed that "having readme" is good enough so
>>>> > even newbies can add dependencies.
>>>> I don't agree is good enough. Good enough is not needed to add
>>>> anything else. Or not asking the user to do something we could have
>>>> provided instead with 0 drawbacks.
>>>>
>>>> > What are the other pain points except "need to add a couple of jars if
>>>> > json is needed"?
>>>> >
>>>> > Frankly speaking, I find current "different jdbc version jars" even
>>>> > more confusing than "if you want json, add pgjdbc-json dependency".
>>>>
>>>> Multiple-jars would be for experienced user who would like to
>>>> override the RI. Everybody else would be happy with the default one. I
>>>> wouldn't call it "multiple JARs", just an "expert" JARs for those who
>>>> have that unfrequent needs.
>>>>
>>>> >
>>>> >> so that you don't need to parse it manually,
>>>> > B) That does not work that way.
>>>> > Can you suggest a piece of "user code" you have in mind?
>>>> >
>>>> > Let me predict it a bit:
>>>> > 1) It processes resultset
>>>> > 2) Fetches "JsonValue"
>>>> > 3) Passes to a business-logic class
>>>> >
>>>> > We can stop here.
>>>> > "business logic class" from #3 will definitely have "JsonValue"
>>>> > classes in its method signatures.
>>>>
>>>> No, it doesn't need to be like that. That you extract a JSON from
>>>> your database, it doesn't mean that you have to have a JSON on your
>>>> business logic. Not at all.
>>>>
>>>>
>>>> > In other words, it would require to have "javax.json" API in the class
>>>> > path to compile.
>>>> >
>>>> > Then I would love to know how is the user addressing that without
>>>> > adding "javax.json" API dependency to her build system of choice.
>>>> >
>>>> > The same business logic should be unit-tested (without DB), shouldn't
>>>> it?
>>>> > That results in "it should be testable without pgdjbc dependency".
>>>>
>>>> As I said, it doesn't need to. So if you *also* have JSON at your
>>>> business-logic then yes, you need the API on your classpath. But that's
>>>> obvious :)
>>>> >
>>>> > C) If we continue creating bundles here and there (not sure what is
>>>> > "non offensive" wording here), the number of possible bundles would
>>>> > explode exponentially. jdbc driver is not an application for end-user,
>>>> > so I do not see much reason why it should "bundle optional
>>>> > dependencies without shading them".
>>>> >
>>>> > For instance, if we decide to use objectweb.asm bytecode transformer,
>>>> > it would be perfectly fine to shade it into org.postgresql.asm...
>>>> > package, so it is not exposed to public.
>>>> >
>>>> > However, with javax.json you cannot do package renaming since it would
>>>> > make no sense.
>>>>
>>>> Right. So there's one bundle (JDBC+API+shaded RI) and another just
>>>> with JDBC, for people that don't want Json and want to save 96Kb on
>>>> their Jars or "expert" people that want to override the RI. That's it.
>>>> 2. That's not an exponential explosion.
>>>>
>>>> >
>>>> > D) Theoretically, we could represent json as java.util.Map /
>>>> > java.util.List by embedding and repackaging some json implementation,
>>>> > however I am not sure if that makes much sense provided JSR353 defines
>>>> > proper interfaces.
>>>> Yeah, I don't think that makes sense.
>>>>
>>>> Regards,
>>>>
>>>> Álvaro
>>>>
>>>>
>>>> --
>>>> Álvaro Hernández Tortosa
>>>>
>>>>
>>>> -----------
>>>> 8Kdata
>>>>
>>>>
>>>>
>>>> --
>>>> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
>>>> To make changes to your subscription:
>>>> http://www.postgresql.org/mailpref/pgsql-jdbc
>>>>
>>>
>>
>