On Wed, 10 Jan 2024 18:27:45 GMT, Pavel Rappo wrote:
> > /contributor add @pavelrappo
>
> Thanks, Joe. Making me an "overriding author" was a bit over the top. :)
Skimmed the docs too quickly when looking for a "co-author" command :-)
-
PR Comment: https://git.openjdk.org/jdk/pull
On Wed, 10 Jan 2024 18:16:05 GMT, Joe Darcy wrote:
>> As recently discussed on core libs, sealed-ness information could be
>> included in the Class.toGenericString() output, analagous to how "modifiers"
>> that also correspond to JVM access flags are handled.
>>
>> This is the initial spec, im
On Wed, 10 Jan 2024 18:16:05 GMT, Joe Darcy wrote:
>> As recently discussed on core libs, sealed-ness information could be
>> included in the Class.toGenericString() output, analagous to how "modifiers"
>> that also correspond to JVM access flags are handled.
>>
>> This is the initial spec, im
> As recently discussed on core libs, sealed-ness information could be included
> in the Class.toGenericString() output, analagous to how "modifiers" that also
> correspond to JVM access flags are handled.
>
> This is the initial spec, implementation, and test updated needed for that
> change.
> As recently discussed on core libs, sealed-ness information could be included
> in the Class.toGenericString() output, analagous to how "modifiers" that also
> correspond to JVM access flags are handled.
>
> This is the initial spec, implementation, and test updated needed for that
> change.
On Tue, 9 Jan 2024 19:37:54 GMT, Joe Darcy wrote:
>> As recently discussed on core libs, sealed-ness information could be
>> included in the Class.toGenericString() output, analagous to how "modifiers"
>> that also correspond to JVM access flags are handled.
>>
>> This is the initial spec, imp
> As recently discussed on core libs, sealed-ness information could be included
> in the Class.toGenericString() output, analagous to how "modifiers" that also
> correspond to JVM access flags are handled.
>
> This is the initial spec, implementation, and test updated needed for that
> change.
On Mon, 8 Jan 2024 22:29:47 GMT, Joe Darcy wrote:
>>> Since it doesn't seem possible to do so, I did not attempt to relay
>>> "non-sealed" information in this PR :-)
>>
>> Naively, I thought that something like this is possible _in principle_; I
>> might be mistaken though:
>>
>> diff --git a
> As recently discussed on core libs, sealed-ness information could be included
> in the Class.toGenericString() output, analagous to how "modifiers" that also
> correspond to JVM access flags are handled.
>
> This is the initial spec, implementation, and test updated needed for that
> change.
> As recently discussed on core libs, sealed-ness information could be included
> in the Class.toGenericString() output, analagous to how "modifiers" that also
> correspond to JVM access flags are handled.
>
> This is the initial spec, implementation, and test updated needed for that
> change.
> As recently discussed on core libs, sealed-ness information could be included
> in the Class.toGenericString() output, analagous to how "modifiers" that also
> correspond to JVM access flags are handled.
>
> This is the initial spec, implementation, and test updated needed for that
> change.
On Wed, 3 Jan 2024 19:44:51 GMT, Pavel Rappo wrote:
>> I think the best place, or least-bad place, to discuss the "modifier"
>> ordering of sealed/non-sealed would be an informative note on
>> Modifier.toString(int) -- "The sealed/non-sealed Java language modifiers are
>> not represented in th
On Wed, 3 Jan 2024 22:20:15 GMT, Joe Darcy wrote:
>>> Since it doesn't seem possible to do so, I did not attempt to relay
>>> "non-sealed" information in this PR :-)
>>
>> Naively, I thought that something like this is possible _in principle_; I
>> might be mistaken though:
>>
>> diff --git a
On Wed, 3 Jan 2024 19:44:51 GMT, Pavel Rappo wrote:
>> I think the best place, or least-bad place, to discuss the "modifier"
>> ordering of sealed/non-sealed would be an informative note on
>> Modifier.toString(int) -- "The sealed/non-sealed Java language modifiers are
>> not represented in th
On Wed, 3 Jan 2024 18:16:24 GMT, Joe Darcy wrote:
> Since it doesn't seem possible to do so, I did not attempt to relay
> "non-sealed" information in this PR :-)
Naively, I thought that something like this is possible _in principle_; I might
be mistaken though:
diff --git a/src/java.base/shar
On Wed, 3 Jan 2024 06:43:22 GMT, Joe Darcy wrote:
> As recently discussed on core libs, sealed-ness information could be included
> in the Class.toGenericString() output, analagous to how "modifiers" that also
> correspond to JVM access flags are handled.
>
> This is the initial spec, implemen
On Wed, 3 Jan 2024 16:40:32 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/java/lang/Class.java line 264:
>>
>>> 262: /**
>>> 263: * Returns a string describing this {@code Class}, including
>>> 264: * information about modifiers, {@linkplain #isSealed() sealing},
>>> and
On Wed, 3 Jan 2024 14:52:48 GMT, Roger Riggs wrote:
>> As recently discussed on core libs, sealed-ness information could be
>> included in the Class.toGenericString() output, analagous to how "modifiers"
>> that also correspond to JVM access flags are handled.
>>
>> This is the initial spec, i
On Wed, 3 Jan 2024 14:59:33 GMT, Roger Riggs wrote:
>> As recently discussed on core libs, sealed-ness information could be
>> included in the Class.toGenericString() output, analagous to how "modifiers"
>> that also correspond to JVM access flags are handled.
>>
>> This is the initial spec, i
On Wed, 3 Jan 2024 06:43:22 GMT, Joe Darcy wrote:
> As recently discussed on core libs, sealed-ness information could be included
> in the Class.toGenericString() output, analagous to how "modifiers" that also
> correspond to JVM access flags are handled.
>
> This is the initial spec, implemen
20 matches
Mail list logo
