FasterXML / jackson-jr

Stand-alone data-binding module designed as a light-weight (and -featured) alternative to `jackson-databind`: will only deal with "Maps, Lists, Strings, wrappers and Java Beans" (jr-objects), or simple read-only trees (jr-stree)
Apache License 2.0
239 stars 31 forks source link

Afterburner (or Blackbird) with jackson-jr? #47

Open Macarse opened 8 years ago

Macarse commented 8 years ago

As far as I understand afterburner can't be used with jackson-jr.

Is there any plan to "port" afterburner?

cowtowncoder commented 8 years ago

@Macarse I have toyed with the idea as I don't think that is a bad idea at all. I think that should be an optional add-on, similar to how it works with regular Jackson; partly because there is still some additional risk of failures (since it's more elaborate setup with bytecode generation etc), and partly because it just won't work on Android.

I have not worked on anything like this, but I think idea itself is valid and I would love to help if anyone wants to prototype the idea.

Macarse commented 8 years ago

@cowtowncoder afterburner + databind doesn't work on Android?

cowtowncoder commented 8 years ago

Correct: Android bytecode is not Java bytecode but its own thing, and may or may not be dynamically loadable. If it is, then different support library (Afterburner uses asm) could be used to generate Dalvik bytecode for android java vm.

Some of techniques that Afterburner uses would actually work (specifically, use of JsonParser.nextFieldName()), but majority of speedup is from bytecode generation to avoid reflection calls.

Macarse commented 8 years ago

@cowtowncoder I am interested in Android. I was checking another library called LoganSquare: https://github.com/bluelinelabs/LoganSquare There is an issue open mentioning that LoganSquare is not AS fast as it was before: https://github.com/bluelinelabs/LoganSquare/issues/159

Inside their repo they have a comparison of a couple of libraries but jackson-jr is not there. So I wanted to give it a try. I have tried replacing Jackson with Jackson-Jr in my personal branch: https://github.com/Macarse/LoganSquare/tree/macarse/jacksonJr but it just doesn't work :(

Is there a way to see logs?

cowtowncoder commented 8 years ago

@Macarse logs of... ? Neither Jackson nor jackson-jr logs anything

FWIW LoganSquare does use streaming parer/generator from jackson-core, so the suggestion by someone that it is much more likely that new version helps with regular Jackson databind to get closer, than that LS is slowed down. Android reflection performance, specifically, was abysmally bad before, so if that is sped up, difference would be big.

Still would be interesting to see jackson-jr; on JavaSE jr has performance similar to regular jackson. And with version 2.8 can use fields, not just getter/setter methods.

Macarse commented 8 years ago

@cowtowncoder oh interesting. How do you usually figure out what's wrong?

The code is serializing with:

String ret = JSON.std.asString(response);

Logs show that the String output is:{} and I can't find what's wrong :(

cowtowncoder commented 8 years ago

@Macarse what is the class like? It would first sound like there were no public getters available on that object -- jackson-jr versions before 2.8.0 required getters. It is also not an error if no properties are found (unlike default settings with Jackson).

Macarse commented 8 years ago

@cowtowncoder wait, what?

I am using jackson-jr in my work project and I am using it without getters and setters. Just public fields.

Macarse commented 8 years ago

@cowtowncoder ok, I am clueless. Adding getters and setters fixed the LoganSquare Demo. I will update my code.

How come my model works without getters and setters?

Macarse commented 8 years ago

btw, this is the result of running my branch in a nexus 6p with developer preview 4.

screenshot_20160719-165146

screenshot_20160719-165212

cowtowncoder commented 8 years ago

Cool. So, on fields -- version 2.8.0 DOES support use of simple public fields. Older versions (up 2.7) do NOT. So it depends on version. Support for fields was added since Android developers mentioned that there are reasons for wanting to avoid use of fields.

Interesting numbers; clearly Moshi has been geared at Android use as its numbers are better than GSON here, which is different from J2SE where GSON seems to be faster.

Macarse commented 8 years ago

I found my issue, after cleaning the build my code stop working. Apparently I started using 2.8 and changed it to 2.7.x but the dependency was not updated.

@cowtowncoder do you maintain a changelog? I can't find any doc which says 2.8 supports fields and 2.7 does not. I would also like to know if 2.8.1 is prod ready.

cowtowncoder commented 8 years ago

Yes, changelog is under release-notes/VERSION, and entry for field addition is #26. In addition, Jackson release notes:

https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.8

list this change (although list of all changes is sometimes incomplete; modules keep actual changes in release-notes/VERSION and those should be complete change lists).

2.8.1 is now released.

Macarse commented 8 years ago

@cowtowncoder thanks. since I am only going to use USE_FIELDS, should I turn off other features? for example USE_IS_GETTERS.

cowtowncoder commented 8 years ago

@Macarse yes, you may want to do that; if it's left on, getter/setter is used instead of field if one exists, otherwise field is used. So if you never plan on using getters, turn them off; ditto for setters.

re-thc commented 6 years ago

What would be required to add Afterburner style support? Can this still be evaluated?

cowtowncoder commented 6 years ago

@hc-codersatlas If anyone wants to implement it, I'd be happy to help. I do not have any extra time to work on this personally. But then again, mr-bean came as external contribution, and then served as basis of Afterburner.

But basically jackson-jr does not have any extension points to support this yet. Adding extension points might not be superbly difficult, and it might even make sense to add support for ability to map abstract types to concrete more generally (since the two parts are related in Jackson).