In the recent jdk8u-dev edits of this file for 8157561, we introduced a
debug field based on this key :
Debug.getInstance("jca", "Cipher");
Can we continue to use 'jca' to be consistent for people upgrading ?
for the testcase, I guess you can edit
test/javax/crypto/CryptoPermission/TestUnlimited.java but you'll have to
launch with a customized java.security file which doesn't have
crypto.policy set. (Security.setProperty doesn't allow null values)
Regards,
Sean.
On 16/11/16 00:40, Bradford Wetmore wrote:
Never noticed that before! We have NOT been consistent in whether we
use:
System.out.println()
or
debug.println()
I knew SeanC wants to rework the JCA/JCE/Security debugging output in
another project, so I will remove the prefix for now. Thanks for
catching it.
I will also add a simple regression Test before I push. In hindsight,
it's not as trivial a change as I initially thought. If you want to
review it, I can wait until you are back tomorrow.
Brad
On 11/15/2016 4:12 PM, Wang Weijun wrote:
You create a debug field with a prefix string and then check both
debug != null and Debug.isOn("policy") and then use
System.out.println to print the message. Something must be useless.
--Max
On Nov 16, 2016, at 3:31 AM, Bradford Wetmore
<bradford.wetm...@oracle.com> wrote:
Simple codereview:
http://cr.openjdk.java.net/~wetmore/8169335/webrev.00
The "crypto.policy" Security property is normally defined/configured
in the java.security file at build time. (e.g. "limited" or
"unlimited") Rather than currently failing catastrophically if this
value doesn't exist, there should be a sensible default if it is
undeclared for whatever reason. We will use a sane fallback value of
"limited".
If the distribution has also removed the "limited" policy directory
then the VM will still fail to initialize, but we have at least made
an effort to recover.
Thanks,
Brad
