y that
extension
can only be from Java to Scala, which will help the
situation.
However,
I'm
not sure if this is practical.
Thanks,
Xuefu
----------------------
Sender:jincheng sun
Sent at:2018 Nov 23 (Fri) 09:49
Recipient:dev
Subject:Re: [DISCUSS] Long-term goal of making flink-table
S
y that
extension
can only be from Java to Scala, which will help the situation.
However,
I'm
not sure if this is practical.
Thanks,
Xuefu
----------------------
Sender:jincheng sun
Sent at:2018 Nov 23 (Fri) 09:49
Recipient:dev
Subject:Re: [DISCUSS] Long-term
gt;>>>>>>> to
>>>>>>>>>>> bring a smaller impact on users, I think we should go fast when we
>>>>>>>>> migrate
>>>>>>>>>>> APIs targeted to users. It's better to introduce the
s,
Xuefu
----------------------
Sender:jincheng sun
Sent at:2018 Nov 23 (Fri) 09:49
Recipient:dev
Subject:Re: [DISCUSS] Long-term goal of making flink-table
Scala-free
Hi Timo,
Thanks for initiating this great discussion.
Currently when using SQL/T
t; >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Fri, Nov 23, 2018 at 5:36 PM Timo Walther
> >>>>>> wrote:
> >>>>>>>>> Hi everyone,
> >>>>>>>>>
> >
is practical.
Thanks,
Xuefu
----------------------
Sender:jincheng sun
Sent at:2018 Nov 23 (Fri) 09:49
Recipient:dev
Subject:Re: [DISCUSS] Long-term goal of making flink-table
Scala-free
Hi Timo,
Thanks for initiating this great discussion.
gt;>>>> @Xuefu: I extended the document by almost a page to clarify when
> we
> > >>>>>> should develop in Scala and when in Java. As Piotr said, every new
> > >>> Scala
> > >>>>>> line is instant technical debt.
> > >
t;>> Thanks,
> >>>>>> Timo
> >>>>>>
> >>>>>>
> >>>>>> Am 23.11.18 um 10:29 schrieb Piotr Nowojski:
> >>>>>>> Hi Timo,
> >>>>>>>
> >>>>>>> Thanks for writing this d
ension
can only be from Java to Scala, which will help the situation.
However,
I'm
not sure if this is practical.
Thanks,
Xuefu
------
Sender:jincheng sun
Sent at:2018 Nov 23 (Fri) 09:49
Recipient:dev
Subject:Re: [DISCUSS] Lo
pproach here, probably we
> > >> will
> > >>> have to work it out as we go. One thing to consider is that from now
> > on,
> > >>> every single new code line written in Scala anywhere in Flink-table
> > >> (except
> > >>> of Flink-table-ap
ating quite big inchonvieneces
> >>> just to avoid any new Scala code.
> >>>> Piotrek
> >>>>
> >>>>> On 23 Nov 2018, at 03:25, Zhang, Xuefu
> >> wrote:
> >>>>> Hi Timo,
> >>>>>
> >>>>>
However,
I'm
not sure if this is practical.
Thanks,
Xuefu
--
Sender:jincheng sun
Sent at:2018 Nov 23 (Fri) 09:49
Recipient:dev
Subject:Re: [DISCUSS] Long-term goal of making flink-table Scala-free
Hi Timo,
Thanks for initiating this great discussion.
Currently when using SQL/
; the
> > current code base there are cases where a Scala class extends Java and
> vise
> > versa. This is quite painful. I'm thinking if we could say that extension
> > can only be from Java to Scala, which will help the situation. However,
> I'm
> > not sure if
ly be from Java to Scala, which will help the situation. However, I'm
> not sure if this is practical.
> >>
> >> Thanks,
> >> Xuefu
> >>
> >>
> >> --
> >> Sender:
23 (Fri) 09:49
Recipient:dev
Subject:Re: [DISCUSS] Long-term goal of making flink-table Scala-free
Hi Timo,
Thanks for initiating this great discussion.
Currently when using SQL/TableAPI should include many dependence. In
particular, it is not necessary to introduce the specific implementation
de
x27;m thinking if we could say that extension can
> only be from Java to Scala, which will help the situation. However, I'm not
> sure if this is practical.
>
> Thanks,
> Xuefu
>
>
> ------
> Sender:jincheng
sure if this is
practical.
Thanks,
Xuefu
--
Sender:jincheng sun
Sent at:2018 Nov 23 (Fri) 09:49
Recipient:dev
Subject:Re: [DISCUSS] Long-term goal of making flink-table Scala-free
Hi Timo,
Thanks for initiating this great discuss
Hi Timo,
Thanks for initiating this great discussion.
Currently when using SQL/TableAPI should include many dependence. In
particular, it is not necessary to introduce the specific implementation
dependencies which users do not care about. So I am glad to see your
proposal, and hope when we consid
Hi Timo, thanks for driving this! I think that this is a nice thing to do.
While we are doing this, can we also keep in mind that we want to
eventually have a TableAPI interface only module which users can take
dependency on, but without including any implementation details?
Xiaowei
On Thu, Nov 2
Hi Timo,
Thanks for writing up this document.
I like the new structure and agree to prioritize the porting of the
flink-table-common classes.
Since flink-table-runtime is (or should be) independent of the API and
planner modules, we could start porting these classes once the code is
split into the
Hi everyone,
I would like to continue this discussion thread and convert the outcome
into a FLIP such that users and contributors know what to expect in the
upcoming releases.
I created a design document [1] that clarifies our motivation why we
want to do this, how a Maven module structure c
Hi Piotr,
thanks for bumping this thread and thanks for Xingcan for the comments.
I think the first step would be to separate the flink-table module into
multiple sub modules. These could be:
- flink-table-api: All API facing classes. Can be later divided further
into Java/Scala Table API/SQL
-
Hi all,
I also think about this problem these days and here are my thoughts.
1) We must admit that it’s really a tough task to interoperate with Java and
Scala. E.g., they have different collection types (Scala collections v.s.
java.util.*) and in Java, it's hard to implement a method which tak
Bumping the topic.
If we want to do this, the sooner we decide, the less code we will have to
rewrite. I have some objections/counter proposals to Fabian's proposal of doing
it module wise and one module at a time.
First, I do not see a problem of having java/scala code even within one module,
Hi,
In general, I think this is a good effort. However, it won't be easy and I
think we have to plan this well.
I don't like the idea of having the whole code base fragmented into Java
and Scala code for too long.
I think we should do this one step at a time and focus on migrating one
module at a
I think that is a noble and honorable goal and we should strive for it.
This, however, must be an iterative process given the sheer size of the
code base. I like the approach to define common Java modules which are used
by more specific Scala modules and slowly moving classes from Scala to
Java. Th
Hi,
I do not have an experience with how scala and java interacts with each other,
so I can not fully validate your proposal, but generally speaking +1 from me.
Does it also mean, that we should slowly migrate `flink-table-core` to Java?
How would you envision it? It would be nice to be able to
Hi everyone,
as you all know, currently the Table & SQL API is implemented in Scala.
This decision was made a long-time ago when the initital code base was
created as part of a master's thesis. The community kept Scala because
of the nice language features that enable a fluent Table API like
28 matches
Mail list logo
