On Fri, 29 Apr 2022 09:03:58 GMT, Pavel Rappo wrote:
> * Syntactically improves a few cases from 8285676
> (https://github.com/openjdk/jdk/pull/8410)
> * Fixes a few misspelled `@param` tags for elements that, although are not
> included in the API Documentation, are visible in and processed by
On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy wrote:
> To enable more complete doclint checking (courtesy @jonathan-gibbons), please
> review this PR to add type-level @param tags where they are missing.
>
> To the maintainers of java.util.concurrent, those changes could be separat
tenance of that code.
>
> Making these library fixes is a blocker for correcting and expanding the
> doclint checks (JDK-8285496).
>
> I'll update copyright years before pushing.
Joe Darcy has updated the pull request with a new target base due to a merge or
a rebase. The increm
On Thu, 28 Apr 2022 08:10:38 GMT, Alan Bateman wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Respond to more review feedback.
>
> src/java.base/share/classes/java/nio/file/Wat
tenance of that code.
>
> Making these library fixes is a blocker for correcting and expanding the
> doclint checks (JDK-8285496).
>
> I'll update copyright years before pushing.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last
On Thu, 28 Apr 2022 08:08:37 GMT, Alan Bateman wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Respond to more review feedback.
>
> src/java.base/share/classes/java/nio/file/Secu
On Wed, 27 Apr 2022 23:24:57 GMT, Stuart Marks wrote:
>> I said "keys maintained", omitting "by this map" to finesse the question of
>> if the SimpleEntry class *is* a map, or is used to implement a map, etc. I
>> can change it to include "by this map" if the map/entry distinction is okay
>> t
tenance of that code.
>
> Making these library fixes is a blocker for correcting and expanding the
> doclint checks (JDK-8285496).
>
> I'll update copyright years before pushing.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last
On Wed, 27 Apr 2022 10:55:22 GMT, Daniel Fuchs wrote:
>> Joe Darcy has updated the pull request with a new target base due to a merge
>> or a rebase. The incremental webrev excludes the unrelated changes brought
>> in by the merge/rebase. The pull request contains three
tenance of that code.
>
> Making these library fixes is a blocker for correcting and expanding the
> doclint checks (JDK-8285496).
>
> I'll update copyright years before pushing.
Joe Darcy has updated the pull request with a new target base due to a merge or
a rebase. The increm
On Wed, 27 Apr 2022 10:54:00 GMT, Daniel Fuchs wrote:
>> To enable more complete doclint checking (courtesy @jonathan-gibbons),
>> please review this PR to add type-level @param tags where they are missing.
>>
>> To the maintainers of java.util.concurrent, those changes could be separated
>> o
On Wed, 27 Apr 2022 01:39:27 GMT, Stuart Marks wrote:
>> To enable more complete doclint checking (courtesy @jonathan-gibbons),
>> please review this PR to add type-level @param tags where they are missing.
>>
>> To the maintainers of java.util.concurrent, those changes could be separated
>> o
To enable more complete doclint checking (courtesy @jonathan-gibbons), please
review this PR to add type-level @param tags where they are missing.
To the maintainers of java.util.concurrent, those changes could be separated
out in another bug if that would ease maintenance of that code.
Making
On Fri, 8 Apr 2022 13:40:37 GMT, Sean Mullan wrote:
> Please review these changes to update the security libraries to use sealed
> classes. See JEP 409 for more details on sealed classes.
>
> No CSR is required as all the changes are to internal classes. A few classes
> that did not have subcl
On Fri, 4 Mar 2022 21:17:01 GMT, Joe Darcy wrote:
> Please review this small API enhancement to add the usual constructors taking
> a cause to SocketException and then update uses of initiCause on creating
> SocketException to instead pass the cause via the constructor.
>
> Ple
.net/browse/JDK-8282688
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Improve test.
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7705/files
- new: https://git.openjdk.java.net/jdk/pull/7705/files/978b379d..da
.net/browse/JDK-8282688
Joe Darcy has updated the pull request with a new target base due to a merge or
a rebase. The incremental webrev excludes the unrelated changes brought in by
the merge/rebase. The pull request contains three additional commits since the
last revision:
- Add regression
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote:
> Hi
>
> I have reviewed the code for removing double semicolons at the end of lines
>
> all the best
> matteo
Marked as reviewed by darcy (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/7268
Please review this small API enhancement to add the usual constructors taking a
cause to SocketException and then update uses of initiCause on creating
SocketException to instead pass the cause via the constructor.
Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688
---
On Tue, 1 Feb 2022 21:11:39 GMT, Joe Darcy wrote:
> The references to JOSS, the Java Object Serialization Specification, are not
> done consistently in the API javadoc. This should be improved.
>
> I'll update copyright years before pushing.
This pull request has no
> The references to JOSS, the Java Object Serialization Specification, are not
> done consistently in the API javadoc. This should be improved.
>
> I'll update copyright years before pushing.
Joe Darcy has updated the pull request incrementally with one additional commi
The references to JOSS, the Java Object Serialization Specification, are not
done consistently in the API javadoc. This should be improved.
I'll update copyright years before pushing.
-
Commit messages:
- JDK-8281082: Improve javadoc references to JOSS
Changes: https://git.openjdk
On Fri, 28 Jan 2022 16:58:55 GMT, Michael McMahon wrote:
>> Hi,
>>
>> This change adds Channel Binding Token (CBT) support to HTTPS
>> (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO,
>> Kerberos) authentication scheme. When enabled, the implementation
>> preemptively inclu
On Mon, 22 Nov 2021 12:09:30 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-419 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] - https://openjd
On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote:
> Here are the code changes for the "Deprecate finalizers in the standard Java
> API" portion of JEP 421 ("Deprecate Finalization for Removal") for code
> review.
>
> This change makes the indicated deprecations, and updates the API spec
On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote:
> This PR follows up one of the recent PRs, where I used a non-canonical
> modifier order. Since the problem was noticed [^1], why not to address it at
> mass?
>
> As far as I remember, the first mass-canonicalization of modifiers took place
On Sat, 9 Oct 2021 19:41:51 GMT, Joe Darcy wrote:
> Analogous to other recent cleanups like JDK-8274393, suppress warnings for
> serialization-related issues in the windows mscapi code.
This pull request has now been integrated.
Changeset: 926966be
Author: Joe Darcy
URL:
Analogous to other recent cleanups like JDK-8274393, suppress warnings for
serialization-related issues in the windows mscapi code.
-
Commit messages:
- Applease jcheck.
- 8275003: Suppress warnings on non-serializable non-transient instance fields
in windows mscapi
Changes: http
On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov
wrote:
> Redundant castings make code harder to read.
> Found them by IntelliJ IDEA.
> I tried to select only casts which are definitely safe to remove. Also didn't
> touch primitive types casts.
Curious. The JDK build is done with javac -Xlint:
On Mon, 27 Sep 2021 19:24:39 GMT, Joe Darcy wrote:
> Follow-up change to JDK-8231262, augmentations to javac's Xlint:serial
> checking are out for review (#5709) and various security libraries would need
> some changes to pass under the expanded checks.
>
> The cha
> serializable types are not declared with a type statically known to be
> serializable. That isn't necessarily a correctness issues, but it does merit
> further scrutiny.
Joe Darcy has updated the pull request with a new target base due to a merge or
a rebase. The incremental web
> serializable types are not declared with a type statically known to be
> serializable. That isn't necessarily a correctness issues, but it does merit
> further scrutiny.
Joe Darcy has updated the pull request with a new target base due to a merge or
a rebase. The incremental web
On Wed, 29 Sep 2021 18:13:14 GMT, Joe Darcy wrote:
>> Follow-up change to JDK-8231262, augmentations to javac's Xlint:serial
>> checking are out for review (#5709) and various security libraries would
>> need some changes to pass under the expanded checks.
>>
&
Follow-up change to JDK-8231262, augmentations to javac's Xlint:serial checking
are out for review (#5709) and various security libraries would need some
changes to pass under the expanded checks.
The changes are to suppress warnings where non-transient fields in serializable
types are not decl
This is an initial PR for expanded lint warnings done under two bugs:
8202056: Expand serial warning to check for bad overloads of serial-related
methods and ineffectual fields
8160675: Issue lint warning for non-serializable non-transient instance fields
in serializable type
to get feedback on
On Tue, 21 Sep 2021 13:16:02 GMT, Pavel Rappo wrote:
>> 8274075: Fix miscellaneous typos in java.base
>
> Pavel Rappo has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Tweak wording for Throwable constructor parameters
Marked as reviewed by
On 8/18/2021 6:20 AM, Roger Riggs wrote:
On Wed, 18 Aug 2021 10:07:35 GMT, Claes Redestad wrote:
C-style array declarations generate noisy warnings in IDEs, et.c. This patch
cleans up all java.* packages.
(Copyrights intentionally not updated due the triviality of most changes)
34 Minutes
On 6/21/2021 2:02 PM, Paul Sandoz wrote:
On Mon, 21 Jun 2021 05:17:09 GMT, Yi Yang wrote:
After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
the whole JDK codebase.
Yi Yang has updated th
On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote:
> Please review this implementation of [JEP
> 411](https://openjdk.java.net/jeps/411).
>
> The code change is divided into 3 commits. Please review them one by one.
>
> 1.
> https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28
On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy wrote:
> 8264148: Update spec for exceptions retrofitted for exception chaining
This pull request has now been integrated.
Changeset: 815248ab
Author: Joe Darcy
URL: https://git.openjdk.java.net/jdk/commit/815248ab
Stats: 84 lines in
On 3/30/2021 6:29 AM, Roger Riggs wrote:
On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy wrote:
8264148: Update spec for exceptions retrofitted for exception chaining
I agree that the public field in WriteAbortedException could be remediated.
But it is also mostly harmless.
src
On 3/30/2021 6:43 AM, jmehrens wrote:
On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy wrote:
8264148: Update spec for exceptions retrofitted for exception chaining
src/java.base/share/classes/java/io/WriteAbortedException.java line 86:
84: @Override
85: public Throwable getCause
On Thu, 25 Mar 2021 18:52:54 GMT, Stuart Marks wrote:
>> 8264148: Update spec for exceptions retrofitted for exception chaining
>
> The removal of the obsolescent "As of release 1.4, this exception has been
> retrofitted..." is good. Changing the calls from the other exception-getting
> methods
8264148: Update spec for exceptions retrofitted for exception chaining
-
Commit messages:
- Respond to review feedback.
- Respond to review feedback.
- Merge branch 'master' into 8264148
- Merge branch 'master' into 8264148
- 8264148: Update spec for exceptions retrofitted for ex
On Fri, 26 Mar 2021 12:25:43 GMT, Jim Laskey wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>>
>> javadoc can be
On Thu, 18 Mar 2021 15:08:56 GMT, Jim Laskey wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>>
>> javadoc can be
On Mon, 15 Mar 2021 12:54:32 GMT, Jim Laskey wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>>
>> javadoc can be
On Mon, 15 Mar 2021 12:54:32 GMT, Jim Laskey wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>>
>> javadoc can be
On Tue, 9 Mar 2021 00:56:25 GMT, Bradford Wetmore wrote:
>> Fix various things pointed out by the most recent doclint run in the
>> security-libs area.
>>
>> This is docs only: I will be checking doccheck/doclint, and will be running
>> tier1/tier2 tests. Minor spot checks on generated files
On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon
wrote:
> Hi,
>
> Could someone please review my code for updating the code in the `java.io`,
> `java.math`, and `java.text` packages to make use of the `instanceof` pattern
> variable?
>
> Kind regards,
> Patrick
Marked as reviewed by darcy
On Tue, 2 Mar 2021 19:35:47 GMT, Jonathan Gibbons wrote:
> Please review some minor doc fixes, for issues found by _doccheck_.There
> are two kinds of errors that are addressed.
>
> 1. Incorrect use of ``. In HTML, `` marks the *beginning* of a
> paragraph. It is not a terminator, to mark
On Fri, 19 Feb 2021 12:48:05 GMT, Jim Laskey wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>>
>> javadoc can be
On Tue, 5 Jan 2021 21:02:21 GMT, Joe Darcy wrote:
> Back in JDK 16, two unintended default constructors were identified and
> deprecated for removal. The time has come to remove them.
>
> Please also review the corresponding CSRs:
>
> JDK-8258521 Remove terminally depreca
Back in JDK 16, two unintended default constructors were identified and
deprecated for removal. The time has come to remove them.
Please also review the corresponding CSRs:
JDK-8258521 Remove terminally deprecated constructor in GSSUtil
https://bugs.openjdk.java.net/browse/JDK-8258521
JDK-825
On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote:
> The change is (just) to remove legacy usages of a JDK-private custom tag.
Marked as reviewed by darcy (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/814
On 7/24/2020 10:32 AM, Sean Mullan wrote:
On 7/24/20 1:18 PM, Joe Darcy wrote:
-
src/jdk.security.jgss/share/classes/com/sun/security/jgss/GSSUtil.java
37 /**
38 * Do not call.
39 */
40 @Deprecated(since="16", forRemoval=true)
41 public GSSUtil() {
Hi Sean,
On 7/24/2020 4:52 AM, Sean Mullan wrote:
Hi Joe,
On 7/24/20 1:17 AM, Joe Darcy wrote:
Hello,
Please review a set of changes to add explicit constructors to
replace default (implicit) constructors in various classes in
security libs across several modules:
JDK-8250246
Hello,
Please review a set of changes to add explicit constructors to replace
default (implicit) constructors in various classes in security libs
across several modules:
JDK-8250246: Address reliance on default constructors in security libs
http://cr.openjdk.java.net/~darcy/8250246.0/
Hello,
Please review the addition of several explicit constructors to abstract
classes in javax.net.ssl to remove the use of implicit default
constructors; CSR link and patch below:
JDK-8247374: Remove default constructors from javax.net.ssl
CSR: https://bugs.openjdk.java.net/browse/J
s? I'm assuming this is a jtreg feature
but I have not heard of it before.
Thanks,
Sean
Thanks,
-- Igor
On Jan 2, 2020, at 12:58 PM, Roger Riggs wrote:
The core lib changes look ok.
Roger
On Jan 2, 2020, at 1:26 PM, Joe Darcy wrote:
The removal of the existing TEST.properties file
Hi Chris and Sean,
I'll push a fix for JDK-8231262 with a single class-level suppression in
X509CertImpl:
@SuppressWarnings("serial") // See writeReplace method in Certificate
I've filed
JDK-8232062: Clarify serialization mechanisms of X509CertImpl
for the follow-up work.
Thank
Hi Sean,
Getting back to this review...
On 9/26/2019 1:55 PM, Sean Mullan wrote:
On 9/26/19 4:20 PM, Sean Mullan wrote:
Would you prefer I revise the patch where there are multiple
SuppressWarnings("serial") on fields to put a single one on the
class instead?
Yes, but only in the cases wher
Hi Sean,
Amended as requested before pushing; thanks,
-Joe
On 10/8/2019 2:12 PM, Sean Mullan wrote:
I would change "asn1" to "ASN.1" in the comment as that is the more
common usage of the acronym, otherwise looks good.
Thanks,
Sean
On 10/8/19 1:36 PM, Joe Darcy wro
PS And a revised webrev acting on comments from the JDK-8231262 to use a
single class-level @SuppressWarnings when an alternative serial form is
implicitly being used:
http://cr.openjdk.java.net/~darcy/8231368.1/
Thanks,
-Joe
On 10/8/2019 10:11 AM, Joe Darcy wrote:
Hi Sean,
Returning
trast, the javax.security.auth.kerberos.EncryptionKey class is
declared to be Serializable. Therefore, the @SuppressWarnings on the
field in the initial patch is needed.
If the patch looks good, I'll get this pushed.
Thanks,
-Joe
--Sean
On 9/23/19 8:15 PM, Joe Darcy wrote:
Hello,
Hello,
At least from a quick reading, either the spec change or the behavior
change would seem to merit a CSR.
Cheers,
-Joe
On 10/2/2019 4:26 PM, Ivan Gerasimov wrote:
Hi Chris!
Thank you very much for review!
I agree that it makes sense to update the javadoc for consistency.
I don't thi
Hi Sean,
On 9/26/2019 12:46 PM, Sean Mullan wrote:
On 9/23/19 4:16 PM, Joe Darcy wrote:
Hi Sean,
On 9/23/2019 12:19 PM, Sean Mullan wrote:
Hi Joe,
It's a little odd to suppress the warnings in the X509CertImpl class
since it is a subclass of java.security.cert.Certificate which
imple
Hello,
Another module, another review request as part of making serial warnings
more robust:
JDK-8231368: Suppress warnings on non-serializable non-transient
instance fields in java.security.jgss
http://cr.openjdk.java.net/~darcy/8231368.0/
(Related earlier review
https://mail.open
Hi Sean,
On 9/23/2019 12:19 PM, Sean Mullan wrote:
Hi Joe,
It's a little odd to suppress the warnings in the X509CertImpl class
since it is a subclass of java.security.cert.Certificate which
implements the writeReplace method so these fields are not serialized.
Also for other classes like X
On 9/21/2019 4:15 AM, Chris Hegarty wrote:
On 19 Sep 2019, at 18:32, Joe Darcy wrote:
Hello,
Ahead of augmenting javac's serial lint checks under JDK-8160675, it would be
helpful to mark fields in security libs classes where the class is
serializable, but a non-transient instance
Hello,
Ahead of augmenting javac's serial lint checks under JDK-8160675, it
would be helpful to mark fields in security libs classes where the class
is serializable, but a non-transient instance field does *not* have a
serialiable type. Such classes may have difficulties being serialized at
r
s not @Documented so it doesn't appear in the
generated javadoc.
Thanks,
-Joe
--Sean
On 8/27/19 8:16 PM, Joe Darcy wrote:
Hello,
Recent work for JDK-8202385: "Annotation to mark serial-related
fields and methods" added the java.io.Serial annotation type to the
platform. The i
Hello,
Recent work for JDK-8202385: "Annotation to mark serial-related fields
and methods" added the java.io.Serial annotation type to the platform.
The intention of this new annotation type is to allow
serialization-related fields and methods to be marked as documentation
and to allow strict
Hello,
On 12/21/2018 8:43 AM, Volker Simonis wrote:
Hi Alan,
thanks for looking at this issue. I've dived into the ZipFS
implementation during the last weeks and together with Christoph we've
extended and improved both the implementation the test coverage. As
Christoph already emphasized, this
Hello,
Please review a simple doc-only change to address:
JDK-8213911: Use example.com in java.net and other examples
http://cr.openjdk.java.net/~darcy/8213911.0/
Patch below.
Thanks,
-Joe
--- old/src/java.base/share/classes/java/net/HostPortrange.java
2018-11-26 13:32:47.07800
Changes look fine; thanks,
-Joe
On 10/1/2018 4:43 PM, Lance Andersen wrote:
The changes look reasonable Ivan
On Oct 1, 2018, at 7:37 PM, Ivan Gerasimov wrote:
Hello!
A handful of a few similar typos across core-libs/security-libs areas.
BUGURL: https://bugs.openjdk.java.net/browse/JDK-82
Hi Alan,
On 8/6/2018 11:12 PM, Alan Bateman wrote:
On 06/08/2018 20:11, joe darcy wrote:
Hello,
Various interfaces in the JDK extend Serializable and declare
serialVersionUID fields. Such fields are ineffectual and
@SuppressWarnings("serial") should be applied to such fields to
Hi Sergey,
On 8/6/2018 3:39 PM, Sergey Bylokhov wrote:
Hi, Joe.
On 06/08/2018 14:30, joe darcy wrote:
Even if currently less commonly used, I think "ineffectual" better
captures the intention of what I want to convey in the comment than
"ineffective."
Can you please cla
would probably have used "ineffective" instead of
"ineffectual".
(Googling "define ineffective" and "define ineffectual" shows an
interesting graph of
the use of the term with ineffective growing and ineffectual dropping
in use.
Look under the more tag)
R
Hello,
Various interfaces in the JDK extend Serializable and declare
serialVersionUID fields. Such fields are ineffectual and
@SuppressWarnings("serial") should be applied to such fields to suppress
future planned serial lint checks (JDK-8202056).
Most of the affected files are in the securi
Hi Sean,
On 1/30/2018 10:03 AM, Sean Mullan wrote:
Does Runtime.version().feature() return the same value as the
"java.specification.version" property? (see
sun.security.util.SecurityConstants.PROVIDER_VER).
That is the value that the JDK security providers use as their
version. If not, this
Hello,
The test
java/security/Provider/ProviderVersionCheck.java
has a version-check that is hard coded; therefore, it has to be updated
with each major JDK update. If the test made its check based on the
runtime version, no explicit update would be needed.
Please review the patch below
I understand the interest in having test pass reliably, but I don't
think giving the test very large timeouts is the preferred way of
accomplishing that.
For all configurations, the test can now run for up to 20 minutes, up
from 4 minutes. We want to run the entire test suite, thousands of
te
Looks better; thanks Jon,
-Joe
On 4/26/2017 6:49 PM, Jonathan Gibbons wrote:
Updated webrev to address Joe's suggestion to try harder to use
{@code} as a substitute for .
http://cr.openjdk.java.net/~jjg/8179370/webrev.01
The modified sed script has a new first line:
s|\([^&<>]*\)|{@code \1
question:
-@SuppressWarnings("deprecation")
+@SuppressWarnings({"deprecation",
+ "removal"}) // PolicyTool
Why did you split the line to 2?
Thanks
Max
On 03/28/2017 09:09 AM, joe darcy wrote:
Hello,
The jdk.security and jdk.policytool modules use variou
Hello,
The jdk.security and jdk.policytool modules use various APIs that are
deprecated for removal. Until the types in question are actually
removed, the lint removal warnings should be suppressed in support of
having a warnings-free build. Please review the webrev:
http://cr.openjdk.ja
Looks fine Hamlin; thanks,
-Joe
On 3/7/2017 7:36 PM, Hamlin Li wrote:
Would you please review below patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8176337
webrev: http://cr.openjdk.java.net/~mli/8176337/webrev.00/
These tests are failing intermittently, they should be marked
accordi
Hello,
After the version update to "10" in JDK 10 ( JDK-8029942 ), various
libraries tests failed including:
java/lang/module/MultiReleaseJarTest.java
java/security/Provider/ProviderVersionCheck.java
sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java
These tests need to b
Hello,
Until JDK-8171061 is fixed, the test
sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
should be problem listed on windows.
Patch below.
Thanks,
-Joe
diff -r b9cdffb87bea test/ProblemList.txt
--- a/test/ProblemList.txtWed Dec 07 10:55:13 2016 -0500
+++ b/test/Pro
;t really think this permission target belongs in
RuntimePermission since it is specific to Oracle's Java Plugin. I
would be in favor of removing it and only documenting it in the
deployment guides.
--Sean
On 09/08/2016 02:17 PM, Lance Andersen wrote:
all good Joe
On Sep 8, 2016, a
Hello,
Please review the patch below to address
JDK-8039854: Broken link in java.lang.RuntimePermission
Two broken links are replaced by a live link to the deployment guide.
Thanks,
-Joe
--- a/src/java.base/share/classes/java/lang/RuntimePermission.java Thu
Sep 08 16:16:44 2016 +0100
+
Hello,
The test
java/security/SignedObject/Chain.java
has been seen to fail intermittently (JDK-8136842). I'd like to mark the
test accordingly; please review the test below which does this.
Thanks,
-Joe
--- a/test/java/security/SignedObject/Chain.javaThu Jul 07 10:16:47
2016 -0700
+
The test
javax/net/ssl/TLSv12/ShortRSAKey512.java
has been seen to intermittently fail (JDK-8159501). The test should be
marked accordingly.
Please review the patch below which does this.
Thanks,
-Joe
diff -r d6a1ad87842f test/javax/net/ssl/TLSv12/ShortRSAKey512.java
--- a/test/javax/net/s
Hello,
The test
sun/security/mscapi/ShortRSAKey1024.sh
has been seen to fail with some frequency on windows. Until JDK-8153948
is addressed, the test should be problem listed.
Please review the patch below which does this.
Thanks,
-Joe
diff -r b14b89e259ac test/ProblemList.txt
--- a/test/
he checked exception language contract
Date: Thu, 21 Apr 2016 09:25:27 -0700
From: joe darcy
Organization: Oracle Corporation
To: core-libs-dev
Hello,
After a generally positive reception, please review the webrev to
implement the deprecation of Class.newInstance and the suppression of
the
On 3/30/2016 5:34 PM, Mandy Chung wrote:
On Mar 30, 2016, at 4:48 PM, 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 c
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.
Hello,
The test
sun/security/mscapi/SmallPrimeExponentP.java
has been seen to timeout intermittently, bug JDK-8151834.
The sources of the test should be marked accordingly; please review the
corresponding patch below.
Thanks,
-Joe
--- a/test/sun/security/mscapi/SmallPrimeExponentP.java
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 webr
Hello,
The test
sun/security/mscapi/SignatureOffsets.java
has been observed to intermittently fail (JDK-8134265). Until the root
cause is found, the test should be marked accordingly. Please review the
patch below which does this.
Thanks,
-Joe
diff -r 1c7bad079890 test/sun/security/mscapi
1 - 100 of 435 matches
Mail list logo