Jeff, thank you for raising this topic. + 1 to final move to java.time in Beam 3.0 I didn’t find a Jira about that, so I created a new one: https://issues.apache.org/jira/browse/BEAM-5530 <https://issues.apache.org/jira/browse/BEAM-5530>
> On 27 Sep 2018, at 15:37, Jeff Klukas <jklu...@mozilla.com> wrote: > > 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 > <mailto: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 > <mailto: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 > <mailto:jklu...@mozilla.com>> napisał: > Looks like https://github.com/apache/beam/pull/4964 > <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 > <mailto: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 > <mailto: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 > <mailto: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 > <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 > <mailto: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? >
