As long as joda stays anywhere in the public API (and removing it would be a backwards incompatible change) we can't drop it as a dependency.
While we could provide java.time overloads for time-accepting methods, time-returning methods can't be as transparently interchangeable. I'm not sure whether the duplication is worth it (until we move to 3.0, at which point if it's mechanical enough (for us and our users) we could just switch over). The situation I'd really rather end up in is where some methods take only joda time, some methods take only java.time, and some take both. Similarly with return values. Whatever we do we should be consistent. On Thu, Sep 27, 2018 at 12:00 PM Łukasz Gajowy <[email protected]> wrote: > +1 to removing joda. IMO from now on we should favor java.time in reviews > over joda.time in new features and feel free to replace joda when > refactoring is done in places where code stays backward-compatibile and > doesn't get duplicated (eg. some class internals, not exposed through class > interface). I'm not sure if adding methods with alternative signatures only > because of the time is the way to go (lots of duplication, low gain?). I > think we should wait with places like this until the 3.0 version. > > Łukasz > > śr., 26 wrz 2018, 20:16 użytkownik Jeff Klukas <[email protected]> > napisał: > >> 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? >>>>>> >>>>>>
