I'll comment in greater detail later today... but in short I've been somewhat uncomfortable with this as well.
In the end, I think it's best if we make clear what things we've tested with and what runtimes we'll accommodate, but allow users to choose what JSON provider they want. You mentioned it being like SLF4J. Another analogy I've heard that is appropriate is that it's like a JDBC provider. I also agree that because of the different generation patterns that are supported across the various providers, it becomes difficult to understand which provider to use in which instance. Intersect that with the particular object type that a user may want to use and it becomes much more painful than it should be. Anyway... wanted to get that on the table. More to come. Thanks for starting the thread Michael. -Nick ----- Original Message ---- From: Michael Elman <[email protected]> To: [email protected] Sent: Sunday, September 13, 2009 3:54:16 AM Subject: [DISCUSS]: JSON implementations Hi all, I'd like to discuss the JSON implementation we have and how they are organized. First, we have json.org implementation embedded inside wink-common. Pros: - Wink ships with a default JSON implementation. - The JAXB-to-JSON implementation is quite fast. Cons: - Currently there is no JSON-to-JAXB implementation. - The built-in json-to-xml doesn't use Badgerfish, while our inner implementation uses Badgerfish. It's inconsistency, since people that are familiar with json.org may expect a different behavior. - wink-common always brings json third-party, even if it is not used. - There is a license problem with json.org classes (see https://issues.apache.org/jira/browse/WINK-159) In addition, we have Jettison support in wink-providers module and Jackson has built-in JAX-RS providers. I don't feel comfortable with this approach. Especially with json.orgsupport we have now. I prefer to separate it to a an additional module under wink-providers and use it for both serialization/de-serialization. So anyone may decide which JSON support to use. Quite similar to Slf4j approach of logging. However, it changes a behavior with 0.1 and probably not so efficient, since a double parsing occurs. Thoughts?
