beam-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Wegner (JIRA)" <>
Subject [jira] [Commented] (BEAM-134) Investigate use of AutoValue
Date Tue, 29 Mar 2016 21:30:25 GMT


Scott Wegner commented on BEAM-134:

TL;DR: 39 classes in the SDK would be candidates for AutoValue, 12 of which are sufficiently
complex. I recommend we do the work to incorporate AutoValue.

I did some analysis over the current SDK codebase, looking at classes which act as value classes
with boilerplate equals/hashCode implementations; these are good candidates for AutoValue.
Of those, I categorized them based on how much they would value from being converted to AutoValue:
* "low": equality is represented by a single field. Little value in converting.
* "medium": equality represented by 2 fields; AutoValue would remove some complexity and ensure
equals/hashCode are implemented "correctly"
* "high": equality represented by 3 or more fields; at this point, the boilerplate code is
larger and equality is easy to get wrong or break over time. These would benefit from AutoValue.

Based on those definitions, I categorized the SDK codebase, limiting to non-test, non-runner
code, and found:
* Low value: 16 classes
* Medium value: 21 classes
* High value: 12 classes

Based on this, I think AutoValue would be worth including and converting these existing classes.

> Investigate use of AutoValue
> ----------------------------
>                 Key: BEAM-134
>                 URL:
>             Project: Beam
>          Issue Type: Improvement
>          Components: sdk-java-core
>            Reporter: Scott Wegner
>            Assignee: Scott Wegner
>            Priority: Minor
>         Attachments: 0001-Mark-classes-which-might-benefit-from-AutoValue.patch
> The initial PR for [BEAM-118] added a dependency on AutoValue to auto-implement equality
semantics for a new POJO. We decided to remove the dependency because the cost of adding the
dependency for this feature may not be worth it for the value.
> However, we could use AutoValue for all of our POJO's, it might be worth it. The proposal
here is to follow-up with an investigation on whether we would gain significant value to porting
our code to use AutoValue instead of hand-written POJO's.

This message was sent by Atlassian JIRA

View raw message