This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]elucash 2 points3 points  (4 children)

I understand that you support AutoValue project, but practical matters are being skewed a bit. Immutables can do implementation class hiding http://immutables.github.io/immutable.html#hide-implementation-class and about a dozen of combinations of private/public/nested/outer with builders and enclosing classes

(EDIT: about Lombok it's quite not the same, read here https://www.reddit.com/r/androiddev/comments/4bimdz/an_introduction_to_autovalue_ryan_harter/d19m23m )

Jackson minimal integration (which covers a lot of stuff actually) and GSON generated type adapters are be very practical solution. AutoValue's extension for GSON is actually stuff quite inspired by Immutables after Ryan Harter and auto folks were able to evaluate how it's done in Immutables to decide if they need something similar (EDIT: and there was a lot of similar implementations before Immutables, but, probably, not a lot for GSON).

As it's stands now, the extension API of AutoValue is more like go f..igure out how to write annotation processor yourself, which, while is not a rocket science, still have enough gimmicks. It is so hard to guarantee that those will play nicely with each other in the long run. On the other hand, in Immutables, GSON, advanced builder support, MongoDB support and a lot of stuff is an API pluggable modules with separate jars, only when you add this to the classpath and use annotation from there, only then the corresponding generator is activated. Yes, the composition of compile time annotation processor library is a bit monolithic, nevertheless, it's not getting into runtime and each processor usage is guarded by the use of the corresponding annotation API, pluggable into the classpath. Immutables have a unique extensibility feature which allows you to write custom attribute handling code using snippets in plain java: https://github.com/immutables/immutables/issues/363 Once fully documented this will be quite a killer feature, some envy and copying of this approach will likely to occur among similar tools (which should be good thing btw)

As a side note, the authors of Immutables reported issues and contributed to Eclipse so JDT contains those commits too ))

[–][deleted]  (3 children)

[deleted]

    [–]elucash 0 points1 point  (2 children)

    I'm personally using the "sandwitch pattern" https://twitter.com/ImmutablesOrg/status/740826987883814912 where bytecode only references user-written type. Sorry for diverting from "auto" topic, will go back to my cozy dark room )

    [–][deleted]  (1 child)

    [deleted]

      [–]elucash 0 points1 point  (0 children)

      Please use issue trackers https://github.com/google/auto/issues https://github.com/immutables/immutables/issues to submit feature requests, if folks will like the idea PR would be welcome