Re: SQLJSON
От | dmp |
---|---|
Тема | Re: SQLJSON |
Дата | |
Msg-id | 55940848.4080606@ttc-cmc.net обсуждение исходный текст |
Ответ на | Re: SQLJSON (Christopher BROWN <brown@reflexe.fr>) |
Список | pgsql-jdbc |
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
В списке pgsql-jdbc по дате отправления: