[
https://issues.apache.org/jira/browse/CSV-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226898#comment-13226898
]
Emmanuel Bourg commented on CSV-43:
-----------------------------------
It's less efficient than a direct instantiation, but that doesn't make the API
inefficient. The critical part is the parsing, concerns about the efficiency
should be focused on this part of the code.
I don't want to make the API more complex with an additional CSVFormatBuilder
class or extra steps to define a format. This is quite similar to the design of
the Guava API for example, such as the Joiner/Splitter classes.
> CSVFormat fluent API is rather inefficient
> ------------------------------------------
>
> Key: CSV-43
> URL: https://issues.apache.org/jira/browse/CSV-43
> Project: Commons CSV
> Issue Type: Improvement
> Reporter: Sebb
>
> The implementation of the CSVFormat fluent API is rather inefficient, as each
> method invocation clones the original class instance.
> Now that the fields are volatile, it would be possible to do away with the
> clone() calls entirely.
> This would mean that the format could be updated later.
> If such usage is not desirable, then perhaps consider adding some kind of
> "freeze" method to prevent further changes.
> Or perhaps the parse() and format() methods could perform the freeze (e.g.
> set a flag to disable further updates).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
