Re: SQLJSON

>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 running on 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 have a 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