|
J avolution v5.2 (J2SE 1.5+) | ||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |
See:
Description
Class Summary | |
---|---|
CharArray | This class represents a character sequence backed up by a
char array. |
CharSet | This class represents a set of characters. |
Text | This class represents an immutable character sequence with
fast concatenation , insertion and
deletion capabilities (O[Log(n)]) instead of
O[n] for StringBuffer/StringBuilder). |
TextBuilder | This class represents an Appendable text whose capacity expands
gently without incurring expensive resize/copy operations ever. |
TextFormat<T> | This class represents the base format for text parsing and formatting;
it supports CharSequence and Appendable
interfaces for greater flexibility. |
TextFormat.Cursor | This class represents a parsing cursor over a character sequence (or subsequence). |
TypeFormat | This class provides utility methods to parse CharSequence
into primitive types and to format primitive types into any
Appendable . |
Provides classes and interfaces to handle text.
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
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).
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
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 Text.concat(Text)
is more efficient (it avoid character copies, but creates small nodes objects
instead).
"/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:
The prefix (directoryName)is shared between
Text directoryName = Text.valueOf("/proj/lodecase/src/com/lodecase/util/");
Text fooFileName = directoryName.plus("foo.java");
Text barFileName = directoryName.plus("bar.java");
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.
|
J avolution v5.2 (J2SE 1.5+) | ||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |