I would deprecate "org.apache.flink.api.common.time.Time" only if we have
alternative methods for the window api.
If users can only write code by using a deprecated class, that would not be
a good experience.
Otherwise sound good.
Best,
Stephan
On Thu, Sep 12, 2019 at 11:23 AM Zili Chen
Hi,
I've given it a try to switch to Java's Duration for all runtime Java code.
Generally, most of its usages are for @RpcTimeout and testing timeout.
However, do a clean work without touch public interface possibly introduce
bridge codes convert runtime Java Duration to Flink's Time. I don't
Seems everyone is in favor in principle.
- For public APIs, I would keep Time for now (to not break the API).
Maybe add a Duration variant and deprecate the Time variant, but not remove
it before Flink 1.0
- For all runtime Java code, switch to Java's Duration now
- For all Scala code let's
+1 to use Java's Duration instead of Flink's Time.
Regarding to the Duration parsing, we have mentioned this in FLIP-54[1] to
use `org.apache.flink.util.TimeUtils` for the parsing.
Best,
Jark
[1]:
+1 since Java Duration is more common and powerful than Flink Time.
For whether to drop scala Duration for parsing duration OptionConfig, I
think it's another question and should be discussed in another thread.
Thanks,
Zhu Zhu
Becket Qin 于2019年8月24日周六 下午4:16写道：
> +1, makes sense. BTW, we
+1, makes sense. BTW, we probably need a FLIP as this is a public API
change.
On Sat, Aug 24, 2019 at 8:11 AM SHI Xiaogang wrote:
> +1 to replace Flink's time with Java's Duration.
>
> Besides, i also suggest to use Java's Instant for "point-in-time".
> It can take care of time units when we
+1 to replace Flink's time with Java's Duration.
Besides, i also suggest to use Java's Instant for "point-in-time".
It can take care of time units when we calculate Duration between different
instants.
Regards,
Xiaogang
Zili Chen 于2019年8月24日周六 上午10:45写道：
> Hi vino,
>
> I agree that it
Hi vino,
I agree that it introduces extra complexity to replace Duration(Scala)
with Duration(Java) *in Scala code*. We could separate the usage for each
language and use a bridge when necessary.
As a matter of fact, Scala concurrent APIs(including Duration) are used
more than necessary at least
+1 to replace the Time class provided by Flink with Java's Duration:
- Java's Duration has better representation than the Flink's Time class;
- As a built-in Java class, Duration class has a clear advantage over
Java's Time class when interacting with other Java APIs and third-party
Hi Stephan,
I like the idea unify usage of time/duration api. We actually
use at least five different classes for this purposes(see below).
One thing I'd like to pick up is that duration configuration
in Flink is almost in pattern as "60 s" that fits in the pattern
parsed by
Hi all!
Many parts of the code use Flink's "Time" class. The Time really is a "time
interval" or a "Duration".
Since Java 8, there is a Java class "Duration" that is nice and flexible to
use.
I would suggest we start using Java Duration instead and drop Time as much
as possible in the runtime
11 matches
Mail list logo
