JSR75 and zip-file problems

Started by heikok, 11. October 2009, 18:00:33

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

heikok

Hi,

I just upgraded my dictionary from 3.3 beta to 3.4 and started to play around with the file-connection system:

a) Some mobiles (i.e. Nokia) don't allow jar-files to be larger than 500kB. They don't allow them to appear on the device, so I cannot use them as file-input. Having a zip files > 500kB is no problem. The FileConnection api should test for files with .zip ending, too, and handle them the same as .jar files. (Maybe it should just test, if the file is a directory, then use JSR75InputStream, and for everything else just use the ZipInputStream? But I have never worked with JSR75 before, so I don't know if a directory test exists.)

b) The zip-input-stream seems to have a bug. My dictionary is > 3MB uncompressed. When using a .jar file-connection with a uncompressed jar file (jar -cf0), it works well. When using a compressed .jar file (jar -cf), the file is only 1MB, but Suns WTK2.5.2 throws a ArrayIndexOutOfBounds exception (without further information). So I guess it's a problem in the decompression-code.

The dictionary (still with the 3.3beta code) can be downloaded at: http://www.heinzelnisse.info/Downloads/get_it/HeinzelnisseForMIDs/

Best regards,

Heiko

Gert

Heiko,

thank you for testing the 'loadable dictionaries' !

a) Does that mean that you cannot simply copy a Jar file e.g. on some Nokias ? I mean, not installing the Jar file, just copying the Jar file on the device. This does not work ? Strange. What device does have this behaviour ?
But if you rename the file to a .zip then it works, right ?

Yes it is possible to distinguish between files and dictionaries.

About the .zip extension we probably should test whether it is a .zip file that was downloaded from our download page, where the .jar file is included; in that case we would first have to use a nested zip decode, the first time for the .zip and the second time for the .jar within the .zip.

b) Some time ago I did make a test with CEDICT, which is rather large, and it worked to run it as a loadable dictionary. Did you test with the compression that is done from JarCreator ? Well, ok, I will look at your dictionary and check if I can reproduce the problem.

Best regards,
Gert

Gert

I made some investigation:

a)
On the Nokia S40 emulator I cannot 'see' the Jar files that are stored on the internal file system. Very strange. Does anybody know the reason for this behaviour ? And are there any other devices affected also ?
I created a DfM version that checks for a directory versus a normal file - as you suggest; for normal files a zip encoded file is assumed. Then it works after renaming the .jar file, see the attached screenshot.

b)
I had been able to reproduce the exception by restarting the application without terminating the emulator: possibly this is due to the emulator problem with handling data that is stored in the DictionaryForMIDs RecordStore. Well, maybe not, I have to check this further.
Until now I did not note a problem with the decompression.

Thanks for your report !
Gert

heikok

Gert,

a)
it is not possible to have a .jar file above a certain size on some (all?) Nokia S40 devices. Copying as a .zip file to the device works, but when trying to rename it on the device to a .jar file fails.

b)
I haven't used the JarCreator at all. And I will test it on a real device instead of the emulator.

Heiko

Gert