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.
