On Fri, 15 Sep 2023 18:06:10 GMT, Pavel Rappo wrote:
>> This modernizes an example to use the extended for-statement introduced in
>> JDK 1.5.
>>
>> I understand that StringTokenizer is a legacy class. But legacy or not, a
>> class shouldn't promote older constructs when newer fit better. Espe
On Fri, 15 Sep 2023 16:20:15 GMT, Naoto Sato wrote:
> No need to create another PR for such changes IMO.
> Although it may be a bit odd to re-use the same variable names for different
> types, I might keep the original `myDate`/`myNumber` that aligns with other
> locations in the class descript
> This modernizes an example to use the extended for-statement introduced in
> JDK 1.5.
>
> I understand that StringTokenizer is a legacy class. But legacy or not, a
> class shouldn't promote older constructs when newer fit better. Especially
> when advising on preferred alternatives to itself.
On Wed, 13 Sep 2023 12:39:00 GMT, Pavel Rappo wrote:
> This modernizes an example to use the extended for-statement introduced in
> JDK 1.5.
>
> I understand that StringTokenizer is a legacy class. But legacy or not, a
> class shouldn't promote older constructs when newer fit better. Especiall
On Wed, 13 Sep 2023 22:55:00 GMT, Naoto Sato wrote:
>> This modernizes an example to use the extended for-statement introduced in
>> JDK 1.5.
>>
>> I understand that StringTokenizer is a legacy class. But legacy or not, a
>> class shouldn't promote older constructs when newer fit better. Espec
On Wed, 13 Sep 2023 12:39:00 GMT, Pavel Rappo wrote:
> This modernizes an example to use the extended for-statement introduced in
> JDK 1.5.
>
> I understand that StringTokenizer is a legacy class. But legacy or not, a
> class shouldn't promote older constructs when newer fit better. Especiall
