Re: SQLJSON

Christopher BROWN 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
>

+1

danap