Therefore, I think the setters should still use the plain objects, as there are anyway no practical way to enforce non-nullity of the arguments.
http://stackoverflow.com/questions/31922866/why-should-java-8s-optional-not-be-used-in-arguments http://dolszewski.com/java/java-8-optional-use-cases/ £0.02 /a general On 2016-11-25 00:47, Clueless Joe (JIRA) wrote:
[ https://issues.apache.org/jira/browse/AVRO-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15694432#comment-15694432 ] Clueless Joe commented on AVRO-1961: ------------------------------------ Thanks a lot for your answer. And don't forget I'm clueless, so it's all deeply open to discussion :) I'll do a PR on your repo tomorrow night regarding the null part, so at least this part will be solved. You're right to think of the transition We're using Avro at work and, to be honest, I was rather thinking of some breaking changes in our dev branches. A smoother transition would be great, but I don't see some currently. How would you transition from the two getters (getFoo and getOptionalFoo) to the one Optional<Foo> getFoo() later on? For the setters, at least having both, with setFoo(Foo fooOrNull) and setFoo(Optional<Foo> foo), is doable code wise. Furthermore in the builder to have both seems handy. I would love to have more feedbacks on the matter actually, to know everyone's feeling. 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)
smime.p7s
Description: S/MIME Cryptographic Signature
