Jackson vs. MOXy

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Jackson vs. MOXy

Robert DiFalco
I'm migrating from Jersey 1.9 to 2.x. Wow, what a lot of odds and ends to relearn. It looks like Moxy is preferred over Jackson (which I use in other parts of my code). I can make this change but before I do  I have some questions:
 
    1. Why is MOXy the "preferred" approach for Jersey 2.x? 
    2. Why was it selected over Jackson? 
    3. Have there been any speed comparisons between Moxy and Jackson for POJO mapping?
    4. Should I just stick with Jackson for Jersey 2.x or will I get some special goodness from MOXy that I wont with Jackson?
Reply | Threaded
Open this post in threaded view
|

Re: Jackson vs. MOXy

Gili
On 13/12/2013 4:41 PM, Robert DiFalco wrote:

> I'm migrating from Jersey 1.9 to 2.x. Wow, what a lot of odds and ends
> to relearn. It looks like Moxy is preferred over Jackson (which I use
> in other parts of my code). I can make this change but before I do  I
> have some questions:
>     1. Why is MOXy the "preferred" approach for Jersey 2.x?
>     2. Why was it selected over Jackson?
>     3. Have there been any speed comparisons between Moxy and Jackson
> for POJO mapping?
>     4. Should I just stick with Jackson for Jersey 2.x or will I get
> some special goodness from MOXy that I wont with Jackson?

My guess is that this is related to
http://blog.bdoughan.com/2013/06/moxy-is-new-default-json-binding.html

I second your question about MOXy though, because in my experience
Jackson is a 1st-class library that should be the default. It also has a
longer positive track record than MOXy.

Gili
Reply | Threaded
Open this post in threaded view
|

Re: Jackson vs. MOXy

Marek Potociar
In reply to this post by Robert DiFalco
We advertise MOXy as the recommended default, because it can support both JSON and XML as well as full set of JAXB annotations and more goodies (e.g. externalized bindings etc.). IOW, you can code your data model POJOs once and have them exposed as both JSON and XML for free. MOXy is also by default available in GlassFish and WebLogic, so you do not need to install any additional libraries in these app servers.

That said, you can use Jackson if you prefer it for some reason. Here's how:

As for other goodies, MOXy has a lot of extra features. From those directly related to Jersey, for example we currently support entity filtering with MOXy JSON providers. (To be fair, this is something we would like to support with Jackson too, sometime soon.)

Performance-wise, our internal tests indicate that Jackson is slightly faster at the moment. However, as soon as real network calls are involved, the performance difference is marginal. In general, you want to worry about design of your REST services wrt. latency caused by network and database communication; small server-side processing performance differences are irrelevant (as long as the server is scalable). 

Marek

On 13 Dec 2013, at 22:41, Robert DiFalco <[hidden email]> wrote:

I'm migrating from Jersey 1.9 to 2.x. Wow, what a lot of odds and ends to relearn. It looks like Moxy is preferred over Jackson (which I use in other parts of my code). I can make this change but before I do  I have some questions:
 
    1. Why is MOXy the "preferred" approach for Jersey 2.x? 
    2. Why was it selected over Jackson? 
    3. Have there been any speed comparisons between Moxy and Jackson for POJO mapping?
    4. Should I just stick with Jackson for Jersey 2.x or will I get some special goodness from MOXy that I wont with Jackson?

Reply | Threaded
Open this post in threaded view
|

Re: Jackson vs. MOXy

Robert DiFalco
Thanks for the great explanation. FWIW, I think you are doing too much
work on your Jackson integration. For example, the code you provide is
tied to 1.9 which has different package paths. Fortunately, Jackson
provides what is needed and you only need to instruct users to include
the jackson json provider jar. Nothing else is needed on the Jersey
end.

On Wed, Dec 18, 2013 at 9:28 AM, Marek Potociar
<[hidden email]> wrote:

