[FLINK-7000] Add custom configuration local environment in Scala StreamExecutionEnvironment

[ch33hau]

See description in FLINK-7000

[zentol]

you're modifying an existing method, didn't you mean to add a new one?

[ch33hau]

Hi @zentol , thanks for taking time for reviewing :)

It was my original thought.
However turns out due to Scala supports default value in parameters, in order to achieve same behaviour as Java, adding a new method is not working here.

This is what currently Java has:

1. createLocalEnvironment()
2. createLocalEnvironment(Int)
3. createLocalEnvironment(Int, Configuration)

Before this PR, in Scala we have:

createLocalEnvironment(Int = defaultValue)

So a Scala user can access this method by createLocalEnvironment() or createLocalEnvironment(someValue).

If I add another method createLocalEnvironment(Int = defaultValue, conf = defaultValue), compiler will complain because at this moment createLocalEnvironment(someValue) is ambiguous.

My opinion is by just adding a parameter with default value to existing method, it doesn't change the existing way to access the method. In addition, Scala user can choose to use default values or override any one of them.

There is also a test in org.apache.flink.streaming.api.scala.DataStreamTest#testParallelism() to make sure that the existing method is working fine.

How do you think?

[zentol]

This method is part of the public API and thus must not be changed.

Does the compiler still complain if there is no default value for the configuration?

[ch33hau]

Do you mean a new method with createLocalEnvironment(Int, conf)?

By this way compiler won't complain, just both the value have to be entered.
However, I do agree that the way that you have suggested could allows user to pass in custom configuration without modifying public API

I could update the PR in a moment.

[ch33hau]

Hi @zentol ,

I have updated PR by adding a new method without default values.

Thanks =)

[zentol]

can the parallelism have a default value?

[ch33hau]

No it can't. I have think about it before, again compiler complains.

It could be related to this scala issue spec

If you have two overloads with defaults on the same parameter position, 
we would need a different naming scheme. 
But we want to keep the generated byte-code stable over multiple compiler runs.

[zentol]

well that's unfortunate.

[zentol]

Will merge this.

[zentol]

well that's unfortunate.

[ch33hau]

Thank you @zentol !