On Mon, Jan 2, 2017 at 5:26 AM, Dragan Jotanovic <[email protected]> wrote: > Sorry for resurrecting this old thread, but has there been any more work > around support for serialization of objects that don't have default > constructor?
I haven't had time to investigate this further myself, and have not heard of others doing that yet. But if someone has I hope they can speak up. > I think this is very important feature, as a lot of people would want to use > jackson serialization on legacy classes that can't be changed or third party > classes, so there is no way to add @JsonCreator annotation and creating > mixins and registering them manually for a bunch of classes is just too much > work and maintenance hell. > I understand that you don't want to add yet another dependency but objenesis > is only 50K jar, and it doesn't need to be included by default in jackson > dependencies. Users could add it to dependencies themselves when needed. > We could have a method in ObjectMapper, setInstantiatorStrategy(Class > instantiationStrategy) where we could check if supplied instantiation > strategy is on the classpath and instantiate it (this would most likely be > StdInstantiatorStrategy from objenesis). > Objenesis does not use sun.misc.Unsafe only, it uses various mechanisms for > various JDK implementations, you can check supported JVMs: > https://github.com/easymock/objenesis/blob/master/SupportedJVMs.md > The documentation is here: http://objenesis.org/ I would be happy to help with additional hooks if any are needed, so that a module could be written to add this. It sounds like something for which module system was created: Afterburner (bytecode generation for speed) and Mr Bean (on-the-fly bytecode generation to implement interfaces/abstract classes) are existing examples. It might even be possible to already hook this, via `ValueInstantiator` injection -- this interface is already used for constructing instances regardless of whether it's via no-args constructor or some other creator. The first step might be to see if it's possible to do this, even if it was clumsy; and if so see how process could be streamlined from module-api perspective (or how to make it possible if not yet). I don't think I will have time to work on this myself for immediate future, but I would be interested in helping. And I suspect work involved could be relatively modest; more important is the focus. -+ Tatu +- > > Thanks, > Dragan > > > On Friday, 13 September 2013 16:34:37 UTC+1, tsaloranta wrote: >> >> On Fri, Sep 13, 2013 at 12:50 AM, Tammo van Lessen <[email protected]> >> wrote: >>> >>> On Fri, Sep 13, 2013 at 6:30 AM, Tatu Saloranta <[email protected]> >>> wrote: >>>> >>>> On Thu, Sep 12, 2013 at 1:44 PM, Tammo van Lessen <[email protected]> >>>> wrote: >>>>> >>>>> Hi Tatu, >>>>> >>>>> have you ever considered to use Objenesis to give jacksons databind the >>>>> option to create objects without having to call a constructor? Any >>>>> thoughts >>>>> on this? >>>>> >>>> >>>> I hadn't heard of that library. I am guessing it uses sun.misc.Unsafe's >>>> facilities to do this? >>>> I had thought of using something like that as a fallback, in cases where >>>> there isn't zero-arg constructor or @JsonCreator annotated method, but that >>>> seemed like a niche thing, so never proceeded with it. >>>> >>>> So would there be other benefits besides otherwise impossible to >>>> instantiate classes? >>> >>> >>> No, I think this is the only use case, but a nice one :) But, >>> sun.misc.Unsafe, besides the fact it being >> >> >> Ok. I try hard to avoid adding any new dependencies in core packages, so >> perhaps this could make sense for Afterburner module? Small patches (with >> proper attributions of course) would be a possibility. >> I think there's already an issue filed for this one (was at Codehaus, not >> sure if I moved it over). >> >>> an internal class, seems to provide some other interesting benefits >>> performance wise. The kryo guys have a Unsafe-based field and >>> array-serializer/deserializer [1], which appears to bring a lot of >>> performance improvements [2]. >>> >> >> I have heard comments to that effect, but have never been sure how to use >> it for JSON. With LZF compression I did get very nice improvements; but the >> challenge here is that JSON mostly things boil down to UTF-8 >> encoding/decoding. So efficient int/long access to byte[] (which was the >> major speedup for me) won't help a lot. It could help with Smile, but even >> there VInt encoding is more difficult than fixed lengths. >> >> So I'd need to figure out new tricks for non-binary data here. And would >> definitely be all ears for tips, tricks. :) >> >> -+ Tatu +- >> >>> >>> Best, >>> Tammo >>> >>> [1] https://groups.google.com/d/msg/kryo-users/QI_L_t939_o/iZtFkxBvLG4J >>> [2] https://groups.google.com/d/msg/kryo-users/QzZkt2HA9ew/LRfwP_GYXV8J >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "jackson-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> For more options, visit https://groups.google.com/groups/opt_out. >> >> > -- > You received this message because you are subscribed to the Google Groups > "jackson-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "jackson-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
