From: | Florent Guillaume <fg(at)nuxeo(dot)com> |
---|---|
To: | List <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: SQLJSON |
Date: | 2015-07-01 11:57:19 |
Message-ID: | CAF-4BpM7BchkZ3qh+g+eOjLH=w0x3vMynwzTcy-SDLbjAKWEGw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
I totally agree that bundling any kind of external API or non-shaded
library inside the driver would be a very bad thing.
I work every day with a big open source application that has to
include close to 250 external libraries, and trust me anytime some
library tries to do something clever and include other parts of some
APIs that do not belong to its namespace, it's a world of pain. It
even includes libraries that "helpfully" include a log4j.xml,
simplelogger.properties or similar META-INF/services/*, all things
which DON'T belong in a library but in an application.
So please, don't bundle the JSON API or the RI or Jackson in the driver.
The *first time* the developer will try to use it without proper
dependencies he'll get an error message (the driver can provide
helpful errors here), he'll add the missing dependencies, and this
will be it. No big deal, and it keeps things cleanly separated.
Florent
On Wed, Jul 1, 2015 at 1:31 PM, Dave Cramer <pg(at)fastcrypt(dot)com> wrote:
> 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
>>>
>>>
>>
>
--
Florent Guillaume, Director of R&D, Nuxeo
Open Source Content Management Platform for Business Apps
http://www.nuxeo.com http://community.nuxeo.com
From | Date | Subject | |
---|---|---|---|
Next Message | dmp | 2015-07-01 15:33:28 | Re: SQLJSON |
Previous Message | Dave Cramer | 2015-07-01 11:31:57 | Re: SQLJSON |