Looks like https://github.com/apache/beam/pull/4964 is somewhat different from what I had in mind. As Reuven mentioned, I'm specifically interested in using the Java 8 java.time API as a drop-in replacement for joda-time objects so that we don't have to rely on an external library. PR 4964 is using joda-time objects to replace older java.util and java.sql objects with richer joda-time alternatives.
Reuven mentioned a "list of things to do when we release Beam 3.0". Is there a JIRA issue or other document that's tracking Beam 3.0 work? Reuven also mentioned that using java.time would introduce backwards-incompatible changes to the Beam 2.x API, but in many cases (such as FixedWindows) we could introduce alternative method signatures so that we can support both joda and java.time. If there are methods that return joda-time objects, it may be less feasible to support both. On Wed, Sep 26, 2018 at 1:51 PM Jean-Baptiste Onofré <[email protected]> wrote: > +1 > > It makes sense to me and it's also a plan to "split" the core in more > grained modules, and give a more API flavor to Beam 3. > > Regards > JB > Le 26 sept. 2018, à 13:49, Reuven Lax <[email protected]> a écrit: >> >> 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 < [email protected]> >> 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 < [email protected]> >>> 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? >>>> >>>>
