+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, à 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? >>> >>>
