Re: Character Test

[Artur Biesiadowski <abies@pg.gda.pl>]

"Aaron M. Renn" wrote:
> 
> I convertered Artur's Character test to the Mauve framework (a simple task)
> and checked into the gnu/testlet/java/lang/Character directory as
> unicode.java.  A word of warning: This test is very thorough and takes a
> very long time to run.  It is possible we might not want to run it at all by
> default.  Running debug it printed over 150MB of output before I killed the
> job to avoid filling up my filesystem.

Attached is small diff to SimpleTestHarness which cause the test to run
100x faster (at least).
Second file is update unicode.java - you have hacked a bit too much of
code, so most errors what not reported in right manner.

I think that it works good now as far as performance and verbosity is
concerned. Now we can begin to chase JLS incompatibilities.

Single most important one for JDK is if SUPERSCRIPT/SUBSCRIPT numbers
should be treated as digits. 

JLS says it should not be, because they do not contain word DIGIT in
them. But they do have digit value in unicode spec. JLS is known to be
buggy - there is even a site somewhere which tracks all the errors in
JLS. But on the other hand it is only source of 'truth'. So, we can
change a rule to ignore unicode digit value if entry has not DIGIT in
its name.

Next problem for jdk is that it reports roman numerals (category Nl) as
java and unicode indetifier starts. It is clearly stated in api that
char needs to be
a letter     
a currency symbol (such as "$")
a connecting punctuation character (such as "_")

And there is a link to isLetter method. JDK isLetter returns false for
roman numerals, but at the same time jdk allows it to be start of
identifiers. It seems like different people made different methods.

Third problem is that TIBETAN DIGIT HALF * are not reported as digits. I
don't know what this letters are, but JLS rules set them as digits.

First problem is my fault (I used unicode spec instead of JLS), second
and third are clearly JDK faults (if something looks like V then it is V
isn't it ?). 

Rest of my code works with JDK (as long as deprecated methods are not
used). So if anybody disagree with the test, please include specific
cases, so we can get them one by one.

BTW, deprecated methods are quite funny - they are implemented randomly
with another methods which they should be, not with JLS or even API
spec. They could have changed API to say that it is not longer JLS
method, but they continue to include 1.0 api, with method being replaced
by another one. I wonder how they could pass their own JCK ? Maybe
deprecated methods are not needed to pass JCK ?

Artur
--- OldHarness.java	Sat Jan  9 15:14:49 1999
+++ SimpleTestHarness.java	Sat Jan  9 15:32:31 1999
@@ -39,16 +39,21 @@
 
   public void check (boolean result)
     {
+      if (! result)
+	{
       String d = (description
 		  + ((last_check == null) ? "" : (": " + last_check))
 		  + " (number " + (count + 1) + ")");
-      if (! result)
-	{
+
 	  System.out.println("FAIL: " + d);
 	  ++failures;
 	}
       else if (verbose)
 	{
+      String d = (description
+		  + ((last_check == null) ? "" : (": " + last_check))
+		  + " (number " + (count + 1) + ")");
+
 	  System.out.println("PASS: " + d);
 	}
       ++count;