Hi Timo,

Thanks for looking into this Timo. It's becoming increasingly messy for my
trying to locate the correct functions in IDE :-/

This is probably due to the fact that Scala and Java access modifiers /
qualifiers are subtly and fundamentally different. Using Trait might be the
best solution here. Another way I can think of is to move the all
TableEnvironment classes to Java side, but that would probably introduce a
lot of issue we need to resolve on the Scala side though. "protected" is
less restrictive in Java but there's really no equivalent of package
private modifier on Java.

I was wondering is there any better way to provide backward-compatible
support though. I played around with it and seems like every "protected"
field will create a private Java member and a public getter, should we add
them all and annotate with "@Deprecated" ?
--
Rong

On Thu, Mar 1, 2018 at 10:58 AM, Timo Walther <twal...@apache.org> wrote:

> Hi everyone,
>
> I'm currently thinking about how to implement FLINK-8606. The reason
> behind it is that Java users are able to see all variables and methods that
> are declared 'private[flink]' or even 'protected' in Scala. Classes such as
> TableEnvironment look very messy from the outside in Java. Since we cannot
> change the visibility of Scala protected members, I was thinking about a
> bigger change to solve this issue once and for all. My idea is to convert
> all TableEnvironment classes and maybe the Table class into traits. The
> actual implementation would end up in some internal classes such as
> "InternalTableEnvironment" that implement the public traits. The goal would
> be to stay source code compatible.
>
> What do you think?
>
> Regards,
> Timo
>
>

Reply via email to