[
https://issues.apache.org/jira/browse/TEZ-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14065281#comment-14065281
]
Siddharth Seth commented on TEZ-857:
------------------------------------
bq. The type of the object being casted is already LogicalInput in this case.
The rest of the patch for this file already has unchecked casts.
Will look, the specific condition was already being checked before the patch.
Will take a look to see what can be changed, and maybe remove the checks.
bq. For the naming, LogicalInputInternal
That's an option. The question is whether this interface is private. I had
marked it so in an earlier instance of the patch - but I don't think it's
private. Internal gives that impression. Any other name suggestions ?
[~hitesh] - any thoughts on this, specifically naming.
> Split Input/Output interfaces into Framework / User components
> --------------------------------------------------------------
>
> Key: TEZ-857
> URL: https://issues.apache.org/jira/browse/TEZ-857
> Project: Apache Tez
> Issue Type: Sub-task
> Reporter: Siddharth Seth
> Assignee: Siddharth Seth
> Attachments: TEZ-857.1.txt
>
>
> Inputs / Outputs have several methods which are not meant for user
> interaction - initialize(Tez*Context), close(), TEZ-844 is adding another.
> There has been confusion in the past on whether the framework will call
> close, or whether it's the user's responsibility.
> The framework specific methods and the Processor usable methods can be split
> into a separate interface. Input/Output writers would need to implement both,
> Processor writers would only see the Input part of the interface.
> TEZ-782, TEZ-827 introduced some requirements on Inputs which are not
> enforced at compile time (must request mem). These could potentially be added
> to the framework part of the interface to force Inputs/Outputs to be aware of
> them at compile time, while not polluting the Processor interface.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
