[
https://issues.apache.org/jira/browse/AVRO-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15691487#comment-15691487
]
Clueless Joe edited comment on AVRO-1961 at 11/23/16 10:08 PM:
---------------------------------------------------------------
Hi Niels and all
Thanks a lot for this issue, I was about to create it.
>From what I've seen in your code, you plan to let the current getter/setter
>and add a getOptionalFoo, not considering whether the field accepts null or
>not.
Indeed, IMHO, the main goal of the optional is to make sure every developers
knows a field can hold a null value (or not). In the current template, there's
no easy way to figure this out, so one can easily forget to handle nullity.
Which leads to plenty of NullPointerExcepteion.
By letting the current getter (which return nulls), the risk is still highly
present.
When regenerating pojos with your optional, then the code would still compile
whereas in many cases the developer may have forgotten the value can be null.
When activating your createOptionalGetters, what about changing the getter to
return Optional<Foo> instead of just Foo only when the field can have a null
value?
As such the IDE/type would make sure the developer handles the potential null
values. NPE would be way less frequent.
For the setter, I've no opinion on the way to go. Currently we don't generate
them. I guess changing the setter for potentially null values to
setFoo(Optional<Foo> foo) would make sense again in terms of revealing the
intent. Or maybe putting both, for convenience. Maybe the setter without an
Optional could have its parameter name completed by "OrNull" to explicit the
potential null value, for example setFoo(Foo fooOrNull).
Whatever the choice made for the setter, we should then apply it as well to the
builder.
Eager to read you back
Thanks again
best
cluelessjoe
was (Author: cluelessjoe):
Hi Niels and all
Thanks a lot for this issue, I was about to create it.
>From what I've seen in your code, you plan to let the current getter/setter
>and add a getOptionalFoo.
Why letting the previous getter?
Indeed, IMHO, the main goal of the optional is to make sure every developers
knows a field can hold a null value. In the current template, there's no easy
way to figure this out, so one can easily forget to handle nullity. IMHO this
would the main thing to target when introducing Optional: to make sure there's
no doubt about what can be null and what can't be null.
By letting the current getter (which return nulls), the risk is still highly
present.
When regenerating pojos with your optional, then the code would still look
right whereas in many cases the developer may have forgotten the value can be
null.
When activating your createOptionalGetters, what about only changing the getter
to return Optional<Foo> instead of just Foo only when the field can have a null
value?
As such the IDE/type would make sure the developer handles the potential null
values.
For the setter, I've no opinion on the way to go. Currently we don't generate
them. I guess changing the setter for potentially null values to
setFoo(Optional<Foo> foo) would make sense again in terms of revealing the
intent. Or maybe putting both, for convenience. Maybe the setter without an
Optional could have its parameter name completed by "OrNull" to explicit the
potential null value, for example setFoo(Foo fooOrNull).
Whatever the choice made for the setter, we should then apply it as well to the
builder.
Eager to read you back
Thanks again
best
cluelessjoe
> [JAVA] Generate getters that return an Optional
> -----------------------------------------------
>
> Key: AVRO-1961
> URL: https://issues.apache.org/jira/browse/AVRO-1961
> Project: Avro
> Issue Type: New Feature
> Reporter: Niels Basjes
> Assignee: Niels Basjes
> Priority: Minor
>
> A colleague of mine indicated that having getters that return an Optional
> (java 8 thingy) would be very useful for him.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
