[
https://issues.apache.org/jira/browse/TEZ-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13977261#comment-13977261
]
Thomas Jungblut commented on TEZ-841:
-------------------------------------
Here is my patch. I think most of the changes are worth a discussion, so please
tell me what you think.
Some things I would like to discuss:
*Now useless classes*
LogicalOutput seems not useful anymore now, we could replace it with
AbstractLogicalOutput directly. (Same with LogicalInput)
*Default implementation vs. abstract method definition*
I personally think that a user should be forced to override a mandatory method
that is defining the behaviour (LogicalIOProcessor#run is the best example
here), while other methods like inits/close are default implemented to do
nothing. On the other side, empty methods that must be overriden are extremely
code cluttering.
What do you think? In the MR the Mapper implements everything default with
nothing, or in the map method just returning the identity. Should we stay
consistent?
*Throwing UnsupportedOperationException*
While this is quite widespread in Java SE, I think it is a bad style unless you
are really hitting something unexpected that wasn't implemented. This actually
is a sign of misuse as it transfers the problem to runtime checks (this is
compiler's business imo).
One example I found in the code was throwing with the message: "Not expecting
any events to the broadcast output processor", is this really an exceptional
case? Events can be ignored gracefully without harming the rest of the
application.
I removed this boilerplate from the examples, please tell me your opinion on
that.
*Default Constructors*
I can understand that it makes sense to tell the users not to define their own
parameterized constructors, but adding empty default constructors to all
examples is not useful either. Let's use the compilers feature and use auto
generated default constructors, reflection will tell us if there is no
parameterless constructor in the class (probably a good thing to check on
client side already).
> Changes interfaces to abstract classes
> --------------------------------------
>
> Key: TEZ-841
> URL: https://issues.apache.org/jira/browse/TEZ-841
> Project: Apache Tez
> Issue Type: Task
> Affects Versions: 0.4.0
> Reporter: Bikas Saha
> Labels: newbie
> Attachments: TEZ-841_1.patch
>
>
> Some interfaces like VertexManagerPlugin/EdgeManager/Input/Output/Processor
> are meant to be implemented by users. If they are abstract classes instead of
> interfaces then we may be able to add optional new methods without breaking
> existing impls. Also, some common functionality may be added to the abstract
> classes to make the developers lives easier.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
