On Sun, 15 May 2022 18:36:07 GMT, Joe Darcy wrote:
> Make the javadoc in the InputStream and OutputStream subclasses in core libs
> DRY-er by use of inheritDoc. (Any analagous changes to AudioInputStream in
> client libs will be done another a separate bug.) When the time comes, will
> do any
On Fri, 13 May 2022 21:17:22 GMT, Joe Darcy wrote:
> Update reference to the latest "Effective Java" version and switch to cite
> tags.
Looks good!
1. Had to educate myself on the [cite
element](https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-cite-element).
The HTML
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 a
* 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 IDEs
-
Commit messages:
- Fix misspelled
On Fri, 29 Apr 2022 08:45:42 GMT, Pavel Rappo wrote:
> Good catch. Sorry I missed it. This occurs in all `java/lang/ref` files.
I've created a PR; feel free to review it at your convenience.
-
PR: https://git.openjdk.java.net/jdk/pull/8410
On Thu, 28 Apr 2022 19:06:04 GMT, Mandy Chung wrote:
>> src/java.base/share/classes/java/lang/ref/PhantomReference.java line 48:
>>
>>> 46: * The {@link #refersTo(Object) refersTo} method can be used to test
>>> 47: * whether some object is the referent of a phantom reference.
>>> 48: *
On Fri, 22 Apr 2022 15:08:51 GMT, Magnus Ihse Bursie wrote:
> I ran `codespell` on modules owned by core-libs, and accepted those changes
> where it indeed discovered real typos.
>
> I will update copyright years using a script before pushing (otherwise like
> every second change would be a
On Fri, 22 Apr 2022 15:08:51 GMT, Magnus Ihse Bursie wrote:
> I ran `codespell` on modules owned by core-libs, and accepted those changes
> where it indeed discovered real typos.
>
> I will update copyright years using a script before pushing (otherwise like
> every second change would be a
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 separated
> out in
On Fri, 15 Apr 2022 19:34:33 GMT, Pavel Rappo wrote:
> People rarely include JDK elements with package access in a javadoc run. That
> is why bugs in those elements' doc comments tend to remain unnoticed.
>
> There are many more bugs in the doc comments of the JDK elements with th
People rarely include JDK elements with package access in a javadoc run. That
is why bugs in those elements' doc comments tend to remain unnoticed.
There are many more bugs in the doc comments of the JDK elements with the
package access than are addressed by this PR; I only included the
On Fri, 15 Apr 2022 11:25:09 GMT, Pavel Rappo wrote:
>> I ran `codespell` on the `src/java.base` directory, and accepted those
>> changes where it indeed discovered real typos.
>>
>> (Due to false positives this can unfortunately not be run automatically)
>
On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie wrote:
> I ran `codespell` on the `src/java.base` directory, and accepted those
> changes where it indeed discovered real typos.
>
> (Due to false positives this can unfortunately not be run automatically)
>
> The majority of fixes are in
On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote:
> Use presumed syntax that will be introduced by JDK-8280488.
Is that a wrong bug? If you are talking about module-prefix syntax for links,
then it was introduced in JDK 15; JDK-8164408: Add module support for @see,
@link and @linkplain
On Mon, 24 Jan 2022 11:00:37 GMT, Daniel Fuchs wrote:
> LGTM. I hope in the future IDEs will pick that rule up and offer some help
> when writing `{@link }` `@see`...
They will do it quicker, if you create new or support existing bugs in their
bug trackers.
-
PR:
On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo wrote:
> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead,
> please say so; I will drop those typos from the patch.
> - As
atting artefact and thus can be removed.
> - `` is an apostrophe, which does not require to be encoded.
Pavel Rappo has updated the pull request incrementally with one additional
commit since the last revision:
Additional typos
-
Changes:
- all: https://git.openjdk.java.net/j
On Thu, 13 Jan 2022 11:38:13 GMT, Lance Andersen wrote:
> Yes an "or" is probably worthwhile to add.
I would prefer to leave it for the follow-up cleanup if only because adding
"or" here would make it inconsistent with other `@throws SQLException`
descriptions in that file and perhaps
On Thu, 13 Jan 2022 11:42:48 GMT, Lance Andersen wrote:
> The above is a bit confusing as it reads(same in ImageInputStream.java). I
> think that that can be looked at later.
Just to clarify: you are okay with removing the ` ` entity, right? As for
ImageInputStream, some doc comments should
On Thu, 13 Jan 2022 11:18:42 GMT, Kevin Walls wrote:
>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead,
>> please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in
On Thu, 13 Jan 2022 11:00:55 GMT, Kevin Walls wrote:
>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead,
>> please say so; I will drop those typos from the patch.
>> - As I understand it, in
On Thu, 13 Jan 2022 10:46:11 GMT, Kevin Walls wrote:
>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead,
>> please say so; I will drop those typos from the patch.
>> - As I understand it, in
- Most of the typos are of a trivial kind: missing whitespace.
- If any of the typos should be fixed in the upstream projects instead, please
say so; I will drop those typos from the patch.
- As I understand it, in ImageInputStream and DataInput is an irrelevant
formatting artefact and thus
On Thu, 18 Nov 2021 03:22:50 GMT, Tim Prinzing wrote:
> JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream
Given that this PR affects files that aren't rooted under java/util/stream, I
would either rename the PR or exclude the unrelated files. If this PR is going
to
On Thu, 25 Nov 2021 00:31:46 GMT, Pavel Rappo wrote:
>> JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java
> line 63:
>
>> 61: * Helper class to g
On Thu, 18 Nov 2021 03:22:50 GMT, Tim Prinzing wrote:
> JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream
Looks good.
src/jdk.compiler/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java
line 63:
> 61: * Helper class to generate stable
On Thu, 18 Nov 2021 19:18:24 GMT, Jonathan Gibbons wrote:
> Remarkable to have not been noticed for so long!
Remarkable, but not too surprising: the PR consists of source files and tests
that are not part of the API Documentation.
-
PR: https://git.openjdk.java.net/jdk/pull/6443
On Mon, 27 Sep 2021 11:20:53 GMT, Andrey Turbanov wrote:
> 1. Stream.distinct() is redundant before toSet() collector. Duplicates will
> be collapsed by Collector.
> 2. Stream.sorted() is redundant before toMap() collector. Keys will be
> shuffled by Collector (it's a HashMap in current
On Fri, 5 Nov 2021 12:53:46 GMT, kabutz wrote:
> This is a draft proposal for how we could improve stream performance for the
> case where the streams are empty. Empty collections are common-place. If we
> iterate over them with an Iterator, we would have to create one small
> Iterator object
On Fri, 12 Nov 2021 12:25:20 GMT, Pavel Rappo wrote:
> Please review this simple two-hunk fix to the documentation comment of
> java.util.Properties#load(java.io.Reader). The first hunk (line/lines) is a
> suggestion. I believe it reads better since the plurality is more idiomatic;
Please review this simple two-hunk fix to the documentation comment of
java.util.Properties#load(java.io.Reader). The first hunk (line/lines) is a
suggestion. I believe it reads better since the plurality is more idiomatic;
native English speakers should correct me if I'm wrong. The second hunk
On Thu, 4 Nov 2021 16:07:01 GMT, Naoto Sato wrote:
> This fix is to require to include `Locale.ROOT` in the returned arrays/set
> from `getAvailableLocales()` methods in various locale-sensitive classes. The
> implementation has been including `Locale.ROOT` since its inception, it is
> simply
On Wed, 3 Nov 2021 11:58:42 GMT, Pavel Rappo wrote:
> This PR fixes two sentences which conflate a string with its length, and also
> makes the "equivalency wording" consistent.
>
> There are many ways to fix "the resulting String may be a different length
one of the most
> lightweight ways to do that.
Pavel Rappo has updated the pull request incrementally with one additional
commit since the last revision:
Fix inconsistent formatting
- Removes stray whitespace character *inside* a sentence.
- Makes sentences that introduce tables
On Thu, 4 Nov 2021 11:09:42 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source owned by core-libs. This
> scripts verifies that modifiers are in the "blessed" order, and fixes it
> otherwise. I have manually checked the changes made by the script to make
> sure
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 en
> masse?
>
> As far as I remember, the first mass-canonicalization of
This PR fixes two sentences which conflate a string with its length, and also
makes the "equivalency wording" consistent.
There are many ways to fix "the resulting String may be a different length than
the original String". The proposed way might be one of the most lightweight
ways to do that.
On Tue, 2 Nov 2021 20:34:44 GMT, Martin Buchholz wrote:
>>> Pragmatically, fix the script to ignore those keywords on comment lines.
>>> Learn Perl, its just a regular expression pattern match and replace
>>> expression.
>>
>> I understand in principle how to modify that script to ignore doc
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 en
> masse?
>
> As far as I remember, the first mass-canonicalization of
On Tue, 2 Nov 2021 19:22:15 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/java/lang/invoke/CallSite.java line 88:
>>
>>> 86: */
>>> 87: public
>>> 88: abstract class CallSite {
>>
>> I think it's better to move all modifiers
On Tue, 2 Nov 2021 19:15:26 GMT, Andrey Turbanov 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
On Tue, 2 Nov 2021 18:48:20 GMT, Roger Riggs wrote:
> Pragmatically, fix the script to ignore those keywords on comment lines.
> Learn Perl, its just a regular expression pattern match and replace
> expression.
I understand in principle how to modify that script to ignore doc comments. The
On Tue, 2 Nov 2021 17:45:07 GMT, Pavel Rappo wrote:
>>> In comments, I think the 'synchronized static 'reads better, the
>>> conventional order is for the code.
>>
>> I think Roger is right and maybe the change to the javadoc could be dropped
>> from this
On Tue, 2 Nov 2021 17:39:17 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/lang/Object.java line 282:
>>
>>> 280: * For objects of type {@code Class,} by executing a
>>> 281: * static synchronized method of that class.
>>> 282: *
>>
>> In comments, I think the
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 modif
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
in JDK-8136583 in 2015 [^2]. That change affected 1780 lines
On Mon, 1 Nov 2021 16:51:36 GMT, Pavel Rappo wrote:
>> Please review this PR. A comprehensive test job has been scheduled; I'll
>> notify this thread once that job has completed.
>
> Pavel Rappo has updated the pull request incrementally with one additional
> commit si
On Mon, 1 Nov 2021 15:04:16 GMT, Pavel Rappo wrote:
> Please review this PR. A comprehensive test job has been scheduled; I'll
> notify this thread once that job has completed.
This pull request has now been integrated.
Changeset: 2eafa036
Author: Pavel Rappo
URL:
On Mon, 1 Nov 2021 16:25:26 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/sun/util/resources/LocaleData.java line 248:
>>
>>> 246: private static final LocaleDataStrategy INSTANCE = new
>>> LocaleDataStrategy();
>>> 247: //
> Please review this PR. A comprehensive test job has been scheduled; I'll
> notify this thread once that job has completed.
Pavel Rappo has updated the pull request incrementally with one additional
commit since the last revision:
Use the blessed modifiers order
-
C
On Mon, 1 Nov 2021 15:23:49 GMT, Claes Redestad wrote:
>> Please review this PR. A comprehensive test job has been scheduled; I'll
>> notify this thread once that job has completed.
>
> src/java.base/share/classes/sun/util/resources/LocaleData.java line 248:
>
>> 246: private static
On Mon, 1 Nov 2021 15:52:51 GMT, Daniel Fuchs wrote:
>> Please review this PR. A comprehensive test job has been scheduled; I'll
>> notify this thread once that job has completed.
>
> src/java.base/share/classes/sun/util/resources/LocaleData.java line 336:
>
>> 334: public List
Please review this PR. A comprehensive test job has been scheduled; I'll notify
this thread once that job has completed.
-
Commit messages:
- Fix *code* typo
- Be more immutable
- Fix typos
Changes: https://git.openjdk.java.net/jdk/pull/6191/files
Webrev:
On Fri, 15 Oct 2021 07:17:52 GMT, Сергей Цыпанов wrote:
> It looks like we cannot use `Long.hashCode(long)` for
> `java.rmi.server.ObjID.hashCode()` due to JavaDoc:
> https://docs.oracle.com/en/java/javase/17/docs/api/java.rmi/java/rmi/server/ObjID.html#hashCode().
It's important to be
On Mon, 11 Oct 2021 21:07:21 GMT, Andrey Turbanov wrote:
>> 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8275002: Remove unused
On Mon, 11 Oct 2021 18:52:07 GMT, Andrey Turbanov wrote:
>> 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 275002: Remove unused
On Sat, 9 Oct 2021 17:54:16 GMT, Andrey Turbanov
wrote:
> 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE
Oops. I think we should also do something about this occurrence of
MAX_ARRAY_SIZE:
On Sat, 9 Oct 2021 17:54:16 GMT, Andrey Turbanov
wrote:
> 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE
Marked as reviewed by prappo (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/5878
Empty? As in arrays of length zero?
There ought to be a much better solution. I'm neither an expert nor (sadly) an
active follower of the Valhalla project [1]. Perhaps something there or in
Frozen Arrays [2] will address the runtime cost of creating zero-length arrays
much more elegantly.
[1]
> On 9 Oct 2021, at 13:07, Pavel Rappo wrote:
>
>
>
> Separately, java.lang.AbstractStringBuilder#MAX_ARRAY_SIZE seems unused; I
> wonder how that happened.
I found what happened:
$ git log -S "MAX_ARRAY_SIZE" --
src/java.base/share/classes/java/lang/Abstr
This error has two causes. The first cause is that the VM cannot allocate
arrays whose length exceeds Integer.MAX_VALUE - 8 (MAX_ARRAY_SIZE). The second
cause is that Arrays.deepToString tries to pre-allocate 20 chars per string
representation for each array element and maxes out at
On Thu, 30 Sep 2021 09:36:34 GMT, Ichiroh Takiguchi
wrote:
> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
> After JDK18-b13, javac and some other langtool command's usage were garbled
> on Japanese Windows.
> These commands use PrintWriter instead of standard out/err with PrintStream.
On Mon, 27 Sep 2021 12:04:48 GMT, Pavel Rappo wrote:
> This PR fixes indentation in the examples in the doc comment for
> java.lang.Throwable#printStackTrace().
>
> 1. Indentation in stack-trace output is significant. The cause of an
> exception is output on the same level
This PR fixes indentation in the examples in the doc comment for
java.lang.Throwable#printStackTrace().
1. Indentation in stack-trace output is significant. The cause of an exception
is output on the same level of indentation as that of the exception. A
suppressed exception is output at a
On Tue, 21 Sep 2021 12:26:25 GMT, Pavel Rappo wrote:
> 8274075: Fix miscellaneous typos in java.base
This pull request has now been integrated.
Changeset: 87998565
Author: Pavel Rappo
URL:
https://git.openjdk.java.net/jdk/commit/8799856528f5804b616b734caed3fc4ba9811bfa
Stats:
> 8274075: Fix miscellaneous typos in java.base
Pavel Rappo has updated the pull request incrementally with one additional
commit since the last revision:
Add missing "the"
(Spotted by Brian Burkhalter.)
-
Changes:
- all: https://git.openjdk.java.net/jdk/pu
On Tue, 21 Sep 2021 12:05:27 GMT, Pavel Rappo wrote:
> This PR fixes an inline comment typo and reduces "overlinking" in a doc
> comment in `java.lang.ref.Reference`. Overlinking happens because the
> `reachabilityFence` method:
> * Links `package-summary.html#reachabili
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 paramet
On Wed, 22 Sep 2021 10:24:12 GMT, Pavel Rappo wrote:
>> Note that we don't throw the "wrapped exception" we throw the exception that
>> wraps it. The "wrapped exception" is the original cause. The wording as
>> presented now is correct in that regard. You
> 8274075: Fix miscellaneous typos in java.base
Pavel Rappo has updated the pull request incrementally with two additional
commits since the last revision:
- Fix "non-white space"
JDK predominantly uses "non-whitespace". There's only one more use of
"non-wh
On Tue, 21 Sep 2021 22:00:29 GMT, David Holmes wrote:
>> Instead of "common case where a wrapped exception is thrown from same
>> method" could one write "common case where an enclosing exception is thrown
>> from the same method"?
>
> Note that we don't throw the "wrapped exception" we throw
On Tue, 21 Sep 2021 16:56:03 GMT, Lance Andersen wrote:
>> src/java.base/share/classes/java/lang/Throwable.java line 68:
>>
>>> 66: * Further, doing so would tie the API of the upper layer to the
>>> details of
>>> 67: * its implementation, assuming the lower layer's exception was a
>>>
On Tue, 21 Sep 2021 17:14:31 GMT, Pavel Rappo wrote:
>> Subjectively, "wrapping exception" would seem to be an exception in the
>> process of wrapping something.
>
> Would "wrappER" be better?
We can either revert this part of the change or rephrase it. Mi
On Tue, 21 Sep 2021 17:10:02 GMT, Brian Burkhalter wrote:
>> If we have two exceptions A and B, such that B is the cause of A, then A is
>> the wrapping exception (the one that wraps or the wrapper) and B is the
>> wrapped exception (the one that is being wrapped or the wrappee).
>>
>> I
On Thu, 16 Sep 2021 19:03:26 GMT, Andrey Turbanov
wrote:
> Pass "cause" exception as constructor parameter is shorter and easier to read.
This will need to be thoroughly tested to make sure there were no implicit
dependencies on now-removed happens-before edges (`initCause` is synchronized).
> 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
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/5610/fi
8274075: Fix miscellaneous typos in java.base
-
Commit messages:
- Initial commit
Changes: https://git.openjdk.java.net/jdk/pull/5610/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5610=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8274075
Stats: 21 lines in 8
This PR fixes an inline comment typo and reduces "overlinking" in a doc comment
in `java.lang.ref.Reference`. Overlinking happens because the
`reachabilityFence` method:
* Links `package-summary.html#reachability` twice.
* Refers to JLS 12.6 twice: once from a block tag and once from an inline
On Fri, 10 Sep 2021 21:16:19 GMT, Pavel Rappo wrote:
> 8273616: Fix trivial doc typos in the java.base module
This pull request has now been integrated.
Changeset: b4b12101
Author: Pavel Rappo
URL:
https://git.openjdk.java.net/jdk/commit/b4b121018d16e531f3a51ff75ae37fdc374d5
On Fri, 10 Sep 2021 23:20:11 GMT, Pavel Rappo wrote:
>> 8273616: Fix trivial doc typos in the java.base module
>
> Pavel Rappo has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Revert two fixes
Thanks to those who revi
> 8273616: Fix trivial doc typos in the java.base module
Pavel Rappo has updated the pull request incrementally with one additional
commit since the last revision:
Use "ensure" instead of "insure"
-
Changes:
- all: https://git.openjdk.java.net/jdk/
> 8273616: Fix trivial doc typos in the java.base module
Pavel Rappo has updated the pull request incrementally with one additional
commit since the last revision:
Revert two fixes
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/5475/files
- new: ht
On Fri, 10 Sep 2021 21:52:36 GMT, John R Rose wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Revert two fixes
>
> src/java.base/share/classes/java/nio/channels/FileCh
8273616: Fix trivial doc typos in the java.base module
-
Commit messages:
- Initial commit
Changes: https://git.openjdk.java.net/jdk/pull/5475/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5475=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8273616
Stats: 55
Has that method been ever used? If nothing else its name seems strange. To me,
a union has OR semantics, not AND.
> On 27 Aug 2021, at 15:37, Andrey Turbanov wrote:
>
> Hello.
> I found suspicious code in the method
>
.
* The following are helper methods that the native launcher uses
* to perform checks etc. using JNI, see src/share/bin/java.c
*/
import java.io.File;
In no context can an import statement be documented.
-Pavel
> On 24 Aug 2021, at 16:07, Pavel Rappo wrote:
>
>> On 24 Aug
> On 24 Aug 2021, at 15:38, Jonathan Gibbons
> wrote:
>
> IIRC, the one in javadoc CommentUtils has recently been fixed.
>
> It might be worth a javac -Xlint option to detect/report such dangling
> comments.
How would you currently implement that? Aren't comments on non-documentable
On Fri, 20 Aug 2021 16:49:15 GMT, Pavel Rappo wrote:
>> Ian Graves has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> some quick fixes
>
> test/jdk/java/util/regex/RegExTest.java line 4270:
>
>> 42
On Fri, 20 Aug 2021 16:27:53 GMT, Ian Graves wrote:
>> 8271302: Regex Test Refresh
>
> Ian Graves has updated the pull request incrementally with one additional
> commit since the last revision:
>
> some quick fixes
test/jdk/java/util/regex/RegExTest.java line 4270:
> 4268:
On Fri, 20 Aug 2021 13:46:39 GMT, Pavel Rappo wrote:
>> Ian Graves has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Couple of fixes
>
> test/jdk/java/util/regex/NegativeArraySize.java line 40:
>
>>
On Wed, 18 Aug 2021 18:35:53 GMT, Ian Graves wrote:
>> 8271302: Regex Test Refresh
>
> Ian Graves has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Couple of fixes
test/jdk/java/util/regex/NegativeArraySize.java line 2:
> 1: /*
> 2: *
On Mon, 26 Jul 2021 20:54:53 GMT, Ian Graves wrote:
>> Fixes a bug where carets aren't indented correctly in PatternSyntaxException
>> messages because tab characters are converted to spaces in their indentation.
>
> Ian Graves has updated the pull request incrementally with one additional
>
On Mon, 26 Jul 2021 18:10:03 GMT, Ian Graves wrote:
> Fixes a bug where carets aren't indented correctly in PatternSyntaxException
> messages because tab characters are converted to spaces in their indentation.
Changes requested by prappo (Reviewer).
On Tue, 2 Mar 2021 18:07:24 GMT, Stuart Marks wrote:
>> test/jdk/jdk/internal/util/ArraysSupport/NewLength.java line 100:
>>
>>> 98: int r = ArraysSupport.newLength(old, min, pref);
>>> 99: fail("expected OutOfMemoryError, got normal return value of
>>> " + r);
>>> 100:
On Mon, 28 Jun 2021 20:50:42 GMT, Ian Graves wrote:
> 8199594: Add doc describing how (?x) ignores spaces in character classes
src/java.base/share/classes/java/util/regex/Pattern.java line 833:
> 831: * Comments mode can also be enabled via the embedded flag
> 832: *
On Wed, 30 Jun 2021 21:38:43 GMT, Naoto Sato wrote:
> A trivial typo fix.
Marked as reviewed by prappo (Reviewer).
-
PR: https://git.openjdk.java.net/jdk17/pull/187
On Wed, 16 Jun 2021 09:57:29 GMT, Julia Boes wrote:
> In the methods in question, `RejectedExecutionException` is an expected
> exception that was previously unhandled (it is a `RuntimeException`, not a
> subclass of `ExecutionException`). This change adds
> `RejectedExecutionException` to
On Tue, 15 Jun 2021 18:05:18 GMT, Joe Darcy wrote:
> The javadoc of AutoCloseable.close is from JDK 7 and thus predates tags like
> @apiNote. However, some of the discussion contained in AutoCloseable.close is
> more appropriate as an apiNote that normal text.
I'm confused: I thought that
I have created a JBS issue: https://bugs.openjdk.java.net/browse/JDK-8268077
> On 1 Jun 2021, at 18:56, Raffaello Giulietti
> wrote:
>
> Hi,
>
> can anybody take a look at this?
> I would do it myself but I don't have Author status to add an issue to the
> JBS.
>
> Should be a trivial
On Mon, 10 May 2021 06:34:36 GMT, Vyom Tewari wrote:
> this change will include the below headers files to Linux only.
> #include
> #include
The fix to 8266610 caused a build failure on macOS. What is your plan to make
sure this won't happen with this change?
I would recommend enabling
1 - 100 of 416 matches
Mail list logo
