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 `@para
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: * @para
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 an
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 c
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 I understan
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
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 elsewher
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 pr
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 ImageInputSt
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 ImageInputStre
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 ImageInputStre
- 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 can
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 Wed, 3 Nov 2021 10:11:31 GMT, Daniel Fuchs wrote:
> Hi,
>
> Please find here a trivial cleanup change that updates classes in the
> `java.net.http` module to use the "blessed modifier order".
>
> The changeset was obtained by running `sh ./bin/blessed-modifier-order.sh
> src/java.net.http
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 c
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 t
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 to
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
th
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
>>
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 spa
On Wed, 6 Oct 2021 16:00:41 GMT, Bradford Wetmore wrote:
>> 8274809: Update java.base classes to use try-with-resources
>
> src/java.base/share/classes/sun/security/timestamp/HttpTimestamper.java line
> 127:
>
>> 125: // Receive the reply
>> 126: byte[] replyBuffer = null;
>> 12
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
> 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
"n
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
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.
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 t
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 notic
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
>>> chec
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&pr=5610&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8274075
Stats: 21 line
those changes, you may want to ask ICU4J [^1] folk to
incorporate them. If they agree, one day those changes may show up in the
OpenJDK.
--
[^1]: https://github.com/unicode-org/icu/tree/master/icu4j
> On 15 Apr 2020, at 12:06, Pavel Rappo wrote:
>
> Vipin,
>
> I saw that
Here's the cumulative webrev:
http://cr.openjdk.java.net/~prappo/8242366/webrev.01/
-Pavel
> On 11 Apr 2020, at 20:23, Vipin Sharma wrote:
>
> Hi Pavel,
>
>> On Apr 9, 2020, at 2:45 AM, Pavel Rappo wrote:
>>
>> If your new patch addresses a similar ty
If your new patch addresses a similar type of problem, please send it in reply
to this email,
so that I could merge it with the existing patch. Let's try to minimize process
overhead if possible.
> On 8 Apr 2020, at 17:35, Vipin Sharma wrote:
>
>
>
>> On Apr 8, 2020,
Why assume something that sophisticated where it can be adequately explained by
a simpler thing? :) I bet it was an IDE inspection.
-Pavel
> On 8 Apr 2020, at 14:14, Alan Bateman wrote:
>
> On 08/04/2020 14:07, Daniel Fuchs wrote:
>> Hi Pavel,
>>
>> On 08/04/2020 13:56, David Holmes wrote:
>>>
prone that can be, I still wouldn't do it in this changeset.
-Pavel
> On 8 Apr 2020, at 13:56, David Holmes wrote:
>
> Hi Pavel,
>
> Not a review ...
>
> On 8/04/2020 9:50 pm, Pavel Rappo wrote:
>> Vipin, here you go:
>> https://bugs.open
t.
-Pavel
> On 7 Apr 2020, at 19:50, Vipin Sharma wrote:
>
> Hi Pavel,
>
>> On Apr 7, 2020, at 11:11 PM, Pavel Rappo wrote:
>>
>> I assume you have signed the OCA [1]. If not and you want to continue,
>> please do it. If you've already done so, whi
>>
>> The former is easier just delete the ’s’.
>>
>> Other bits look good.
>>
>> Paul.
>>
>>> On Mar 13, 2020, at 7:03 PM, Ivan Gerasimov
>>> wrote:
>>>
>>> Hi Pavel!
>>>
>>> Can this please be combi
java.net/~igerasim/XXX-typos/00/webrev/
>
> Just to save cycles on reviewing :)
>
> With kind regards,
>
> Ivan
>
>
> On 3/13/20 8:42 AM, Pavel Rappo wrote:
>> Hello,
>>
>> Please review the change for
>> https://bugs.openjdk.java.net/brow
Hello,
Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014:
http://cr.openjdk.java.net/~prappo/8241014/webrev.00/
This is a documentation cleanup. There are no code changes involved,
and the changes in documentation are mostly trivial.
The following packages are affe
Looks good to me.
-Pavel
> On 25 Nov 2014, at 14:03, Mark Sheppard wrote:
>
> I think this raises a more fundamental question, as to why the URL
> hashCode() and equals() methods delegates to URLStreamHandler
> in the first place? rather than performing the processing within the URL
> class itself, and synchroniz
Peter, thanks a lot for the link and such a detailed explanation. I've been
working with URL/URLStreamHandler recently to make them "modularization ready"
and have noticed some of the problems you were talking about as well. I do
think we should make our best effort to fix it. Give me some time
s hard to imagine the opposite).
-Pavel
> On 25 Nov 2014, at 12:58, Wang Weijun wrote:
>
>
>> On Nov 25, 2014, at 20:25, Pavel Rappo wrote:
>>
>> Hi Max,
>>
>> I don't see any particular reason for this. Maybe it's just a "precaution"
Hi Max,
I don't see any particular reason for this. Maybe it's just a "precaution". It
seems to me it's the only field
of the URL class set directly (without setter) from an outside.
Does it hurt performance a lot? In what cases?
-Pavel
> On 25 Nov 2014, at 12:02, Wang Weijun wrote:
>
> I am
It's exactly the way it's been working since 1.6 I believe.
public class Optimization {
public String concat(String... strings) {
return "#: " + strings[0] + strings[2] + strings[3] + "...";
}
}
public class Optimization {
public Optimization();
Code:
0: aload_0
Otavio,
Just skimmed through your changes. It looks good. But there are some things we
can make a little bit better though. IMO, it's not always a performance that
matters (looking around to see if Alexey Shipilev is somewhere near) but
readability. It's good to estimate performance requirement
> In the class
> src/share/classes/javax/management/openmbean/CompositeType.java you have
> added the
> annotation @SuppressWarnings("StringConcatenationInsideStringBufferAppend")
> instead of fixing the concatenation inside the append method. Why?
+1 Moreover, I wonder where this value comes from
56 matches
Mail list logo
