Re: Security Performance issue

Hi Regis, You mean init these providers is slow, right? But actually we should not init unnecessary providers. I added some info in our code as following and you can see init these provider takes most of the time: ... long start = System.currentTimeMillis(); p = (Provider) Class.forName(providerC

Re: Security Performance issue

On 2010-07-22 13:07, Ray Chen wrote: Hi All, I found that our security implementation is much slower than RI's when get an algorithm instance. I have done some investigation and found that most time are consumed on loading and initialising providers. Following is the test cases and results to sho

Security Performance issue

Hi All, I found that our security implementation is much slower than RI's when get an algorithm instance. I have done some investigation and found that most time are consumed on loading and initialising providers. Following is the test cases and results to show this problem.

Re: [classlib][nio_cahr] Issue about CharsetEncdoer.flush() does not follow the spec and RI5 also doesn't follow the spec

I have summarized our harmony unit test results between RI5 and RI6, Test caseTest expected (Follow spec5?)RI5(Follow spec5?) RI6(Follow spec6?) CharsetEncoder sequence [1] No exception(x) Throws illegaStateException

Re: [classlib][x-net] Creating a provider based on OpenSSL

Hi Chris, On 19/07/2010 21:08, chris.g...@k-embedded-java.com wrote: Hi Oliver, I'm currently investigating the possibility of implementing a JSSE provider wrapping OpenSSL. This would be a great idea, but don't underestimate he task. IIRC there is at least one abandoned project on SourceFor

Re: [classlib][nio_cahr] Issue about CharsetEncdoer.flush() does not follow the spec and RI5 also doesn't follow the spec

2010/7/21 Tim Ellison > On 21/Jul/2010 06:24, Deven You wrote: > > See https://issues.apache.org/jira/browse/HARMONY-6594 > > > > In Java5 Spec, the flush() method should always be invoked after reset() > or the > > three-argument encode ../../

Re: Fwd: [jira] Commented: (HARMONY-6590) [classlib][luni]A issue about CharsetEncoder.flush() in the OutputStreamWriter.close()

2010/7/21 Tim Ellison > On 20/Jul/2010 04:16, Deven You wrote: > > Hi Tim, > > I have write a test case which simulate the behavior of > OutputStreamWriter > > and fail on RI but pass on harmony trunk. > > yes, and the discussion of how CharsetEncoder behaves is the first thing > -- but then we s

Re: Fwd: [jira] Commented: (HARMONY-6590) [classlib][luni]A issue about CharsetEncoder.flush() in the OutputStreamWriter.close()

On 20/Jul/2010 04:16, Deven You wrote: > Hi Tim, > I have write a test case which simulate the behavior of OutputStreamWriter > and fail on RI but pass on harmony trunk. yes, and the discussion of how CharsetEncoder behaves is the first thing -- but then we should look at how the OutputStreamWrite

Re: [classlib][nio_cahr] Issue about CharsetEncdoer.flush() does not follow the spec and RI5 also doesn't follow the spec

On 21/Jul/2010 06:24, Deven You wrote: > See https://issues.apache.org/jira/browse/HARMONY-6594 > > In Java5 Spec, the flush() method should always be invoked after reset() or > the > three-argument > encode

Re: [classlib][nio_cahr] Issue about CharsetEncdoer.flush() does not follow the spec and RI5 also doesn't follow the spec

In message , Deven You writes: > > See https://issues.apache.org/jira/browse/HARMONY-6594 > > > [SNIP] > > So now I am confused if we should modify our harmony trunk > CharsetEncoder to comply with the java5 spec or in other hand modify > it to