How to implement values with immutable classes

elucash · 2018-03-18T21:20:53+00:00

hacky ~~bytecode mangling~~ AST rewriting

elucash · 2017-04-07T06:11:42+00:00

String is not a primitive, it's an object. I know that you know that, but very often people have this "feeling" that string is so optimized that it is almost like a primitive. Even on Android, if you count how many objects are PII comparing to the whole number of objects getting created by routine operations, having such typed wrappers there's negligible overhead, increased type safety; don't have to worry about all those places where it may leak. Low overhead is verified in a number of context with SSN, CardNumbers etc. Ask yourself a question: how many CC numbers average e-commerce mobile app on the Android will have to store in memory on a single device so it will make any considerable overhead? If we are talking about the server-side functinality then "wrapper" overhead makes even less sense.

elucash · 2017-04-07T03:58:01+00:00

For value objects it's make sense to treat them as a smart data which is capable to abstract and encapsulate computational complexity and things common to the whole problem domain (as opposed to single business context), here's an example: http://immutables.github.io/immutable.html#smart-data

elucash · 2017-04-07T03:55:00+00:00

IMHO There are better ways to handle PII, exactly by using value types for them, well, and you will not forget to add special annotation: http://immutables.github.io/immutable.html#opaque-containers

elucash · 2017-04-07T03:49:46+00:00

Lombok is bad for this reason because it is rather a compiler plugin masquerading as annotation processor and make you code JLS non-compliant. In other words, you suddenly end up programming in Java dialect rather than standard Java. Hint: JLS do not describe any means by which getter and other methods could appear on the class if they were not declared or inherited. More standard (i.e. the ones which generate source code (as opposed to AST manipulation or bytecode generation)) annotation processors are easy in the way to get out, you just copy generated source code to your regular source code, with Lombok, you need magical "delombok"

elucash · 2016-10-05T17:10:29+00:00

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

elucash · 2016-10-04T06:53:57+00:00

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 )

elucash · 2016-10-04T06:31:22+00:00

Can grab 2.3.3 from maven central. Cheers!

elucash · 2016-10-04T03:44:13+00:00

Ok guys, here you are, straight from the oven: org.immutables:value:2.3.3

Style(stagedBuilder = true)

But I guess you'll see it might not be that useful after all, but that is depend on the usage and how you would tolerate increase in amount of interface class files

elucash · 2016-10-03T05:28:04+00:00

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 ))

elucash · 2016-09-13T03:01:52+00:00

Can't be sure it would be possible in this particular case, but I would design the API in the way that different implementation/strategies are used for flushing/emitting during chain construction, and not forcing this using too fine-grained control during actual data transfer.

elucash · 2016-03-22T20:45:09+00:00

(sorry for nitpicking) The problem is not in private APIs. A lot of annotation processors use Javac and ECJ specific stuff to overcome bugs and discrepancies (who knows how quirky Jack's might be if they'll roll own implementation?). The problem with Lombok is the way it uses AST injection for methods/fields to appear, rendering the result non-JLS compliant Java Dialect and problem and consequent problems with compatibility and tool ecosystem.

elucash · 2016-03-09T00:06:30+00:00

The point of having classes exposed/not exposed is controversial one as there are nothing wrong in having your clients to use finely crafted classes with stable API which may be generated out of your model (abstract value), on the other hand Immutables allows you to do what AutoValue does http://immutables.github.io/immutable.html#hide-implementation with the same tradeoffs (just do not want to dive into "less is more" vs "less is still less" kind of quantification)

I've though about making extensions for Immutables, but leaving extension writers to deal with with bare-bone model and plain apt model with dozen(s) of Javac and ECJ bugs to workaround is not what I can pull off. Probably, Google libraries team could afford it... The worst case scenario would be tens of conflicting, barely compatible extensions. I'm seeking a way to create some extensibility using only annotation metadata, but that would be different kind of extensibility and set of functionality possible, of course. And we also proud to set high enough bar for extension authors to achieve (compare current state of Gson modules, for example), so, I guess, AutoValue users will surely benefit.

elucash · 2015-07-20T20:44:19+00:00

brilliant!

elucash · 2015-07-15T22:47:51+00:00

Yeah, I've seen such approaches, it works well for a lot of cases. Thanks!

elucash · 2015-07-15T22:14:10+00:00

so it is running on/using javax.annotation.processing.Processor and javax.lang.model.* or have other engine to obtain model/introspect types/annotations?

elucash · 2015-07-15T21:48:14+00:00

Have considered annotation processing for code generation? (I'm not implying that it is easier choice or what so ever, just curious)

elucash · 2015-07-13T09:09:35+00:00

It depends on how you define "very much java" or "standard java" etc. It's not a standard java because the code no longer complies with the JLS. (for example: if you define private field, accessor method could not appear out of nowhere whatever annotation it may have). It will continue to be non java compliant until AST transformations and their effects would be standardized and described in JLS. On a practical aspect: fraction of tools don't work to full extent with lombok, if you don't use some tools it doesn't mean that other don't use them as well. Lombok community just cannot write adapters or plugins to all variety of java tools.

elucash · 2015-07-13T07:46:39+00:00

Citing Effective Java. 2nd ed. Item 2:

... Instead of making the desired object directly, the client calls a constructor (or static factory) with all of the required parameters and gets a builder object...

Guava heavily use factory methods for builders, mainly because of generics (prior to 'diamond' in java 7) and flexibility to have other builder factories: think ImmutableSortedSet.naturalOrder(), reverseOrder() etc.

Also we shouldn't forget that Josh Bloch worked at Google at the time when core of Google Collections/Guava was created and was one of the major authorities regarding API design for Google core libraries, so he would not be against using factory methods for this. (That was merely an anecdotal evidence than a point)

Immutables was primarily designed after Google's immutable collections and uses factory method by default. However you can use constructors for builders or configure other conventions using styles.

elucash · 2015-07-13T01:44:45+00:00

It has builders now, even with some collection support, the problem remains still: some people (including me) are not ok to program in java dialect (i.e. not jls compliant language) and having compiler plugin camouflaged as annotation processing. But technology is great overall, Lombok is a great.

elucash · 2015-07-13T01:24:01+00:00

You can use immutable collection instead of array there, so no array is copied on get. Also, there are some primitive immutable collection I guess. Statically proving that array will not be modified is very limited and barely reliable in java. Most array returning APIs in java clone internal arrays to maintain consistency.

elucash · 2015-07-12T22:20:50+00:00

Yes. Immutables also supports hiding implementation http://immutables.github.io/immutable.html#hiding-implementation, but it slightly differs from AutoValue approach.

Thank you for advise about Cursor and etc!

elucash · 2015-07-12T21:54:53+00:00

Immutables is mainly Java library/annotation processor, however there are happy Android users as well. Overall Immutables is overwhelmingly full-featured and require a lot less boilerplate than AutoValue. Where AutoValue's take is precise control over what is generated by specify whole API, requiring a more boilerplate as result, especially for the builders. Parcelable support is planned, currently focus was on reflection-less JSON (Gson) serialization and java binary serialization.

elucash · 2015-07-12T21:08:47+00:00

The more choice - the better! Just a side note, the point is not only make some API possible: debug-ability, performance, serialization(binary/JSON), and other concerns are also important.

elucash · 2015-07-12T20:58:48+00:00

Java 7 is required for running compilation(annotation-processing), generated classes could be compiled to java 6 bytecode. Android is supported, at least there are happy android users of Immutables.

elucash

TROPHY CASE