On Tue, 2 Nov 2021 19:14:23 GMT, Pavel Rappo wrote:
>> Pragmatically, fix the script to ignore those keywords on comment lines.
>> Learn Perl, its just a regular expression pattern match and replace
>> expression.
>>
>> All of the changes have to be manually reviewed by the author and then th
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 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 to the single line.
>
> This is a survivorship bias. This ex
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 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 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 Tue, 2 Nov 2021 18:48:06 GMT, Mark Sheppard wrote:
>> Here's a bit of archaeology. I found the original JDK-8136583 patch, which
>> has moved from where it was in the RFR to
>> https://cr.openjdk.java.net/~martin/webrevs/jdk9/blessed-modifier-order/.
>> That patch doesn't change Object.java
On Tue, 2 Nov 2021 18:17:36 GMT, Pavel Rappo wrote:
>> It's tough when a natural language clashes with a programming language. I
>> appreciate that this particular clash might cause discomfort to native
>> English speakers. (This reminds me of that _DOSASCOMP_ mnemonic for
>> adjective order.)
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 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 patch.
>
> It's tough when a natural l
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 17:13:47 GMT, Roger Riggs 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 patch.
-
PR: https://git.openjdk.java
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 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 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 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 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
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 Thu, 28 Oct 2021 01:02:27 GMT, Yoshiki Sato wrote:
> Please review the integration of tzdata2021e (including tzdata2021d) to the
> JDK.
> The fix has passed all relevant JTREG regression tests and JCK tests.
>
> 8275754: (tz) Update Timezone Data to 2021d
> 8275849: TestZoneInfo310.java fai
On Tue, 2 Nov 2021 07:31:09 GMT, Stephen Colebourne
wrote:
>> I see what you're saying that an arbitrary `Temporal` could define its own
>> fields with its own ranges, but I would consider it a design bug if such an
>> implementation at a whim redefines the value ranges of well-defined
>> con
> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
> formatters are less efficient for some common patterns than custom formatters
> in apache-commons and log4j. This patch reduces the gap, without having
> looked at the third party implementations.
>
> When printing
On Mon, 1 Nov 2021 15:59:22 GMT, Ludvig Janiuk wrote:
> Adds table headers to all tables in Formatter api docs. I inferred the header
> "Unicode" for the columns that contained unicode
> codepoints.
>
> Formatter api docs:
> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/uti
On Thu, 28 Oct 2021 01:02:27 GMT, Yoshiki Sato wrote:
> Please review the integration of tzdata2021e (including tzdata2021d) to the
> JDK.
> The fix has passed all relevant JTREG regression tests and JCK tests.
>
> 8275754: (tz) Update Timezone Data to 2021d
> 8275849: TestZoneInfo310.java fai
On Mon, 1 Nov 2021 22:35:58 GMT, Claes Redestad wrote:
>> The commentary on this line could probably be improved, but this is in a
>> private printer-parser that will only be used for NANO_OF_SECOND and not any
>> arbitrary `TemporalField` (see line 704), thus I fail to see how this
>> assumpt
25 matches
Mail list logo
