+1
It could be regarded as part of Flink client api refactor.
Removal of stale code paths helps reason refactor.
There is one thing worth attention that in this thread[1] Thomas
suggests an interface with a method return JobGraph based on the
fact that REST API and in per job mode actually extracts the JobGraph
from user program and submit it instead of running user program and
submission happens inside the program in session scenario.
Such an interface would be like
interface Program {
JobGraph getJobGraph(args);
}
Anyway, the discussion above could be continued in that thread.
Current Program is a legacy class that quite less useful than it should be.
Best,
tison.
[1]
http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/REST-API-JarRunHandler-More-flexibility-for-launching-jobs-td31026.html#a31168
Stephan Ewen <se...@apache.org> 于2019年8月14日周三 下午7:50写道：
> +1
>
> the "main" method is the overwhelming default. getting rid of "two ways to
> do things" is a good idea.
>
> On Wed, Aug 14, 2019 at 1:42 PM Kostas Kloudas <kklou...@gmail.com> wrote:
>
> > Hi all,
> >
> > As discussed in [1] , the Program interface seems to be outdated and
> > there seems to be
> > no objection to remove it.
> >
> > Given that this interface is PublicEvolving, its removal should pass
> > through a FLIP and
> > this discussion and the associated FLIP are exactly for that purpose.
> >
> > Please let me know what you think and if it is ok to proceed with its
> > removal.
> >
> > Cheers,
> > Kostas
> >
> > link to FLIP-52 :
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=125308637
> >
> > [1]
> >
> https://lists.apache.org/x/thread.html/7ffc9936a384b891dbcf0a481d26c6d13b2125607c200577780d1e18@%3Cdev.flink.apache.org%3E
> >
>