> We advertise MOXy as the recommended default, because it can support both
> JSON and XML as well as full set of JAXB annotations and more goodies (e.g.
> externalized bindings etc.). IOW, you can code your data model POJOs once
> and have them exposed as both JSON and XML for free. MOXy is also by default
> available in GlassFish and WebLogic, so you do not need to install any
> additional libraries in these app servers.
>
> That said, you can use Jackson if you prefer it for some reason. Here's how:
> https://jersey.java.net/documentation/2.4.1/media.html#json.jackson
>
> As for other goodies, MOXy has a lot of extra features. From those directly
> related to Jersey, for example we currently support entity filtering with
> MOXy JSON providers. (To be fair, this is something we would like to support
> with Jackson too, sometime soon.)
>
> Performance-wise, our internal tests indicate that Jackson is slightly
> faster at the moment. However, as soon as real network calls are involved,
> the performance difference is marginal. In general, you want to worry about
> design of your REST services wrt. latency caused by network and database
> communication; small server-side processing performance differences are
> irrelevant (as long as the server is scalable).
>
> Marek
>
> On 13 Dec 2013, at 22:41, Robert DiFalco <[hidden email]> wrote:
>
> I'm migrating from Jersey 1.9 to 2.x. Wow, what a lot of odds and ends to
> relearn. It looks like Moxy is preferred over Jackson (which I use in other
> parts of my code). I can make this change but before I do  I have some
> questions:
>
>     1. Why is MOXy the "preferred" approach for Jersey 2.x?
>     2. Why was it selected over Jackson?
>     3. Have there been any speed comparisons between Moxy and Jackson for
> POJO mapping?
>     4. Should I just stick with Jackson for Jersey 2.x or will I get some
> special goodness from MOXy that I wont with Jackson?
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Jackson vs. MOXy

Marek Potociar
First, note that the JAX-RS 1.x @Provider scanning has been made "obsolete", so to say as it was causing many weird issues esp. in multi-aplication setups in Java EE containers. Sometimes unexpected providers got picked which has lead to many nasty errors. This approach is therefore discouraged. Instead, in JAX-RS 2.0 we encourage all the JAX-RS extension implementations to use JAX-RS Features. This is a way how to encapsulate the extension and all the related configuration options into a single, type-safe public facade. At the moment (AFAIK) Jackson library does not provide such feature class, which is why we have added the integration module.

One thing is that we should update to Jackson 2.x. That's no question.
Other thing is what about the module and the feature. If Tatu (the Jackson guy) wants to take the responsibility and expose the feature directly in Jackson and maintain it there, I would be fine with that. Other option is to keep the integration module and the feature in Jersey and update it based on community feedback to better serve the needs of you and other Jersey+Jackson users. For instance, we would like to at some point start supporting entity filtering with Jackson. Having the Jackson module and feature in Jersey will make it easier for us to add such support. 

I do not have the final answer to the above - I have not contacted Tatu about this at all. So right now we plan to stick to maintaining the Jackson feature in Jersey and updating it based on concrete improvement suggestions from community. Read: if you don't like something, tell us what you don't like or what is missing and we will let you know if we can or cannot fix it (and if yes, then how, and if not, then why) or we may ask you for a contribution if we do want to fix it but will not be able to do it any time soon.

[Tatu, if you can hear me, do you have any comments? :-)]

Marek

On 18 Dec 2013, at 18:38, Robert DiFalco <[hidden email]> wrote:

Thanks for the great explanation. FWIW, I think you are doing too much
work on your Jackson integration. For example, the code you provide is
tied to 1.9 which has different package paths. Fortunately, Jackson
provides what is needed and you only need to instruct users to include
the jackson json provider jar. Nothing else is needed on the Jersey
end.

On Wed, Dec 18, 2013 at 9:28 AM, Marek Potociar
<[hidden email]> wrote:
We advertise MOXy as the recommended default, because it can support both
JSON and XML as well as full set of JAXB annotations and more goodies (e.g.
externalized bindings etc.). IOW, you can code your data model POJOs once
and have them exposed as both JSON and XML for free. MOXy is also by default
available in GlassFish and WebLogic, so you do not need to install any
additional libraries in these app servers.

That said, you can use Jackson if you prefer it for some reason. Here's how:
https://jersey.java.net/documentation/2.4.1/media.html#json.jackson

As for other goodies, MOXy has a lot of extra features. From those directly
related to Jersey, for example we currently support entity filtering with
MOXy JSON providers. (To be fair, this is something we would like to support
with Jackson too, sometime soon.)

