On Fri, 3 Nov 2023 23:22:27 GMT, Claes Redestad wrote:
>> https://github.com/cassioneri/eaf suggest this code for leap year
>> calculation:
>>
>> public static boolean isLeap(long year) {
>> int d = year % 100 != 0 ? 4 : 16;
>> return (year & (d - 1)) == 0;
>> }
>>
>>
On Sat, 4 Nov 2023 16:01:44 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/time/Year.java line 321:
>>
>>> 319: // So for a year that's divisible by 4, checking that it's
>>> also divisible by 16
>>> 320: // is sufficient to determine it must be a leap year.
>>>
On Fri, 3 Nov 2023 23:22:27 GMT, Claes Redestad wrote:
>> https://github.com/cassioneri/eaf suggest this code for leap year
>> calculation:
>>
>> public static boolean isLeap(long year) {
>> int d = year % 100 != 0 ? 4 : 16;
>> return (year & (d - 1)) == 0;
>> }
>>
>>
On Wed, 16 Aug 2023 13:36:38 GMT, Matthias Baesken wrote:
> We run into some BackingStoreException: Couldn't get file lock. e.g. here :
>
> [JShell] Exception in thread "main" java.lang.IllegalStateException:
> java.util.prefs.BackingStoreException: Couldn't get file lock.
> [JShell] at
>
On Sat, 4 Nov 2023 04:57:11 GMT, Quan Anh Mai wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Apply similar optimization to GregorianCalendar, sun.util.calendar
>
>
On Fri, 3 Nov 2023 15:29:25 GMT, Jim Laskey wrote:
>> Update String Templates for a second preview. With the addition of
>>
>> - Expression type and throws are determined from the `process` method of the
>> processor type and not the processor type.
>>
>> - Qualified `STR` and `RAW` are
On Mon, 16 Oct 2023 14:31:46 GMT, Jim Laskey wrote:
> Wasn't sure about that. Thx.
When in doubt, JEP 12. Alex provided good guidance for API authors on how
`@since` should be used with preview APIs.
-
PR Review Comment:
On Mon, 30 Oct 2023 17:26:53 GMT, Yakov Shafranovich wrote:
> The various Zip/Jar-file related Java APIs have some long-standing
> differences or peculiarities with respect to the ZIP-file specification or
> compared to other implementations which should be documented in the API-doc.
> This
