You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@opennlp.apache.org by "Joern Kottmann (Resolved) (JIRA)" <ji...@apache.org> on 2011/11/08 22:57:51 UTC

[jira] [Resolved] (OPENNLP-364) Use StringBuilder instead of StringBuffer

     [ https://issues.apache.org/jira/browse/OPENNLP-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joern Kottmann resolved OPENNLP-364.
------------------------------------

       Resolution: Fixed
    Fix Version/s: tools-1.5.3-incubating
         Assignee: Joern Kottmann

Patch applied. Thanks for the patch.
                
> Use StringBuilder instead of StringBuffer
> -----------------------------------------
>
>                 Key: OPENNLP-364
>                 URL: https://issues.apache.org/jira/browse/OPENNLP-364
>             Project: OpenNLP
>          Issue Type: Improvement
>    Affects Versions: tools-1.5.3-incubating, maxent-3.0.3-incubating
>            Reporter: Aliaksandr Autayeu
>            Assignee: Joern Kottmann
>            Priority: Minor
>             Fix For: tools-1.5.3-incubating
>
>         Attachments: 0004-stringbuffer-to-stringbuilder.patch
>
>
> There are *local* StringBuffer instances used in several places. StringBuilder is preferred:
> Where possible, it is recommended that this class be used in preference to StringBuffer as it will be faster under most implementations.
> More support:
> http://en.wikipedia.org/wiki/String_Buffer:
> The StringBuilder class, introduced in J2SE 5.0, differs from StringBuffer in that it is unsynchronized. When only a single thread at a time will access the object, using a StringBuilder processes more efficiently than using a StringBuffer.
> http://stackoverflow.com/questions/355089/stringbuilder-and-stringbuffer-in-java:
> A test run gives the numbers of 2241 ms for StringBuffer vs 753 ms for StringBuilder.
> http://littletutorials.com/2008/07/16/stringbuffer-vs-stringbuilder-performance-comparison/:
> So StringBuilder is faster by a good percentage (34% on my machine in this case) but remember that it is not thread safe.
> Thread-safety is not threatened, as all proposed changes consider local variables.

--
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