Re: Are there plans for removing joda-time from the beam java SDK?

[Alexey Romanenko <ar...@gmail.com>]

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 <jk...@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 <robertwb@google.com <ma...@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.gajowy@gmail.com <ma...@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 <jklukas@mozilla.com <ma...@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é <jb@nanthrax.net <ma...@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 <relax@google.com <ma...@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 < apilloud@google.com <ma...@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 < jklukas@mozilla.com <ma...@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?
>