jackson-jr
jackson-jr copied to clipboard
FasterXML
Afterburner (or Blackbird) with jackson-jr?
As far as I understand afterburner can't be used with jackson-jr.
Is there any plan to "port" afterburner?
@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.
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.
@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?
@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.
@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 :(
@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).
@cowtowncoder wait, what?
I am using jackson-jr in my work project and I am using it without getters and setters. Just public fields.
@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?
btw, this is the result of running my branch in a nexus 6p with developer preview 4.
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.
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.
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.
@cowtowncoder thanks. since I am only going to use USE_FIELDS, should I turn off other features? for example USE_IS_GETTERS.
@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.
What would be required to add Afterburner style support? Can this still be evaluated?
@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).