Re: StringPrep in ICU4JNI?

Mikhail Zabaluev wrote:

>>The 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.
> 
>>We 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