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