Strings and object 80/20 rule

[Hylander]

80% of what Strings can do is not used in the program. (This is true
of many objects) Is the best solution to use char[] for lightweight
string programming?
However, it seems that some things about Strings are better. ie: they
are optimized via a "String pool", as real Object's they use the
equals contract (part of that 20% that gets actual use) etc. You would
think that maybe there was a lightweight String object available that
had little more than what is needed for Object's. Are there other
optimizations that go on behind the scenes?

Btw, no need to mention when the best time for optimization
is./premature optimization antipattern etc...


I'm aware that Decorators are a solution to the general problem but
that can result in class overpopulation.

 

[Adam Jenkins]

80% of what Strings can do is not used in the program. (This is true
of many objects) Is the best solution to use char[] for lightweight
string programming?
However, it seems that some things about Strings are better. ie: they
are optimized via a "String pool", as real Object's they use the
equals contract (part of that 20% that gets actual use) etc. You would
think that maybe there was a lightweight String object available that
had little more than what is needed for Object's. Are there other
optimizations that go on behind the scenes?

Btw, no need to mention when the best time for optimization
is./premature optimization antipattern etc...

It doesn't make sense to worry about methods of java.lang.String that
you don't use, since they have no per-instance cost, and don't use any
CPU time if you don't call them. So I assume you're worried about
memory usage. Sun's java.lang.String implementation has 4 non-static
member variables; 3 ints and a char[], plus whatever memory an Object
needs. However, String uses those extra ints to implement the nice
property that a substring can share the same char[] data as the string
it's a part of. I.e:

String str = "foobar";
String substr = str.substring(0, 3);

In this case, substr internally refers to the same char[] as str, but
knows to only use the first 3 elements. So whether you'd actually save
memory by using char[] directly instead of Strings depends on how you'd
be using the strings. If you just need to store many unique strings in
memory and memory usage is critical, then it might make sense store
char[] arrays instead of java.lang.Strings. If you'll be picking apart
the strings into substrings, then the extra ints will probably be more
than made up for by being able to share the char[] data between substrings.