#73 Optional in getter

[JP1]

Is there a way to compensate for class with an Optional<?> getter? Trying to use StatefulBeanToCsv + CSVWriter and in the given senerio it writes Optional[2019-09-19]. I am looking or a way that it will print without the "Optional[]" Is there something I can override to do something like if (field.IsPresent) { field.get() } in this situation. Thanks for any help.

protected LocalDate date;

public Optional<localdate> getDate() {
return Optional.ofNullable(date);
}</localdate>

[Andrew Rucker Jones]

So far, there is an easy answer to this question: No, we don't support Optional, because Java 7 is the minimum supported version and Optional was introduced with Java 8.

That said, version 5.0 is coming up, in which we make Java 8 the minimum version. We could consider this request. I have done a little reading today, and I tend to the opinion that using Optional as the return value for an accessor method is not good practice, but not everyone sees it that way, and I'm not usually one to thrust myself into a holy war. Our library is there to make people's lives simpler. I would like to get an opinion from our head developer, Scott Conway, before we make a decision on this request. If we were to go ahead with it, I don't see it being available until version 5.1, which would probably be available four to six months from now, based on historical data of time between our releases.

[Scott Conway]

Oh man I am on the wrong side of that holy war because I have been pissed off over Optional since its inception - I always felt the groovy elvis operator and safe navigator operators were the way to go (https://www.groovy-lang.org/operators.html#safenavigationoperator) and even though they gave a good, even logical, explanation of why they went with Optional I personally felt they wussed out because now we have to carry optional baggage throughout the code.

Let the flame wars begin! <bg></bg>

LOL - really though I will try and take a look at it this weekend and run some different JUnit tests with some different combinations to see what effects it would have.

Andrew - my fear is if we decide to take this on we would have to do it in 5.0 because my gut feeling is that we cannot change public LocalDate getDate() to public Optional<localdate> getDate() without breaking people expecting LocalDate. Thus it would have to go in 5.0 or wait until we have enough breaking changes to justify a 6.0. But that is one of the things I will test this weekend. </localdate>

That said without tests my gut feeling is that this is something you the writer of this support request, because I don't think your name is Nobody or Terrance Hill (https://www.imdb.com/title/tt0070215/), should handle in your bean. I am thinking for the write you should create a custom bean that inherits your original class but returns LocalDate instead of Optional. That would be my final suggestion if my tests show that optional<localdate> and LocalDate don't play well together because I don't want to force users of opencsv to use Optional it should be..... optional for them. </localdate>

Scott :D

Scott :)

[Andrew Rucker Jones]

Sorry, Scott, but I'm not following you at all. I understand the request as follows: the user has a bean class that returns its own member variables as an Optional of whatever type. Possibly he even uses Optional as the parameter type for the setters in the same bean, though he doesn't say that. All he wants is for opencsv to unwrap the Optional when using the getter (or wrap it in an Optional when using the setter). This could probably be done with a few lines of code in FieldAccess.

I don't see anything breaking in this change at all, and I don't know what it has to do with any getDate(). Am I missing something?

[Scott Conway]

Sorry - my bad. I was not looking at the code this morning when I read the
original support request and thought the code example with the getDate was
a suggested change to openCSV method. My fear was if we had an exposed
method that returned type LocalDate (or any class) and changed it to
Optional<localdate> would that break anyone currently expecting the non
optional and that was what I was going to test this weekend.</localdate>

Luckily your confusion confused me enough to actually pull up the code and
realize we don't have a getDate anywhere, we consume the resultSet getDate
but we did not write one. So now I realize the scope of his request was
not for us to return optionals but deal with them in any beans we process.

I apologize for my misunderstanding and the confusion it caused.

Now that I have a better understanding I agree with you this can wait for
5.1 as it should not be a breaking change at all.

I think this means we have to check setters in the CsvToBean and wrap our
values in optional if the field is optional. Tis not fair to handle the
getters but not the setters.

Scott :)

On Fri, Sep 20, 2019 at 11:12 AM Andrew Rucker Jones aruckerjones@users.sourceforge.net wrote:

Sorry, Scott, but I'm not following you at all. I understand the
request as follows: the user has a bean class that returns its own member
variables as an Optional of whatever type. Possibly he even uses Optional
as the parameter type for the setters in the same bean, though he doesn't
say that. All he wants is for opencsv to unwrap the Optional when using the
getter (or wrap it in an Optional when using the setter). This could
probably be done with a few lines of code in FieldAccess.

I don't see anything breaking in this change at all, and I don't know what
it has to do with any getDate(). Am I missing something?

---

• [support-requests:#73]
  https://sourceforge.net/p/opencsv/support-requests/73/ Optional in getter*

Status: open
Group: v1.0 (example)
Created: Thu Sep 19, 2019 05:55 PM UTC by JP1
Last Updated: Fri Sep 20, 2019 02:57 PM UTC
Owner: nobody

Is there a way to compensate for class with an Optional<?> getter? Trying
to use StatefulBeanToCsv + CSVWriter and in the given senerio it writes
Optional[2019-09-19]. I am looking or a way that it will print without
the "Optional[]" Is there something I can override to do something like if
(field.IsPresent) { field.get() } in this situation. Thanks for any help.

protected LocalDate date;

public Optional<localdate> getDate() {
return Optional.ofNullable(date);
}</localdate>

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/opencsv/support-requests/73/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

--
Scott Conway
scott.conway@gmail.com
http://www.conwayfamily.name

[Scott Conway]

Sorry - my bad. I was not looking at the code this morning when I read the original support request and thought the code example with the getDate was a suggested change to openCSV method. My fear was if we had an exposed method that returned type LocalDate (or any class) and changed it to Optional<localdate> would that break anyone currently expecting the non optional and that was what I was going to test this weekend. </localdate>

Luckily your confusion confused me enough to actually pull up the code and realize we don't have a getDate anywhere, we consume the resultSet getDate but we did not write one. So now I realize the scope of his request was not for us to return optionals but deal with them in any beans we process.

I apologize for my misunderstanding and the confusion it caused.

Now that I have a better understanding I agree with you this can wait for 5.1 as it should not be a breaking change at all.

I think this means we have to check setters in the CsvToBean and wrap our values in optional if the field is optional. Tis not fair to handle the getters but not the setters.

Scott :)

[Scott Conway]

P.S. However I am NOT apologizing for any comments that may be viewed as dispairaging towards Optional!

[Andrew Rucker Jones]

😁 No one was asking you to.

[JP1]

Thank you all for your consideration! I apologize for the confusion. This was indeed for my own class not opencsv itself. @sconway I understand your workaround. Which is probably the path I will go down for my immediate need, just hoping I wouldn't have to. Hopefully this will be supported in future release, I understand if not. Again appreciate your attention to this matter.

[Andrew Rucker Jones]

I would write this to wrap null inputs (to a setter) as empty Optionals and unwrap empty Optionals as null outputs (from a getter).

I would also not make accomodations for the case that accessor methods cannot be found and reflection is used -- in that case, the field must be present in the bean class in its original form, and not wrapped in an Optional.

Is that how you would expect to use it?

[Andrew Rucker Jones]

Da ich zwei Wochen lang keine Antwort erhalten habe, habe ich diese Funktion wie beschrieben implementiert.

[Andrew Rucker Jones]

This was actually solved with the release of 5.1 about a month ago. I just failed to close the ticket.