Performance-wise, our internal tests indicate that Jackson is slightly
faster at the moment. However, as soon as real network calls are involved,
the performance difference is marginal. In general, you want to worry about
design of your REST services wrt. latency caused by network and database
communication; small server-side processing performance differences are
irrelevant (as long as the server is scalable).

Marek

On 13 Dec 2013, at 22:41, Robert DiFalco <[hidden email]> wrote:

I'm migrating from Jersey 1.9 to 2.x. Wow, what a lot of odds and ends to
relearn. It looks like Moxy is preferred over Jackson (which I use in other
parts of my code). I can make this change but before I do  I have some
questions:

   1. Why is MOXy the "preferred" approach for Jersey 2.x?
   2. Why was it selected over Jackson?
   3. Have there been any speed comparisons between Moxy and Jackson for
POJO mapping?
   4. Should I just stick with Jackson for Jersey 2.x or will I get some
special goodness from MOXy that I wont with Jackson?



Reply | Threaded
Open this post in threaded view
|

Re: Jackson vs. MOXy

Gili
In reply to this post by Robert DiFalco
However... Jersey should correct their documentation. Pointing users in
the wrong direction doesn't help anybody.

Gili

On 18/12/2013 12:38 PM, Robert DiFalco wrote:

> Thanks for the great explanation. FWIW, I think you are doing too much
> work on your Jackson integration. For example, the code you provide is
> tied to 1.9 which has different package paths. Fortunately, Jackson
> provides what is needed and you only need to instruct users to include
> the jackson json provider jar. Nothing else is needed on the Jersey
> end.
>
> On Wed, Dec 18, 2013 at 9:28 AM, Marek Potociar
> <[hidden email]> wrote:
>> We advertise MOXy as the recommended default, because it can support both
>> JSON and XML as well as full set of JAXB annotations and more goodies (e.g.
>> externalized bindings etc.). IOW, you can code your data model POJOs once
>> and have them exposed as both JSON and XML for free. MOXy is also by default
>> available in GlassFish and WebLogic, so you do not need to install any
>> additional libraries in these app servers.
>>
>> That said, you can use Jackson if you prefer it for some reason. Here's how:
>> https://jersey.java.net/documentation/2.4.1/media.html#json.jackson
>>
>> As for other goodies, MOXy has a lot of extra features. From those directly
>> related to Jersey, for example we currently support entity filtering with
>> MOXy JSON providers. (To be fair, this is something we would like to support
>> with Jackson too, sometime soon.)
>>
>> Performance-wise, our internal tests indicate that Jackson is slightly
>> faster at the moment. However, as soon as real network calls are involved,
>> the performance difference is marginal. In general, you want to worry about
>> design of your REST services wrt. latency caused by network and database
>> communication; small server-side processing performance differences are
>> irrelevant (as long as the server is scalable).
>>
>> Marek
>>
>> On 13 Dec 2013, at 22:41, Robert DiFalco <[hidden email]> wrote:
>>
>> I'm migrating from Jersey 1.9 to 2.x. Wow, what a lot of odds and ends to
>> relearn. It looks like Moxy is preferred over Jackson (which I use in other
>> parts of my code). I can make this change but before I do  I have some
>> questions:
>>
>>      1. Why is MOXy the "preferred" approach for Jersey 2.x?
>>      2. Why was it selected over Jackson?
>>      3. Have there been any speed comparisons between Moxy and Jackson for
>> POJO mapping?
>>      4. Should I just stick with Jackson for Jersey 2.x or will I get some
>> special goodness from MOXy that I wont with Jackson?
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Jackson vs. MOXy

Robert DiFalco
In reply to this post by Marek Potociar
Thanks Mark, makes sense. I think then that updating JacksonFeature to
use 2.3.0 will be problematic as the provider jar defines
META-INF.services that automatically load JacksonJsonProvider.

As for options, I would like to be able to register it as an Object
(rather than a class) so that it can be a singleton and that I can add
things to the ObjectMapper such as the AfterburnerModule. The
currently feature not only uses 1.9 but it is instantiated for every
request (which is not necessary for ObjectMapper which is a heavy
weight object).

