Re: SQLJSON - Mailing list pgsql-jdbc

>you need the API on your classpath. But that's obvious :)

Do you know of https://en.wikipedia.org/wiki/Principle_of_least_astonishment?
I would call an "astonishment" if my jdbc driver provided "javax.xml"
or "javax.json" or "java.util.concurrent" kind of packages.
Don't you think so?

>users don't realize they need another dependency.

This is trivially resolved via readme. Come on.
If a developer can't figure out he needs "a library for json", why do
we care to support such a developer?

Consider the following section in _current_ readme:

>Currently Waffle-JNA and its dependencies are required for SSPI authentication support (only supported on a JVM
runningon Windows). >Unless you're on Windows and using SSPI you can leave them out when you install the driver. 

So, there already exists a case when optional dependency is
recommended in readme. This might be improved in terms of "ready for
use mvn dependency tags", however it does not follow "bundle
everything" approach.

>Classpath collision is extremely unlikely, I won't bet on it, so why not help the user even more?

http://wiki.osgi.org/wiki/Split_Packages
Google finds 124000 results for "osgi split package".

Is that enough to stop embedding non-renamed packages?

The problem is not specific to OSGi. OSGi just highlights it.

Well, I guess it somehow can be not that convincing, so I throw
another issue on the table:
https://issues.jboss.org/browse/AS7-3305 (~
http://www.nightprogrammer.org/development/hints/illegalaccesserror-packages-classloaders/
)

>we could have provided instead with 0 drawbacks

Could you please reconsider that?

>Classpath collision is extremely unlikely

If the collision happens, we will have no reasonable way of solving that.
It's better to prevent that collision from the start than develop on a
minefield.

> 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
havea JSON on your business logic. Not at all. 

Please provide an example of business logic that extracts json values
and does not get infected its methods' signatures with json classes.
I can't follow your justification while you provide zero examples.

I hope you do not call "POJO processResultSet(ResultSet rs)" kind of
method a "business logic".
It is not testable since it does multiple things: "retrieves jsons and
performs conversion".
At least it should be "JsonValue processRow(ResultSet rs)" + "POJO
convertJsonToPojo(JsonValue)".

>That's it. 2. That's not an exponential explosion.

What do you think about Waffle-JNA then?
Should it be included in "all in one" bundle?
Should pgjdbc have "core", "core+waffle", "core+json", "core+waffle+json" jars?
It is exactly what I call "exponential explosion".

Vladimir