db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject i18n/JapanCodeConversion test intermittent failures & changes
Date Wed, 23 Nov 2005 20:37:50 GMT

With the i18n/JapanCodeConversion test I see failures due to the
execution of native2ascii failing. This executing an external process
from ij also causes problems running the test under a security manager.

The test exports data with Japanese unicode characters from a table into
two files, one using EUC_JP encoding and the other SJIS encoding.

The content of these files are "checked for correctness" by dumping the
output of the JDK utility native2ascii to System.out and hence to the
master file.

I've added additional tests that better test the correctness of the
exported data by:

 - importing the exported data using EUC_JP and SJIS into separate
tables and comparing the data to the original table's data. This
actually checks the data is not modified by the export/import process
with the two encodings.

 - importing the data using EUC_JP and SJIS, but from the wrong files
(ie. import from the SJIS file using EUC_JP encoding) and comparing with
the original data. This ensures that a single format is not being used.

This was checked in with svn revision 348553.

Do these changes seem sufficient to remove the nasty use of the
executable native2ascii for this test?

Dan.


Mime
View raw message