| Age | Commit message (Collapse) | Author |
|---|
|
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6242664
Java 1.5 has a bug where detecting codepoint offsets in strings that are
created by String.substring() gives wrong results. The new implementation
uses a different method, avoinding the issue.
The following code will crash without the fix:
final String s = "abcdefg";
final String ss = s.substring(3, 6);
final int[] cps = OtpErlangString.stringToCodePoints(ss);
|
|
The two noncharacter code points 16#FFFE and 16#FFFF were not
allowed to be encoded or decoded using the unicode module or
bit syntax. That causes an inconsistency, since the noncharacters
16#FDD0 to 16#FDEF could be encoded/decoded.
There is two ways to fix that inconsistency.
We have chosen to allow 16#FFFE and 16#FFFF to be encoded and
decoded, because the noncharacters could be useful internally
within an application and it will make encoding and decoding
slightly faster.
Reported-by: Alisdair Sullivan
|
|
There once was a reason to have a "Makefile.otp" makefile, but
it doesn't apply any longer. Rename it to "Makefile" so that
the standard otp_subdir.mk file can be used for recursion into
sub directories.
|
|
|
|
|
|
|
|
The OtpMbox class was missing the hash() method while overriding
equals(). This can cause problems when using jinterface in a
larger Java application.
|
|
|
|
|
