Intrinsic string class.
TODO(jat): consider whether we want to support the following methods;
- deprecated methods dealing with bytes (I assume not since I can't see
much use for them)
- String(byte[] ascii, int hibyte)
- String(byte[] ascii, int hibyte, int offset, int count)
- getBytes(int srcBegin, int srcEnd, byte[] dst, int dstBegin)
- methods which in JS will essentially do nothing or be the same as other
methods
- copyValueOf(char[] data)
- copyValueOf(char[] data, int offset, int count)
- methods added in Java 1.6 (the issue is how will it impact users
building against Java 1.5)
- other methods which are not straightforward in JS
- format(String format, Object... args)
Also, in general, we need to improve our support of non-ASCII characters. The
problem is that correct support requires large tables, and we don't want to
make users who aren't going to use that pay for it. There are two ways to do
that:
- construct the tables in such a way that if the corresponding method is
not called the table will be elided from the output.
- provide a deferred binding target selecting the level of compatibility
required. Those that only need ASCII (or perhaps a different relatively small
subset such as Latin1-5) will not pay for large tables, even if they do call
toLowercase(), for example.
Also, if we ever add multi-locale support, there are a number of other
methods such as toLowercase(Locale) we will want to consider supporting. This
is probably rare, but there will be some apps (such as a translation tool)
which cannot be written without this support.
Another category of incomplete support is that we currently just use the JS
regex support, which is not exactly the same as Java. We should support Java
syntax by mapping it into equivalent JS patterns, or emulating them.
