Hi Timo, Thanks for looking into this Timo. It's becoming increasingly messy for my trying to locate the correct functions in IDE :-/
Advertising
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 > >
