commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Bourg (Commented) (JIRA)" <>
Subject [jira] [Commented] (CSV-43) CSVFormat fluent API is rather inefficient
Date Sat, 10 Mar 2012 17:16:58 GMT


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:
>             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
> 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:!default.jspa
For more information on JIRA, see:


View raw message