Post by Mikhail ZabaluevPost by Ram ViswanadhaThe reason there is no StringPrep in ICU4JNI is that ICU4J already has
pure JAVA implementation.
Isn't that considerably slower than the ICU4JNI equivalent, as stated on
the site? I'm particularly interested in normalization performance.
The statement was true when Noramalization was re-implemented in ICU4C
and accessed through ICU4JNI and ICU4J still had the old implementation.
Normalization has be reimplemented in ICU4J since then and the new
implementation makes use of the same tricks and techniques that gave
ICU4C's implementation a performance boost. I have not tested the
performance but am sure that this statement is not accurate.
Post by Mikhail ZabaluevPost by Ram ViswanadhaWe usually implement a JNI wrapper if a
service is not available in JAVA for a particular release.
That said, implementing a JNI wrapper should not be hard. You need to
write wrappers around usprep_open, usprep_close and usprep_prepare.
Thank you.
I noticed one discrepancy: the ?++ version opens a profile given a
pathname while the Java version accepts an arbitrary InputStream. Should
the ICU4JNI API mirror that of ICU4J, or different constructors/methods
are acceptable?
The reason for this discrepancy is that Java runs in a sandbox, i.e.,
you cannot read arbitrary files. The security manager will not allow you
to do so. There are 2 ways to go about this situation.
i) Model after ResourceBundle API and take ClassLoader object which is
then used to load the files.
ii) Let the client manage file access and take the input stream as a
parameter.
We decided to take the path (ii) since it was less cumbersome to
implement and the presumption is that the client has access to its data.
Best Regards,
Ram Viswanadha