I agree that there's no path to removing joda-time as a dependency in 2.x. If we can it a goal for 3.0 to use java.time consistently and remove joda-time at that point, I'd be very happy.
I have no context, though, on timeline for a 3.0 release. If that's sometime in the next year, then there's likely too much cost and not enough benefit to partially supporting java.time in 2.x. It would be better to leave joda-time as the preferred time library. If Beam 3.0 is further out, then it may still be worth considering if we can add at least partial java.time support. I expect more organizations in the next few years will be trying to enforce use of java.time over joda-time. On Thu, Sep 27, 2018 at 7:59 AM Robert Bradshaw <rober...@google.com> wrote: > 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 <lukasz.gaj...@gmail.com> > 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 <jklu...@mozilla.com> >> 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é <j...@nanthrax.net> >>> 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 <re...@google.com> 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 < 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? >>>>>>> >>>>>>>
