FYI, candidate list of classes to be updated to sealed in JDK-8283414: Update java.base to use sealed classes (umbrella)
Hello, With a number of efforts to update various class hierarchies in the JDK to sealed classes, I wrote an annotation processor to find candidates to be changed to sealed. The candidates for this analysis are non-final public classes with at least one package access constructor and no public constructors. That is, the candidate class cannot be generally subclassable. Several dozen candidates were identified and listed in JDK-8283414, including two cases where changing the classes in question to sealed was already out for review (JDK-8282536 and JDK-8283237). I've created subtasks for a number of other cases in core-libs; the cases in security libs could also be reviewed. -Joe
Re: FYI: new javadoc tag to document system properties
Hello,
For future CSR requests involving system properties, please document the
properties using these javadoc facilities.
Thanks,
-Joe
On 11/14/2018 2:27 PM, Jonathan Gibbons wrote:
This is an FYI to announce some initial, long-overdue support in
javadoc for documenting system properties (JDK-5076751).
Currently, system properties are just documented using ad-hoc
narrative text, which is fine if you know where to look for any given
property.
JDK 12 introduces a new inline javadoc tag, {@systemProperty
/property-name/} which can be used to "declare" the name of a system
property. You can use this tag as a drop-in replacement for the
plain-text property name; it will have no overt effect on the
narrative text, but it will cause the property name to be put into the
search index and the A-Z index. Thus, property names will become
searchable, to allow users to easily find the definition of any such
system property.
Adding support into javadoc is only part of the story. Now that the
support is in javadoc, we want to update the API documentation, so
that the documentation is updated for all Java SE and JDK system
properties.
Where should the tag be used? The tag should be used in the text of
the defining instance of the property. This is where the
characteristics of the system property are described, which may
include information like: "what is the property for", "how and when is
it set", "can it be modified", and so on. For example, it could be
used in the docs for System.getProperties [1] or Networking Properties
[2] In general, it should -not- be used in situations that merely
refer to the system property by name. For example, the docs for
Path.toAbsolutePath [3] make a reference to the system property
user.dir, but that is not a definition of the property.
Going forward, in future releases, we expect to explore some
enhancements to this feature. Here are some of the ideas that have
been suggested:
* Create a "summary page" that lists all the system properties. This
would be somewhat similar to the current top-level "Constant Values"
page.
* Add information regarding the "scope" of the definition: is it
defined by the Java SE specification, or JDK, or JavaFX, etc. This
information could be used to organize the content on the summary page.
* Update @see and {@link} to be able to refer to system properties.
* Allow a short description to be included in the {@systemProperty}
tag. This text could be included in the search index, the A-Z index,
and the summary page.
-- Jon
[1]:
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/System.html#getProperties()
[2]:
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/doc-files/net-properties.html
[3]:
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/file/Path.html#toAbsolutePath()
Re: JDK 12 RFR of JDK-8209024: Use SuppressWarnings -- now RFR for 8209304: Deprecate serialVersionUID fields in interfaces
Hi Sean, On 8/15/2018 1:32 PM, Sean Mullan wrote: On 8/9/18 2:36 PM, joe darcy wrote: Security libs team, for src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java I added a separate @Deprecated annotation for the serialVersionUID field even though the interface itself is already deprecated. That interface's javadoc states: 41 * @deprecated Sun JDK internal use only --- WILL BE REMOVED in a future 42 * release. If you like, as part of this changeset I can upgrade (downgrade?) the @Deprecated annotation for this class to forRemoval=true. Let's just leave it as is for now (don't add forRemoval=true). We don't have any upcoming plans to remove or replace this class. Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8209317 and I'll proceed in getting this fix into JDK 12. Thanks, -Joe
Re: RFR: 8179370: Replace use of , and tags in java.base
Hi Jon,
I'd prefer if the "foo" were replaced with "{@code tt}" rather
than "foo"- none of the tricky cases which preclude use of
{@code } use seem to be present here - but will approve the changeset in
its current form too.
Cheers,
-Joe
On 4/26/2017 5:50 PM, Jonathan Gibbons wrote:
Please review these mostly simple changes to replace HTML tags which
are not valid in HTML 5 in public doc comments in java.base.
As with the previous changes, the changes were done mechanically,
using the following sed script:
s|||g
s|||g
s|<\\/tt>|<\\/code>|g
s|\(]*\)>\([^<]*\)|\1
style="text-align:center">\2|
s|style="margin:0 auto" |
s|||
s|||
The unusual form of the 3rd line was to cover the occurrence in a
makefile.
The 4th line is specific for DataInput.java, and replaces
within a with a style on the element itself.
The 5th and 6th lines are specific to URLConnection. The use of the
table itself and the ASCII art that follows it are questionable, but
the intent here is just to update the HTML and not to rework the
visual appearance of the generated documentation.
The changes cover files in the following packages:
java.base java/io
java.base java/net
java.base java/util
java.base javax/net/ssl
JBS: https://bugs.openjdk.java.net/browse/JDK-8179370
Webrev: http://cr.openjdk.java.net/~jjg/8179370/webrev/
-- Jon
Re: JDK 9 RFR of JDK-8151763; Use more informative format for problem list
Hi Sergey, The thinking is the reformatted file, with the bug on the same line as the test, will allow in the future better reporting and analysis of problem list entries with information from the bug database. Thanks for the review; HTH, -Joe On 3/30/2016 5:02 PM, Sergey Bylokhov wrote: The fix looks fine to me. can you please clarify what "enabling better reporting" from the bug description means? Where this information will be reported? On 31.03.16 2:48, Joseph D. Darcy wrote: Hi Mandy, Hopefully the third time will be the charm for this changeset after your correction to the commented-out test: http://cr.openjdk.java.net/~darcy/8151763.2 I aligned the bug number in column 64 unless the test name took more characters. (This isn't as evident in the webrev since the tab expansion is different than in a text editor.) Thanks, -Joe On 3/29/2016 12:31 PM, Mandy Chung wrote: On Mar 29, 2016, at 12:15 PM, joe darcy wrote: Hi Mandy, On 3/28/2016 8:48 PM, Mandy Chung wrote: On Mar 28, 2016, at 5:03 PM, Joseph D. Darcy wrote: Hello, New iteration of the webrev updated after the Jigsaw integration and incorporating the earlier feedback. http://cr.openjdk.java.net/~darcy/8151763.1 # tools/jimage/JImageTest.java linux-i586,windows-i586 Is this test accidentally removed? Other than this, looks okay. The "#" lines are comments so I was removing a commented out line. (I assumed, but did not verify, the line for this test was a leftover artifact of the recent Jigsaw merge.) I missed “#” since this test should be excluded (some error might have been creeped in before the integration) This test needs to be added back in the problem list. I’ll create a changeset. Nit: it’d be good to have most of bug ids aligned in the same column start. Here are a few ones: 210 sun/security/krb5/auto/Unreachable.java 7164518 macosx-all no PortUnreachableException on Mac 212 java/security/KeyPairGenerator/SolarisShortDSA.java 7041639 solaris-all Solaris DSA keypair generation bug 213 sun/security/tools/keytool/standard.sh 7041639 solaris-all Solaris DSA keypair generation bug 346 java/util/Arrays/ParallelPrefix.java 8080165,8085982 generic-all 348 java/util/BitSet/BitSetStreamTest.java 8079538 generic-all 360 sun/tools/jmap/heapconfig/JMapHeapConfigTest.java 8072131,8132452 generic-all 370 sun/tools/jinfo/JInfoSanityTest.java 8059035 generic-all I was trying to avoid introducing lots of spacing changes in an attempt to make the patch easier to review, but I can look over these cases again. That’d be good. Thanks Mandy
Re: JDK 9 RFR of JDK-8151763; Use more informative format for problem list
Hi Mandy, Hopefully the third time will be the charm for this changeset after your correction to the commented-out test: http://cr.openjdk.java.net/~darcy/8151763.2 I aligned the bug number in column 64 unless the test name took more characters. (This isn't as evident in the webrev since the tab expansion is different than in a text editor.) Thanks, -Joe On 3/29/2016 12:31 PM, Mandy Chung wrote: On Mar 29, 2016, at 12:15 PM, joe darcy wrote: Hi Mandy, On 3/28/2016 8:48 PM, Mandy Chung wrote: On Mar 28, 2016, at 5:03 PM, Joseph D. Darcy wrote: Hello, New iteration of the webrev updated after the Jigsaw integration and incorporating the earlier feedback. http://cr.openjdk.java.net/~darcy/8151763.1 # tools/jimage/JImageTest.java linux-i586,windows-i586 Is this test accidentally removed? Other than this, looks okay. The "#" lines are comments so I was removing a commented out line. (I assumed, but did not verify, the line for this test was a leftover artifact of the recent Jigsaw merge.) I missed “#” since this test should be excluded (some error might have been creeped in before the integration) This test needs to be added back in the problem list. I’ll create a changeset. Nit: it’d be good to have most of bug ids aligned in the same column start. Here are a few ones: 210 sun/security/krb5/auto/Unreachable.java 7164518 macosx-all no PortUnreachableException on Mac 212 java/security/KeyPairGenerator/SolarisShortDSA.java 7041639 solaris-all Solaris DSA keypair generation bug 213 sun/security/tools/keytool/standard.sh 7041639 solaris-all Solaris DSA keypair generation bug 346 java/util/Arrays/ParallelPrefix.java 8080165,8085982 generic-all 348 java/util/BitSet/BitSetStreamTest.java 8079538 generic-all 360 sun/tools/jmap/heapconfig/JMapHeapConfigTest.java 8072131,8132452 generic-all 370 sun/tools/jinfo/JInfoSanityTest.java 8059035 generic-all I was trying to avoid introducing lots of spacing changes in an attempt to make the patch easier to review, but I can look over these cases again. That’d be good. Thanks Mandy
Re: JDK 9 RFR of JDK-8151763; Use more informative format for problem list
Hello, New iteration of the webrev updated after the Jigsaw integration and incorporating the earlier feedback. http://cr.openjdk.java.net/~darcy/8151763.1 Thanks, -Joe On 3/16/2016 4:52 PM, Joseph D. Darcy wrote: Hi Jon, Noted; I'll make that improvement in the next round. Thanks for pointing this out, -Joe On 3/16/2016 4:50 PM, Jonathan Gibbons wrote: On 03/11/2016 07:28 PM, joe darcy wrote: Hello, As Jon Gibbons has noted off-list, the problem list entries can directly include the bug number associated with the test in question, enabling better reporting. This format should be used rather than the current convention of putting the bug number in a comment. Please review the webrev to adopt the revised format for the problem list: http://cr.openjdk.java.net/~darcy/8151763.0/ I've verified jtreg produces the same test list with the old and new versions of the problem list. Thanks, -Joe Joe, You can use a comma-separated list when multiple bugs are involved. The only restriction is, no embedded whitespace within the list 342 # Also 8080165 343 java/util/Arrays/ParallelPrefix.java 8085982 generic-all can be 343 java/util/Arrays/ParallelPrefix.java 8085982,8080165 generic-all -- Jon
Re: JDK 9 RFR of JDK-8151763; Use more informative format for problem list
Hi Jon, Noted; I'll make that improvement in the next round. Thanks for pointing this out, -Joe On 3/16/2016 4:50 PM, Jonathan Gibbons wrote: On 03/11/2016 07:28 PM, joe darcy wrote: Hello, As Jon Gibbons has noted off-list, the problem list entries can directly include the bug number associated with the test in question, enabling better reporting. This format should be used rather than the current convention of putting the bug number in a comment. Please review the webrev to adopt the revised format for the problem list: http://cr.openjdk.java.net/~darcy/8151763.0/ I've verified jtreg produces the same test list with the old and new versions of the problem list. Thanks, -Joe Joe, You can use a comma-separated list when multiple bugs are involved. The only restriction is, no embedded whitespace within the list 342 # Also 8080165 343 java/util/Arrays/ParallelPrefix.java 8085982 generic-all can be 343 java/util/Arrays/ParallelPrefix.java 8085982,8080165 generic-all -- Jon
Re: JDK 9 RFR of JDK-8151763; Use more informative format for problem list
Just a follow-up, to avoid causing additional merge headaches, I'll revise the patch to make this change once the next round of Jigsaw changes get back in jdk9/dev (http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-March/003877.html). Thanks, -Joe On 3/12/2016 1:28 PM, Chris Hegarty wrote: Looks good Joe. -Chris On 11 Mar 2016, at 22:28, joe darcy wrote: Hello, As Jon Gibbons has noted off-list, the problem list entries can directly include the bug number associated with the test in question, enabling better reporting. This format should be used rather than the current convention of putting the bug number in a comment. Please review the webrev to adopt the revised format for the problem list: http://cr.openjdk.java.net/~darcy/8151763.0/ I've verified jtreg produces the same test list with the old and new versions of the problem list. Thanks, -Joe
JDK 9 RFR of JDK-8083436: Doclint regression introduced by JDK-8043758
Hello,
Please review the patch below to address a recently introduced doclint
regression.
Thanks,
-Joe
diff -r 5f952ade41ff
src/java.base/share/classes/javax/net/ssl/SSLEngineResult.java
--- a/src/java.base/share/classes/javax/net/ssl/SSLEngineResult.java Wed
Jun 03 14:35:17 2015 -0700
+++ b/src/java.base/share/classes/javax/net/ssl/SSLEngineResult.java Wed
Jun 03 16:04:22 2015 -0700
@@ -280,7 +280,7 @@
* @apiNote Note that sequence number is an unsigned long and cannot
* exceed {@code -1L}. It is desired to use the unsigned
* long comparing mode for comparison of unsigned long
values
- * (see also {@link java.lang.Long#compareUnsigned()
+ * (see also {@link java.lang.Long#compareUnsigned(long,
long)
* Long.compareUnsigned()}).
*
* For DTLS protocols, the first 16 bits of the sequence
@@ -300,7 +300,7 @@
* record; or ${@code -1L} if no record is produced or
consumed,
* or this operation is not supported by the underlying
provider
*
- * @see java.lang.Long#compareUnsigned(boolean, boolean)
+ * @see java.lang.Long#compareUnsigned(long, long)
*
* @since 1.9
*/
Re: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness
Hello, I'd like to get this changeset, or something close to it, pushed soon so we can start taking advantage of better failure triaging. Any further concerns? Thanks, -Joe On 4/24/2015 11:04 AM, joe darcy wrote: On 4/23/2015 10:58 PM, Alan Bateman wrote: On 24/04/2015 02:54, Joseph D. Darcy wrote: Hello, Any additional comments on marking with tests in question with a "randomness" keyword? Thanks, -Joe I don't object to this keyword although I should say that most of the (apparent) randomness that I've seen hasn't been because of tests using Random but rather because of non-deterministic sequence of tests running in the same VM. The switch from othervm to agentvm a few years ago took a long time to weed out issues, same thing (even more) with -concurrency. Another source of apparent randomness is just having a large pool of machines and where machines are randomly selected to execute the tests. I agree with your comments that tests using Random should have report the seed and a have a way to re-run with the same value. It could help with some cases. One thing that isn't clear to me is how this keyword will be maintained. If I modify a test and replace the use of Random then I guess I need to remember to also remove this label. When I add a test that uses Random ... Just wondering if there is a tool to do the tests analysis, identify the use of specific APIs ,and help identify where the keyword might be missing or not needed. The goal of the keyword is to enable better analysis of bug failures. We (still) have some intermittent test failures in the platform, some probably remaining from -concurrency issues and some due to inconsistent machine config issues on the test farms. However, there is reason to believe some of the tests also fail because of the use of randomness in the generation of test cases. For example, the test java/lang/invoke/MethodHandles/CatchExceptionTest.java fails about once every three hundred runs when the random cases it generates trigger an error condition. Setting the seed to known-bad value causes the test to fail consistently (JDK-8055269). I have suspicions some of our other intermittently failing tests are in a similar but undiagnosed situation. If a test uses randomness, I think the default assumed cause for a test failure should switch from environmental causes (bad machine config, etc.) to the random behavior. Therefore, when a random-using test fails, I think the failure analysis needs to include recording of the bad seed to see if the failure is reproducible / deterministic with a fixed seed value. I was very surprised by the large number of random-using tests in the JDK regression tests. Nearly all of these have been stably passing for many years. After the one-time cost of this large update to add the keywords, there would be a small amount of incremental test maintenance as new random-using tests were added or the randomness value of a test changed. However, I would expect whether or not a test used randomness to be a property of a test that very rarely changed. Thanks, -Joe
Re: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness
Hello, Any additional comments on marking with tests in question with a "randomness" keyword? Thanks, -Joe On 4/21/2015 7:13 PM, Joseph D. Darcy wrote: Hello, As the next step of implementing "Proposed new policies for JDK 9 regression tests: tiered testing, intermittent failures, and randomness" [1], please review this changeset which adds a "randomness" jtreg keyword and tags 240 regression tests in the jdk repository with the keyword: JDK-8078334: Mark regression tests using randomness http://cr.openjdk.java.net/~darcy/8078334.0/ The update to test/TEST.ROOT is -# The list of keywords supported in the entire test suite -keys=2d dnd i18n intermittent +# The list of keywords supported in the entire test suite. The +# "intermittent" keyword marks tests known to fail intermittently. +# The "randomness" keyword marks tests using randomness with test +# cases differing from run to run. (A test using a fixed random seed +# would not count as "randomness" by this definition.) Extra care +# should be taken to handle test failures of intermittent or +# randomness tests. + +keys=2d dnd i18n intermittent randomness To find the affected files for this fix, I grepped over the regression tests looking for "random" and verified if a random number generated was used in a way where its values would differ from run to run. In particular, as noted above, a java.util.Random random number generator with a fixed seed did *not* qualify a test for the "randomness" keyword. The usual update to the files in this changeset is just + * @key randomness The updated tests are mostly in the core libs and security libs areas with a few serviceability tests too. The list in this bug is not quite exhaustive; I did not include rmi tests or client libraries tests. I verified that running jtreg ... -l -k:randomness . returns the expected number of tests and that the tests continue to pass (or be ignored) when run. One goal of marking the tests using randomness is to help root out some remaining intermittent test failures. If one of the randomness tests is observed to fail intermittently, if it has not already been updated to print out the random seed and be able to accept a particular seed when run, the test should be so modified so that future failures can log the seed value in hopes of reproducing the failure. Brian Burkhalter has proactively made these sorts of changes to the java.math tests earlier in JDK 9. [2] Since most of the randomness tests don't have a history of instability (and due to the unexpected large number of them!), I don't think it is necessary to proactively update all the other tests without evidence of a history of failure. However, when an otherwise unexplained failure is seen, I recommend applying the sort of updates Brian has done in java.math to the failing test(s). Thanks, -Joe [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html [2] JDK-8074460, Always print seeds used in [Splittable]Random instances in java.math tests, https://bugs.openjdk.java.net/browse/JDK-8074460
Re: JDK 9 RFR of JDK-8078468: Update security libraries to use diamond with anonymous classes
Hi Max, On 4/23/2015 5:33 PM, Weijun Wang wrote: Hi Joe The changes look good. I remember last time when Stuart updated JDK to use diamond there was a rule that if the assignment of a variable is a little far from its definition, then we don't use diamond. It seems we are not obeying it anymore? A few of the changes in the patch were of the form List foos = new ArrayList(); => List foos = new ArrayList<>(); but in most cases a type hint wasn't on the same line. When diamond was first introduced in JDK 7 circa 2010 - 2011, I think developers were less certain of when to use the feature. After a few years to get familiar with it, I think more aggressive diamond use is fine, especially since tooling support should already be in place to view the inferred type bounds if interested (I know NetBeans has long had such a feature). Thanks for the review. -Joe Thanks Max On 4/24/2015 6:34 AM, Joseph D. Darcy wrote: Hello, Please review the straightforward changes to address JDK-8078468: Update security libraries to use diamond with anonymous classes http://cr.openjdk.java.net/~darcy/8078468.0/ This patch combines two kinds of updates; the first to use traditional diamond available since JDK 7 and the second to use diamond with anonymous classes, a feature now available in JDK 9. As with core libraries (JDK-8078467), many of the uses of the new feature are locations where "new PrivilegedAction" is used. The diamond location candidates were found using a finder built into javac. Thanks, -Joe
JDK 9 RFR of JDK-8078468: Update security libraries to use diamond with anonymous classes
Hello, Please review the straightforward changes to address JDK-8078468: Update security libraries to use diamond with anonymous classes http://cr.openjdk.java.net/~darcy/8078468.0/ This patch combines two kinds of updates; the first to use traditional diamond available since JDK 7 and the second to use diamond with anonymous classes, a feature now available in JDK 9. As with core libraries (JDK-8078467), many of the uses of the new feature are locations where "new PrivilegedAction" is used. The diamond location candidates were found using a finder built into javac. Thanks, -Joe
JDK 9 RFR of JDK-8078334: Mark regression tests using randomness
Hello, As the next step of implementing "Proposed new policies for JDK 9 regression tests: tiered testing, intermittent failures, and randomness" [1], please review this changeset which adds a "randomness" jtreg keyword and tags 240 regression tests in the jdk repository with the keyword: JDK-8078334: Mark regression tests using randomness http://cr.openjdk.java.net/~darcy/8078334.0/ The update to test/TEST.ROOT is -# The list of keywords supported in the entire test suite -keys=2d dnd i18n intermittent +# The list of keywords supported in the entire test suite. The +# "intermittent" keyword marks tests known to fail intermittently. +# The "randomness" keyword marks tests using randomness with test +# cases differing from run to run. (A test using a fixed random seed +# would not count as "randomness" by this definition.) Extra care +# should be taken to handle test failures of intermittent or +# randomness tests. + +keys=2d dnd i18n intermittent randomness To find the affected files for this fix, I grepped over the regression tests looking for "random" and verified if a random number generated was used in a way where its values would differ from run to run. In particular, as noted above, a java.util.Random random number generator with a fixed seed did *not* qualify a test for the "randomness" keyword. The usual update to the files in this changeset is just + * @key randomness The updated tests are mostly in the core libs and security libs areas with a few serviceability tests too. The list in this bug is not quite exhaustive; I did not include rmi tests or client libraries tests. I verified that running jtreg ... -l -k:randomness . returns the expected number of tests and that the tests continue to pass (or be ignored) when run. One goal of marking the tests using randomness is to help root out some remaining intermittent test failures. If one of the randomness tests is observed to fail intermittently, if it has not already been updated to print out the random seed and be able to accept a particular seed when run, the test should be so modified so that future failures can log the seed value in hopes of reproducing the failure. Brian Burkhalter has proactively made these sorts of changes to the java.math tests earlier in JDK 9. [2] Since most of the randomness tests don't have a history of instability (and due to the unexpected large number of them!), I don't think it is necessary to proactively update all the other tests without evidence of a history of failure. However, when an otherwise unexplained failure is seen, I recommend applying the sort of updates Brian has done in java.math to the failing test(s). Thanks, -Joe [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html [2] JDK-8074460, Always print seeds used in [Splittable]Random instances in java.math tests, https://bugs.openjdk.java.net/browse/JDK-8074460
Re: JDK 9 RFR of JDK-8069277: Doclint regression in java/security/KeyStore.java
Hi Max,
Yes; both should be "linkplain" -- I'll push with that fix.
Thanks,
-Joe
On 2/9/2015 4:54 PM, Wang Weijun wrote:
Should the "providers" link in the 2nd method also be "linkplain"?
--Max
On Feb 10, 2015, at 08:28, Joseph D. Darcy wrote:
Hello,
As the final purge of doclint warnings from the java.base module approaches,
please review the changes for
JDK-8069277: Doclint regression in java/security/KeyStore.java
http://cr.openjdk.java.net/~darcy/8069277.0/
Patch below.
Thanks,
-Joe
--- old/src/java.base/share/classes/java/security/KeyStore.java 2015-02-09
16:25:01.853908872 -0800
+++ new/src/java.base/share/classes/java/security/KeyStore.java 2015-02-09
16:25:01.529912945 -0800
@@ -1618,11 +1618,13 @@
* integrity check.
*
*
- * This method traverses the list of registered security {@link Providers},
- * starting with the most preferred Provider.
- * For each {@link KeyStoreSpi} implementation supported by a Provider,
- * it invokes the {@link engineProbe} method to determine if it supports
- * the specified keystore.
+ * This method traverses the list of registered security
+ * {@linkplain Provider providers}, starting with the most
+ * preferred Provider.
+ * For each {@link KeyStoreSpi} implementation supported by a
+ * Provider, it invokes the {@link
+ * KeyStoreSpi#engineProbe(InputStream) engineProbe} method to
+ * determine if it supports the specified keystore.
* A new KeyStore object is returned that encapsulates the KeyStoreSpi
* implementation from the first Provider that supports the specified file.
*
@@ -1672,11 +1674,12 @@
* unlock the keystore data or perform an integrity check.
*
*
- * This method traverses the list of registered security {@link Providers},
- * starting with the most preferred Provider.
- * For each {@link KeyStoreSpi} implementation supported by a Provider,
- * it invokes the {@link engineProbe} method to determine if it supports
- * the specified keystore.
+ * This method traverses the list of registered security {@link
+ * Provider providers}, starting with the most preferred Provider.
+ * For each {@link KeyStoreSpi} implementation supported by a
+ * Provider, it invokes the {@link
+ * KeyStoreSpi#engineProbe(InputStream) engineProbe} method to
+ * determine if it supports the specified keystore.
* A new KeyStore object is returned that encapsulates the KeyStoreSpi
* implementation from the first Provider that supports the specified file.
*
JDK 9 RFR of JDK-8069277: Doclint regression in java/security/KeyStore.java
Hello,
As the final purge of doclint warnings from the java.base module
approaches, please review the changes for
JDK-8069277: Doclint regression in java/security/KeyStore.java
http://cr.openjdk.java.net/~darcy/8069277.0/
Patch below.
Thanks,
-Joe
--- old/src/java.base/share/classes/java/security/KeyStore.java
2015-02-09 16:25:01.853908872 -0800
+++ new/src/java.base/share/classes/java/security/KeyStore.java
2015-02-09 16:25:01.529912945 -0800
@@ -1618,11 +1618,13 @@
* integrity check.
*
*
- * This method traverses the list of registered security {@link
Providers},
- * starting with the most preferred Provider.
- * For each {@link KeyStoreSpi} implementation supported by a Provider,
- * it invokes the {@link engineProbe} method to determine if it
supports
- * the specified keystore.
+ * This method traverses the list of registered security
+ * {@linkplain Provider providers}, starting with the most
+ * preferred Provider.
+ * For each {@link KeyStoreSpi} implementation supported by a
+ * Provider, it invokes the {@link
+ * KeyStoreSpi#engineProbe(InputStream) engineProbe} method to
+ * determine if it supports the specified keystore.
* A new KeyStore object is returned that encapsulates the KeyStoreSpi
* implementation from the first Provider that supports the
specified file.
*
@@ -1672,11 +1674,12 @@
* unlock the keystore data or perform an integrity check.
*
*
- * This method traverses the list of registered security {@link
Providers},
- * starting with the most preferred Provider.
- * For each {@link KeyStoreSpi} implementation supported by a Provider,
- * it invokes the {@link engineProbe} method to determine if it
supports
- * the specified keystore.
+ * This method traverses the list of registered security {@link
+ * Provider providers}, starting with the most preferred Provider.
+ * For each {@link KeyStoreSpi} implementation supported by a
+ * Provider, it invokes the {@link
+ * KeyStoreSpi#engineProbe(InputStream) engineProbe} method to
+ * determine if it supports the specified keystore.
* A new KeyStore object is returned that encapsulates the KeyStoreSpi
* implementation from the first Provider that supports the
specified file.
*
[security-dev 01555]: Re: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6
Vincent Ryan wrote: On 22/01/2010 01:38, Andrew John Hughes wrote: 2010/1/21 Vincent Ryan : I hear ya. Sorry for the delay on this. I'll push the fix for OpenJDK today. Thanks! Would this be suitable for OpenJDK6 as well? CCing the jdk6-dev list on that. Yes. The patch should be applied to OpenJDK6 too. I hereby authorize you do push the fix to OpenJDK 6 too :-) Repositories are under http://hg.openjdk.java.net/jdk6/jdk6/ -Joe
[security-dev 01436]: Re: hg: jdk7/tl/jdk: 6907177: Update jdk tests to remove unncessary -source and -target options
Jonathan Gibbons wrote: Andrew John Hughes wrote: 2009/12/4 : Changeset: 1755493c5774 Author:darcy Date: 2009-12-03 18:19 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1755493c5774 6907177: Update jdk tests to remove unncessary -source and -target options Reviewed-by: ohair ! test/demo/jvmti/hprof/CpuOldTest.java [snip] ! test/sun/tools/jconsole/ResourceCheckTest.sh Was this really necessary? The options, as far as I can see, were doing no harm but this change means that a compiler that defaults to a version < 1.5 (e.g. ecj) will now fail to compile the tests. This is a JDK test suite and there is no guarantee that any other compiler can be used. All sorts of JDK-specific options may be passed to the compiler, runtime and other tools in these tests. Yes, these tests are part of the JDK 7 regression test suite. Interoperability with other compilers, even other compilers from related code bases like OpenJDK 6, is a non-goal. Having the old -source options in the tests was at least in a small way reducing the effectiveness of the test suite since the default -source setting is now 7. Using of new language features in tests, even tests not targeting those language features is certainly encouraged. As explained in my code review request on corelib-dev, many of the -source directives dated to back in JDK 5 before the default sourced was upped from 1.4 to 5. Tests written later in JDK 5 that use JDK 5 language features didn't have explicit -source settings. While the build environment for most programs should explicitly set source, target, and encoding, "Build Advice: Set Source, Target, and Encoding" http://blogs.sun.com/darcy/entry/build_advice_set_source_target the regressions tests of the JDK itself are (usually) an exception. -Joe
[security-dev 00363]: Re: SecurityException in AnnotationInvocationHandler.getMemberMethods
Joseph D. Darcy wrote:
Martin Buchholz wrote:
If I had known when I started how hard it would be,
I would never have started writing one...
That is the case with many endeavors ;-)
Where are annotations tests supposed to go?
They seem under-test-covered.
I've put it into a new directory, test/java/lang/annotation
Recently I moved over the existing closed regression tests for
annotations to test/java/lang/annotation:
http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-October/000231.html
so I'll find a home for your tests in there. The newly-opened tests
will be in the b13 source drop.
Martin, I've reviewed your test and code and Sean Mullan has reviewed
the code too. I verified the test fails with the current build and
passes with change. I've putback the code changes and test into OpenJDK
6 b13. The test lives at
test/java/lang/annotations/ParameterAnnotations.java; the other
annotation tests will go in that directory once I move them over in JDK
7 too. I think you're clear to commit this fix to the JDK 7 repository too.
-Joe
Thanks,
-Joe
Please review. The following fails with
current openjdk, passes with proposed fix.
/*
* Copyright 2008 Sun Microsystems, Inc. All Rights Reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2 only, as
* published by the Free Software Foundation.
*
* This code is distributed in the hope that it will be useful, but
WITHOUT
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
* version 2 for more details (a copy is included in the LICENSE file
that
* accompanied this code).
*
* You should have received a copy of the GNU General Public License
version
* 2 along with this work; if not, write to the Free Software
Foundation,
* Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
*
* Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa
Clara,
* CA 95054 USA or visit www.sun.com if you need additional
information or
* have any questions.
*/
/*
* @test
* @bug 6761678
* @summary Check properties of Annotations returned from
* getParameterAnnotations, including freedom from security
* exceptions.
* @author Martin Buchholz
*/
import java.lang.annotation.Annotation;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import java.lang.reflect.Method;
import java.security.Permission;
import java.security.Policy;
import java.security.ProtectionDomain;
@Retention(RetentionPolicy.RUNTIME)
@Target({ ElementType.FIELD, ElementType.PARAMETER })
@interface Named {
String value();
}
public class ParameterAnnotations {
// A security policy that differs from the default only in that it
// allows a security manager to be uninstalled.
static class MyPolicy extends Policy {
final Policy defaultPolicy;
MyPolicy(Policy defaultPolicy) {
this.defaultPolicy = defaultPolicy;
}
public boolean implies(ProtectionDomain pd, Permission p) {
return p.getName().equals("setSecurityManager") ||
defaultPolicy.implies(pd, p);
}
}
public void nop(@Named("foo") Object foo,
@Named("bar") Object bar) {
}
void test(String[] args) throws Throwable {
// Test without a security manager
test1();
// Test with a security manager
Policy defaultPolicy = Policy.getPolicy();
Policy.setPolicy(new MyPolicy(defaultPolicy));
System.setSecurityManager(new SecurityManager());
try {
test1();
} finally {
System.setSecurityManager(null);
Policy.setPolicy(defaultPolicy);
}
}
void test1() throws Throwable {
for (Method m : thisClass.getMethods()) {
if (m.getName().equals("nop")) {
Annotation[][] ann = m.getParameterAnnotations();
equal(ann.length, 2);
Annotation foo = ann[0][0];
Annotation bar = ann[1][0];
equal(foo.toString(), "@Named(value=foo)");
equal(bar.toString(), "@Named(value=bar)");
check(foo.equals(foo));
check(! foo.equals(bar));
}
}
}
//- Infrastructure ---
volatile int passed = 0, failed = 0;
void pass() {passed++;}
void fail() {failed++; Thread.dumpStack();}
void fail(String msg) {System.err.println(msg); fail();}
void unexpected(Throwable t) {failed++; t.printStackTrace();}
void check(boolean
[security-dev 00362]: Re: SecurityException in AnnotationInvocationHandler.getMemberMethods
Martin Buchholz wrote:
If I had known when I started how hard it would be,
I would never have started writing one...
That is the case with many endeavors ;-)
Where are annotations tests supposed to go?
They seem under-test-covered.
I've put it into a new directory, test/java/lang/annotation
Recently I moved over the existing closed regression tests for
annotations to test/java/lang/annotation:
http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-October/000231.html
so I'll find a home for your tests in there. The newly-opened tests
will be in the b13 source drop.
Thanks,
-Joe
Please review. The following fails with
current openjdk, passes with proposed fix.
/*
* Copyright 2008 Sun Microsystems, Inc. All Rights Reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2 only, as
* published by the Free Software Foundation.
*
* This code is distributed in the hope that it will be useful, but WITHOUT
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
* version 2 for more details (a copy is included in the LICENSE file that
* accompanied this code).
*
* You should have received a copy of the GNU General Public License version
* 2 along with this work; if not, write to the Free Software Foundation,
* Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
*
* Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
* CA 95054 USA or visit www.sun.com if you need additional information or
* have any questions.
*/
/*
* @test
* @bug 6761678
* @summary Check properties of Annotations returned from
* getParameterAnnotations, including freedom from security
* exceptions.
* @author Martin Buchholz
*/
import java.lang.annotation.Annotation;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import java.lang.reflect.Method;
import java.security.Permission;
import java.security.Policy;
import java.security.ProtectionDomain;
@Retention(RetentionPolicy.RUNTIME)
@Target({ ElementType.FIELD, ElementType.PARAMETER })
@interface Named {
String value();
}
public class ParameterAnnotations {
// A security policy that differs from the default only in that it
// allows a security manager to be uninstalled.
static class MyPolicy extends Policy {
final Policy defaultPolicy;
MyPolicy(Policy defaultPolicy) {
this.defaultPolicy = defaultPolicy;
}
public boolean implies(ProtectionDomain pd, Permission p) {
return p.getName().equals("setSecurityManager") ||
defaultPolicy.implies(pd, p);
}
}
public void nop(@Named("foo") Object foo,
@Named("bar") Object bar) {
}
void test(String[] args) throws Throwable {
// Test without a security manager
test1();
// Test with a security manager
Policy defaultPolicy = Policy.getPolicy();
Policy.setPolicy(new MyPolicy(defaultPolicy));
System.setSecurityManager(new SecurityManager());
try {
test1();
} finally {
System.setSecurityManager(null);
Policy.setPolicy(defaultPolicy);
}
}
void test1() throws Throwable {
for (Method m : thisClass.getMethods()) {
if (m.getName().equals("nop")) {
Annotation[][] ann = m.getParameterAnnotations();
equal(ann.length, 2);
Annotation foo = ann[0][0];
Annotation bar = ann[1][0];
equal(foo.toString(), "@Named(value=foo)");
equal(bar.toString(), "@Named(value=bar)");
check(foo.equals(foo));
check(! foo.equals(bar));
}
}
}
//- Infrastructure ---
volatile int passed = 0, failed = 0;
void pass() {passed++;}
void fail() {failed++; Thread.dumpStack();}
void fail(String msg) {System.err.println(msg); fail();}
void unexpected(Throwable t) {failed++; t.printStackTrace();}
void check(boolean cond) {if (cond) pass(); else fail();}
void equal(Object x, Object y) {
if (x == null ? y == null : x.equals(y)) pass();
else fail(x + " not equal to " + y);}
static Class thisClass = new Object(){}.getClass().getEnclosingClass();
public static void main(String[] args) throws Throwable {
try {thisClass.getMethod("instanceMain",String[].class)
.invoke(thisClass.newInstance(), (Object) args);}
catch (Throwable e) {throw e.getCause();}}
public void instanceMain(String[] args) throws Throwable {
try {test(args);} catch