Right now I am just copying the classes that make up
JacksonJsonProvider and putting it into my own feature that registers
it as a singleton. Then I don't have to include the Jackson jar that
has the META-INF.services defined. I also not that Jersey uses
META-INF.services for its own internal stuff. I'm not super familiar
with this functionality but it seems like an all or nothing approach.
Those classes in services are ALWAYS instantiated (regardless of the
jar) by ServiceFinder. Or they are all NOT instantiated if the DISABLE
meta inf is enabled.

Again, I'm just learning all this stuff so I apologize if my questions
or approaches are naive. All I want ultimately is to configure my own
Json Provider using the settings I like (singleton or otherwise) and
that uses the implementation I like and not mess things up. :)

On Wed, Dec 18, 2013 at 12:08 PM, Marek Potociar
<[hidden email]> wrote:

> First, note that the JAX-RS 1.x @Provider scanning has been made "obsolete",
> so to say as it was causing many weird issues esp. in multi-aplication
> setups in Java EE containers. Sometimes unexpected providers got picked
> which has lead to many nasty errors. This approach is therefore discouraged.
> Instead, in JAX-RS 2.0 we encourage all the JAX-RS extension implementations
> to use JAX-RS Features. This is a way how to encapsulate the extension and
> all the related configuration options into a single, type-safe public
> facade. At the moment (AFAIK) Jackson library does not provide such feature
> class, which is why we have added the integration module.
>
> One thing is that we should update to Jackson 2.x. That's no question.
> Other thing is what about the module and the feature. If Tatu (the Jackson
> guy) wants to take the responsibility and expose the feature directly in
> Jackson and maintain it there, I would be fine with that. Other option is to
> keep the integration module and the feature in Jersey and update it based on
> community feedback to better serve the needs of you and other Jersey+Jackson
> users. For instance, we would like to at some point start supporting entity
> filtering with Jackson. Having the Jackson module and feature in Jersey will
> make it easier for us to add such support.
>
> I do not have the final answer to the above - I have not contacted Tatu
> about this at all. So right now we plan to stick to maintaining the Jackson
> feature in Jersey and updating it based on concrete improvement suggestions
> from community. Read: if you don't like something, tell us what you don't
> like or what is missing and we will let you know if we can or cannot fix it
> (and if yes, then how, and if not, then why) or we may ask you for a
> contribution if we do want to fix it but will not be able to do it any time
> soon.
>
> [Tatu, if you can hear me, do you have any comments? :-)]
>
> Marek
>
> On 18 Dec 2013, at 18:38, Robert DiFalco <[hidden email]> wrote:
>
> Thanks for the great explanation. FWIW, I think you are doing too much
> work on your Jackson integration. For example, the code you provide is
> tied to 1.9 which has different package paths. Fortunately, Jackson
> provides what is needed and you only need to instruct users to include
> the jackson json provider jar. Nothing else is needed on the Jersey
> end.
>
> On Wed, Dec 18, 2013 at 9:28 AM, Marek Potociar
> <[hidden email]> wrote:
>
> We advertise MOXy as the recommended default, because it can support both
> JSON and XML as well as full set of JAXB annotations and more goodies (e.g.
> externalized bindings etc.). IOW, you can code your data model POJOs once
> and have them exposed as both JSON and XML for free. MOXy is also by default
> available in GlassFish and WebLogic, so you do not need to install any
> additional libraries in these app servers.
>
> That said, you can use Jackson if you prefer it for some reason. Here's how:
> https://jersey.java.net/documentation/2.4.1/media.html#json.jackson
>
> As for other goodies, MOXy has a lot of extra features. From those directly
> related to Jersey, for example we currently support entity filtering with
> MOXy JSON providers. (To be fair, this is something we would like to support
> with Jackson too, sometime soon.)
>
> Performance-wise, our internal tests indicate that Jackson is slightly
> faster at the moment. However, as soon as real network calls are involved,
> the performance difference is marginal. In general, you want to worry about
> design of your REST services wrt. latency caused by network and database
> communication; small server-side processing performance differences are
> irrelevant (as long as the server is scalable).
>
> Marek
>
> On 13 Dec 2013, at 22:41, Robert DiFalco <[hidden email]> wrote:
>
> I'm migrating from Jersey 1.9 to 2.x. Wow, what a lot of odds and ends to
> relearn. It looks like Moxy is preferred over Jackson (which I use in other
> parts of my code). I can make this change but before I do  I have some
> questions:
>
>    1. Why is MOXy the "preferred" approach for Jersey 2.x?
>    2. Why was it selected over Jackson?
>    3. Have there been any speed comparisons between Moxy and Jackson for
> POJO mapping?
>    4. Should I just stick with Jackson for Jersey 2.x or will I get some
> special goodness from MOXy that I wont with Jackson?
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Jackson vs. MOXy

