<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 12/20/2011 06:43 PM, Adam Young wrote:
<blockquote cite="mid:4EF147D2.7010805@redhat.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
If the only questions are those of performance, than it is a non
issue for now. <br>
<br>
<br>
<br>
On 12/20/2011 09:19 PM, Matthew Harmsen wrote:
<blockquote cite="mid:4EF14219.7030902@redhat.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
On 12/16/11 17:24, Endi Sukma Dewata wrote:
<blockquote cite="mid:4EEBEF4D.5060402@redhat.com" type="cite">On
12/13/2011 4:25 PM, Adam Young wrote: <br>
<blockquote type="cite">On 12/13/2011 02:03 PM, Andrew Wnuk
wrote: <br>
<blockquote type="cite">Hopefully this patch was extremely
well tested since it touches ASN.1 <br>
encoding. <br>
</blockquote>
Do you have a specific set of tests that we should be
running? <br>
</blockquote>
<br>
I just posted patch #5 which contains some unit tests for the
converters. I've also updated and split patch #4 into #4-2a
(renaming the files) and #4-2b (replacing the implementation).
<br>
<br>
Patch #5 should be applied before #4-2a/b to make sure there's
no regression. <br>
<br>
Mozilla JSS library also has some ASN.1 code, should we use
them to implement the converters? <br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://mxr.mozilla.org/mozilla/source/security/jss/org/mozilla/jss/asn1/">http://mxr.mozilla.org/mozilla/source/security/jss/org/mozilla/jss/asn1/</a>
<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Pki-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Pki-devel@redhat.com">Pki-devel@redhat.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pki-devel">https://www.redhat.com/mailman/listinfo/pki-devel</a>
</pre>
</blockquote>
Endi,<br>
<br>
Andrew and I have been looking at these changes, and we have the
following concerns:<br>
<br>
(1) First of all, we looked up the bug where some of the
sun.io.* classes were deprecated (which mentions
java.nio.charset and sun.nio.cs):<br>
<ul>
<li><a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4948149">http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4948149</a><br>
</li>
</ul>
(2) There appears to be considerable concern on performance
degradation when using "Charset":<br>
<ul>
<li><a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://stackoverflow.com/questions/2098137/fast-alternative-to-java-nio-charset-charset-decode-encode">http://stackoverflow.com/questions/2098137/fast-alternative-to-java-nio-charset-charset-decode-encode</a></li>
<li><a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.theserverside.com/discussions/thread.tss?thread_id=61270">http://www.theserverside.com/discussions/thread.tss?thread_id=61270</a></li>
</ul>
</blockquote>
<br>
<br>
The article also states that the issue is being delat with in Java
7. <br>
</blockquote>
<br>
and this is what we need to verify.<br>
<br>
<blockquote cite="mid:4EF147D2.7010805@redhat.com" type="cite"> We
are standardizing on Java 7 for this release, so it should not be
an issue.<br>
<br>
<blockquote cite="mid:4EF14219.7030902@redhat.com" type="cite">
<ul>
</ul>
(3) Additionally, there have been alterations in the CS code in
the past to fix problems encountered with the sun.io.* classes:<br>
<ul>
<li>pki/base/util/src/netscape/security/util/ByteToCharPrintable.java</li>
</ul>
Although we have not gotten to the unit tests, we suspect that
these will be great to have regardless of the direction that is
decided upon. However, due to our concerns regarding
performance, could we have some tests added (unit or a test
tool) which obtain performance results for the existing methods
versus the proposed newer methods?<br>
<br>
If no discernable performance issues are encountered, most of
these changes appear to be acceptable -- the questionable one
being the replacing of the code that addressed issue (3) above.<br>
<br>
If there is an unacceptable degradation in performance, perhaps
we could utilize some customized Java classes to perform these
functions. As an alternative approach, as Endi alluded to, there
is some ASN.1 code in Mozilla JSS, and speaking with Bob Relyea,
we have been postulating on how much work would be involved to
write JNI bindings via JSS to the ASN.1 encoders/decoders
contained in NSS instead of moving this code to use java.nio.*
classes. Theoretically, we may limit our performance issues in
exchange for the extra work involved in making the effort to
standardize on the NSS ASN.1 engine (although I don't know if
this will resolve issues such as (3) noted above).<br>
<br>
-- Matt<br>
</blockquote>
<br>
I am not worried about performance at this point,</blockquote>
<br>
Performance is not easily achievable and ignoring it is not the best
practice for developing servers.<br>
<br>
<blockquote cite="mid:4EF147D2.7010805@redhat.com" type="cite"> it
is way too premature. I am only concerned with correctness. The
deprecated classes are going away, and we need an alternative to
them. We will have a deliberate performance and tuning iteration
once the code base has been restructured. If we find at that
stage that there are still performance issues, we can look into
writing a custom tuned solution, but based on overall system
performance. <br>
<br>
<br>
</blockquote>
<br>
</body>
</html>