Is parsing/formatting of floating-points numbers (e.g. double)
equivalent to standard String/Double methods?
With Javolution 4.1, double formatting/parsing is lossless
and functionally the same as with the standard library. Parsing a character
sequence will always result in the same number whether it is performed with
{@link javolution.text.TypeFormat TypeFormat} or using Double.parseDouble(String)).
When formatting a double number, the number of digits output
is adjustable. The default (if the number of digits is unspecified) is 17
or 16 when the the 16 digits representation can be parsed back to
the same double (mimic the standard library formatting).
Javolution parsing/formatting do not generate garbage and has no adverse
effect on GC. Better, it does not force the user to create intermediate String
objects, any CharSequence/Appendable can be used! Serial parsing is also supported
(cursor parameter).
I'm accumulating a large string, and all I want to do is
append to the end of the current string, which is the better class to use,
Text or TextBuilder? Bearing in mind that speed is important, but I also want
to conserve memory.
It all depends of the size of the text to append (the actual size of the
document being appended has almost no impact in both cases).
If you append one character at a time or a small text then
{@link javolution.text.TextBuilder#append(Object) TextBuilder.append(Object)}
is faster (the cost of copying the characters to the internal buffer is
then negligeable and TextBuilder never resizes its internal arrays).
If you append larger character sequences (the threshold might be around 20
characters) then {@link javolution.text.Text#concat(Text) Text.concat(Text)}
is more efficient (it avoid character copies, but creates small nodes objects
instead).
In our project's use of strings, there are a lot of
instances of directory path names, such as
"/proj/lodecase/src/com/lodecase/util/foo.java", and
"/proj/lodecase/src/com/lodecase/util/bar.java".
Can the 'Text' class save us memory when strings
have common prefixes?
It depends how you build your text. For example in following code:[code]
Text directoryName = Text.valueOf("/proj/lodecase/src/com/lodecase/util/");
Text fooFileName = directoryName.plus("foo.java");
Text barFileName = directoryName.plus("bar.java");[/code]
The prefix (directoryName)is shared between fooFileName and barFileName.
Text is a binary tree of blocks of characters. In the example,
above, fooFileName is a node with directoryName for
head and "foo.java" for tail. The tree is maintained balanced automatically
through tree rotations.
This class represents an immutable character sequence with
fast
Text.concat concatenation ,
Text.insert insertion and
Text.delete deletion capabilities (O[Log(n)]) instead of
O[n] for StringBuffer/StringBuilder).
This class represents the base format for text parsing and formatting;
it supports
CharSequence and
javolution.text.Appendable
interfaces for greater flexibility.
It is possible to retrieve the format for any class for which the
format has been registered (typically during class initialization).
For example:[code]
public class Complex extends RealtimeObject {
private static final TextFormat CARTESIAN = ...;
static { // Sets default format to cartesian, users may change it later (e.g.