Marek Potociar

On 18 Dec 2013, at 21:18, Robert DiFalco <[hidden email]> wrote:

> Thanks Mark, makes sense. I think then that updating JacksonFeature to
> use 2.3.0 will be problematic as the provider jar defines
> META-INF.services that automatically load JacksonJsonProvider.

At the moment we only support all-or-nothing enabling/disabling of META-INF/services scanning. If Jackson will not give us a hand and remove their entries, we could add support for selective per-implementation class disabling and use it in the JacksonFeature.

>
> As for options, I would like to be able to register it as an Object
> (rather than a class) so that it can be a singleton and that I can add
> things to the ObjectMapper such as the AfterburnerModule. The
> currently feature not only uses 1.9 but it is instantiated for every
> request (which is not necessary for ObjectMapper which is a heavy
> weight object).

Would the custom OM context resolver that I have mentioned earlier work? You could just implement it to always provide the same instance.

>
> Right now I am just copying the classes that make up
> JacksonJsonProvider and putting it into my own feature that registers
> it as a singleton. Then I don't have to include the Jackson jar that
> has the META-INF.services defined. I also not that Jersey uses
> META-INF.services for its own internal stuff. I'm not super familiar
> with this functionality but it seems like an all or nothing approach.
> Those classes in services are ALWAYS instantiated (regardless of the
> jar) by ServiceFinder. Or they are all NOT instantiated if the DISABLE
> meta inf is enabled.

There is a property to disable META-INF/services scanning (I have already found it IIUC).
>
> Again, I'm just learning all this stuff so I apologize if my questions
> or approaches are naive. All I want ultimately is to configure my own
> Json Provider using the settings I like (singleton or otherwise) and
> that uses the implementation I like and not mess things up. :)

No problem at all. :)

Marek

