I think the actual implementation is another argument against allowing
private methods. I'm not super familiar with it but we actually generate
code for calling the annotated methods and that code has to adhere to Java
restrictions and cannot call private methods. I think calling private
methods is
Requiring public is also a form of documentation for implementers and
maintainers that this method is meant to be called by someone else.
All our arguments have been around best practices.
I think the only technical argument is that if a runner today chooses to
execute with a security manager, it
We stumbled across this issue when we were doing some Scala-Java interop
and had an anonymous class that was supposed to have an element processing
method. The Scala compiler had decided to make that method private, and so
it was not visible to Beam. While extracting this class to an upper level
(i
We thought about it when this was added. We decided against it because
these are overrides-in-spirit. Letting them be private would be misleading
because they are called from outside the class and should be thought of in
that way.
Also, this seems similar to others in the Java ecosystem: JUnit tes
Hi Stas
Just curious: what would be the use case of private method ? Being able to
reuse the DoFn class in different contexts ?
Regards
JB
On Jan 17, 2017, 07:33, at 07:33, Stas Levin wrote:
>Hi,
>
>At the moment only public methods are eligible to be decorated with
>@ProcessElement (DoFnSig
Hi,
At the moment only public methods are eligible to be decorated with
@ProcessElement (DoFnSignatures#findAnnotatedMethod).
Seems that from a technical point of view, it would be quite possible to
consider private methods as well. In fact, it's one of the benefits of
moving towards an annotatio
