[ https://issues.apache.org/jira/browse/MAPREDUCE-6000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Todd Lipcon updated MAPREDUCE-6000: ----------------------------------- Attachment: mapreduce-6000.txt Attached patch removes about 250 lines of code and the tests still pass. Reader changes: - throw NotSupportedException for Reader.readLine() (no use cases) - implement readUTF() using the built-in Java decoding support instead of manual implementation (should be similar performance, not sure why there was explicit decoding done here) Writer changes: - add better javadoc - move constants to top of class (per hadoop style) - assume that 'handler' is always non-null (in practice, it is). Added a precondition check for it. - remove implementation of writeBytes(String) since this is a bizarre artifact of the java DataOutput interface (it truncates any high-order bytes out of the characters). Unlikely to be useful. - remove implementation of writeChars(String) since it's unused, and again, users should probably be using UTF8 methods - implement writeUTF() using Java support for encoding, instead of manual encoding Tests: - use Mockito spy instead of the new 'Counter' and 'Flag' classes. > native-task: Simplify ByteBufferDataReader/Writer > ------------------------------------------------- > > Key: MAPREDUCE-6000 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-6000 > Project: Hadoop Map/Reduce > Issue Type: Sub-task > Components: task > Reporter: Todd Lipcon > Assignee: Todd Lipcon > Priority: Minor > Attachments: mapreduce-6000.txt > > > The ByteBufferDataReader and ByteBufferDataWriter class are more complex than > necessary: > - several methods related to reading/writing strings and char arrays are > implemented but never used by the native task code. Given that the use case > for these classes is limited to serializing binary data to/from the native > code, it seems unlikely people will want to use these methods in any > performance-critical space. So, let's do simpler implementations that are > less likely to be buggy, even if they're slightly less performant. > - methods like readLine() are even less likely to be used. Since it's a > complex implementation, let's just throw UnsupportedOperationException > - in the test case, we can use Mockito to shorten the amount of new code -- This message was sent by Atlassian JIRA (v6.2#6252)