<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">thanks for review Valerie. I think the
current JDK 9 builds already check for some module correctness.
Hopefully - what I'm proposing will work post modules. My initial
attempt had the java.base module trying to pull in the
jdk.crypto.ec module. That would not be allowed. The current
proposal doesn't seem to place any issue on modules and the
current export rules work ok.<br>
<pre class="moz-signature" cols="72">Regards,
Sean.</pre>
On 05/06/2015 22:04, Valerie Peng wrote:<br>
</div>
<blockquote cite="mid:55720ECA.3090304@oracle.com" type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<br>
This looks pretty good. <br>
However, I suspect this will stop working once the Jake changes
are integrated as module boundaries are enforced?<br>
Valerie<br>
<br>
<br>
On 6/5/2015 3:21 AM, Seán Coffey wrote:
<blockquote cite="mid:55717822.5090806@oracle.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
Looking to resolve a recently reported issue where the
P11ECKeyFactory class has too much dependence on the SunEC
provider. With some reshuffling and creation of a new P11ECUtil
class, I was able to remove the call for lookup of SunEC
Provider. The test picks up the regression when running with the
SunPKCS11-NSS provider.<br>
<br>
bug report : <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://bugs.openjdk.java.net/browse/JDK-8080102">https://bugs.openjdk.java.net/browse/JDK-8080102</a><br>
webrev : <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Ecoffeys/webrev.8080102.jdk9.v2/webrev/">http://cr.openjdk.java.net/~coffeys/webrev.8080102.jdk9.v2/webrev/</a><br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
<pre class="moz-signature" cols="72">--
Regards,
Sean.</pre>
</blockquote>
</blockquote>
<br>
</body>
</html>