>
> On Wed, Dec 18, 2013 at 12:08 PM, Marek Potociar
> <[hidden email]> wrote:
>> First, note that the JAX-RS 1.x @Provider scanning has been made "obsolete",
>> so to say as it was causing many weird issues esp. in multi-aplication
>> setups in Java EE containers. Sometimes unexpected providers got picked
>> which has lead to many nasty errors. This approach is therefore discouraged.
>> Instead, in JAX-RS 2.0 we encourage all the JAX-RS extension implementations
>> to use JAX-RS Features. This is a way how to encapsulate the extension and
>> all the related configuration options into a single, type-safe public
>> facade. At the moment (AFAIK) Jackson library does not provide such feature
>> class, which is why we have added the integration module.
>>
>> One thing is that we should update to Jackson 2.x. That's no question.
>> Other thing is what about the module and the feature. If Tatu (the Jackson
>> guy) wants to take the responsibility and expose the feature directly in
>> Jackson and maintain it there, I would be fine with that. Other option is to
>> keep the integration module and the feature in Jersey and update it based on
>> community feedback to better serve the needs of you and other Jersey+Jackson
>> users. For instance, we would like to at some point start supporting entity
>> filtering with Jackson. Having the Jackson module and feature in Jersey will
>> make it easier for us to add such support.
>>
>> I do not have the final answer to the above - I have not contacted Tatu
>> about this at all. So right now we plan to stick to maintaining the Jackson
>> feature in Jersey and updating it based on concrete improvement suggestions
>> from community. Read: if you don't like something, tell us what you don't
>> like or what is missing and we will let you know if we can or cannot fix it
>> (and if yes, then how, and if not, then why) or we may ask you for a
>> contribution if we do want to fix it but will not be able to do it any time
>> soon.
>>
>> [Tatu, if you can hear me, do you have any comments? :-)]
>>
>> Marek
>>
>> On 18 Dec 2013, at 18:38, Robert DiFalco <[hidden email]> wrote:
>>
>> Thanks for the great explanation. FWIW, I think you are doing too much
>> work on your Jackson integration. For example, the code you provide is
>> tied to 1.9 which has different package paths. Fortunately, Jackson
>> provides what is needed and you only need to instruct users to include
>> the jackson json provider jar. Nothing else is needed on the Jersey
>> end.
>>
>> On Wed, Dec 18, 2013 at 9:28 AM, Marek Potociar
>> <[hidden email]> wrote:
>>
>> We advertise MOXy as the recommended default, because it can support both
>> JSON and XML as well as full set of JAXB annotations and more goodies (e.g.
>> externalized bindings etc.). IOW, you can code your data model POJOs once
>> and have them exposed as both JSON and XML for free. MOXy is also by default
>> available in GlassFish and WebLogic, so you do not need to install any
>> additional libraries in these app servers.
>>
>> That said, you can use Jackson if you prefer it for some reason. Here's how:
>> https://jersey.java.net/documentation/2.4.1/media.html#json.jackson
>>
>> As for other goodies, MOXy has a lot of extra features. From those directly
>> related to Jersey, for example we currently support entity filtering with
>> MOXy JSON providers. (To be fair, this is something we would like to support
>> with Jackson too, sometime soon.)
>>
>> Performance-wise, our internal tests indicate that Jackson is slightly
>> faster at the moment. However, as soon as real network calls are involved,
>> the performance difference is marginal. In general, you want to worry about
>> design of your REST services wrt. latency caused by network and database
>> communication; small server-side processing performance differences are
>> irrelevant (as long as the server is scalable).
>>
>> Marek
>>
>> On 13 Dec 2013, at 22:41, Robert DiFalco <[hidden email]> wrote:
>>
>> I'm migrating from Jersey 1.9 to 2.x. Wow, what a lot of odds and ends to
>> relearn. It looks like Moxy is preferred over Jackson (which I use in other
>> parts of my code). I can make this change but before I do  I have some
>> questions:
>>
>>   1. Why is MOXy the "preferred" approach for Jersey 2.x?
>>   2. Why was it selected over Jackson?
>>   3. Have there been any speed comparisons between Moxy and Jackson for
>> POJO mapping?
>>   4. Should I just stick with Jackson for Jersey 2.x or will I get some
>> special goodness from MOXy that I wont with Jackson?
>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Jackson vs. MOXy

a_bhatt
This post has NOT been accepted by the mailing list yet.
Mark,

This is great information. I am fairly new to Jersey was trying to understand the META-INF/services scanning. I am currently using JacksonFeature which got the 1.9 version of Jackson. However the Jackson jars that I have don't have the SPIs defined in the META-INF folder. This was confusing me a little bit so I wanted your opinion/clarification on it.

Also, is Jersey using the Java 6 ServiceLoader class for META-INF scanning or is it using something custom? I would like to learn further about Jersey rather than simply using it so that I can contribute in the future.

Ankit
Reply | Threaded
Open this post in threaded view
|

Re: Jackson vs. MOXy

gkumar
In reply to this post by Marek Potociar
Does Moxy provide support for XML output and entity data filtering. I was able to produce a JSON output with MoxyJsonConfig() and entity filtering support in Jersey.
Reply | Threaded
Open this post in threaded view
|

Re: Jackson vs. MOXy

Michal Gajdos
Hi,

unfortunately, not at the moment. Only JSON via MOXy is currently supported. We plan to add support for XML via MOXy and for JSON via Jackson.

Michal

> On 14 Aug, 2014, at 20:06 , gkumar <[hidden email]> wrote:
>
> Does Moxy provide support for XML output and entity data filtering. I was
> able to produce a JSON output with MoxyJsonConfig() and entity filtering
> support in Jersey.
>
>
>
> --
> View this message in context: http://jersey.576304.n2.nabble.com/Jackson-vs-MOXy-tp7581625p7582581.html
> Sent from the Jersey mailing list archive at Nabble.com.