We started with Joda because Java 7 time classes were insufficient for our needs. Now that we're on Java 8 we could use Java 8's time libraries (which are much better), but unfortunately that would create backwards-incompatible changes to our APIs. We should add this to the list of things to do when we release Beam 3.0.
Reuven On Wed, Sep 26, 2018 at 10:43 AM Andrew Pilloud <apill...@google.com> wrote: > Last I heard we were actually moving the other way, replacing java.time > with joda-time. See the giant schema PR here: > https://github.com/apache/beam/pull/4964 I don't think this was ever > discussed on the list though. > > Andrew > > On Wed, Sep 26, 2018 at 9:21 AM Jeff Klukas <jklu...@mozilla.com> wrote: > >> It looks like there a few spots in the Beam Java API where users have to >> provide joda-time objects, such as FixedWindows#of(org.joda.time.Duration). >> >> Are there any plans to support java.time objects in addition to joda >> objects? Any plans to eventually remove joda-time? >> >> My personal interest is that my team would like to eventually standardize >> on usage of java.time and remove all explicit usage of joda-time in our >> codebases. Even if joda-time is still pulled in transitively by the beam >> java SDK and used internally, it would be nice for users to be able to >> avoid explicit interaction with joda-time. I'm imagining it would be >> possible to provide additional methods like >> FixedWindows#of(java.time.Duration) and potentially marking the joda-based >> variants as deprecated. >> >> Does this seem worthy of opening a JIRA issue? >> >>
