> Fixing tests that fail at DST->STD offset transition. Simply skipping the
> tests on that occasion.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Changed to not skipping the test in DateFormatTest.java
-
Changes:
-
On Mon, 29 Nov 2021 21:09:47 GMT, Lance Andersen wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Changed to not skipping the test in DateFormatTest.java
>
> test/jdk/java/text/Format/DateFormat/DateFormatTest.java li
> Sorting:
>
> - adopt radix sort for sequential and parallel sorts on int/long/float/double
> arrays (almost random and length > 6K)
> - fix tryMergeRuns() to better handle case when the last run is a single
> element
> - minor javadoc and comment changes
>
> Testing:
> - add new data inputs i
On Mon, 29 Nov 2021 18:48:45 GMT, Naoto Sato wrote:
> Fixing tests that fail at DST->STD offset transition. Simply skipping the
> tests on that occasion.
test/jdk/java/text/Format/DateFormat/DateFormatTest.java line 349:
> 347: var defZone = ZoneId.systemDefault();
> 348: if
>
On Mon, 29 Nov 2021 18:48:45 GMT, Naoto Sato wrote:
> Fixing tests that fail at DST->STD offset transition. Simply skipping the
> tests on that occasion.
Marked as reviewed by joehw (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/6598
On Mon, 29 Nov 2021 18:48:45 GMT, Naoto Sato wrote:
> Fixing tests that fail at DST->STD offset transition. Simply skipping the
> tests on that occasion.
Marked as reviewed by rriggs (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/6598
Adding test group for IPv6 exclusive testing.
-
Commit messages:
- 8277957: add IPv6 test group
Changes: https://git.openjdk.java.net/jdk/pull/6600/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6600&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8277957
On Mon, 29 Nov 2021 18:38:35 GMT, Joe Darcy wrote:
>> The time to get JDK 19 underway draws nigh, please review this usual set of
>> start-of-release updates, including CSRs for the javac and javax.lang.model
>> updates:
>>
>> JDK-8277512: Add SourceVersion.RELEASE_19
>> https://bugs.openjdk.j
Given an API-change is not realistic at this point in jdk-18, would it
make more sense to implement solution (1), and consider (2) for jdk-19+.. ?
On Mon, 29 Nov 2021 17:07:52 GMT, Alan Bateman wrote:
>> @andrew-m-leonard I see you've add several APIs to ZipEntry in this PR. I
>> think this part will require discussion as it's not immediately clear that
>> we should over burden the ZipEntry API as proposed.
>
>> @AlanBateman yes, see abov
*Problem:*
PR https://github.com/openjdk/jdk/pull/6481
addresses the main problems with deterministic timestamping of Zip entries,
with
the introduction of a new --date option for jar & jmod.
However, the ZipEntry timestamp is constructed from a combination of an
MS-DOS timestamp
and a FileTime(se
> On Nov 29, 2021, at 10:42 AM, Simon Roberts
> wrote:
>
> I will say that as Java provides more and more features modeled on more
> functional languages, I'm finding more and more people struggling with the
> inherently mutable nature of Java, and that I strongly believe that
> something that
On Wed, 24 Nov 2021 12:32:32 GMT, Michael Hall wrote:
> Would there be any need to scan class path at all? That would mean a module
> would have a class path dependency wouldn't it?
One reason of scanning the class path is to detect any split packages and emit
warnings.
> Yes, I shouldn't
On Mon, 29 Nov 2021 17:07:52 GMT, Alan Bateman wrote:
> > @AlanBateman yes, see above comment, thanks
>
> This is a significant change to the ZipEntry API that will require discussion
> and agreement. Can you start a discussion on core-libs-dev about the topic?
> You could start with a summary
On Mon, 29 Nov 2021 18:32:30 GMT, Maurizio Cimadamore
wrote:
>> Following integration of the second incubator of the foreign function and
>> memory API [1], we detected few divergences between the contents of the jdk
>> repo and the panama repo:
>>
>> * the name of some of the `FunctionDescri
Fixing tests that fail at DST->STD offset transition. Simply skipping the tests
on that occasion.
-
Commit messages:
- 8190748: java/text/Format/DateFormat/DateFormatTest.java and
NonGregorianFormatTest fail intermittently
Changes: https://git.openjdk.java.net/jdk/pull/6598/files
I will say that as Java provides more and more features modeled on more
functional languages, I'm finding more and more people struggling with the
inherently mutable nature of Java, and that I strongly believe that
something that helps bridge the gap is likely to be crucial to the
language's contin
> The time to get JDK 19 underway draws nigh, please review this usual set of
> start-of-release updates, including CSRs for the javac and javax.lang.model
> updates:
>
> JDK-8277512: Add SourceVersion.RELEASE_19
> https://bugs.openjdk.java.net/browse/JDK-8277512
>
> JDK-8277514: Add source 19
> Following integration of the second incubator of the foreign function and
> memory API [1], we detected few divergences between the contents of the jdk
> repo and the panama repo:
>
> * the name of some of the `FunctionDescriptor` wither methods is different
> (e.g. `withAppendedLayoutArgumen
On Mon, 29 Nov 2021 13:26:11 GMT, Jorn Vernee wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update
>> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java
>>
>> Co-authored-
On Mon, 29 Nov 2021 11:22:45 GMT, Maurizio Cimadamore
wrote:
> Following integration of the second incubator of the foreign function and
> memory API [1], we detected few divergences between the contents of the jdk
> repo and the panama repo:
>
> * the name of some of the `FunctionDescriptor`
On Mon, 29 Nov 2021 11:22:45 GMT, Maurizio Cimadamore
wrote:
> Following integration of the second incubator of the foreign function and
> memory API [1], we detected few divergences between the contents of the jdk
> repo and the panama repo:
>
> * the name of some of the `FunctionDescriptor`
Following integration of the second incubator of the foreign function and
memory API [1], we detected few divergences between the contents of the jdk
repo and the panama repo:
* the name of some of the `FunctionDescriptor` wither methods is different
(e.g. `withAppendedLayoutArguments` vs. `app
I have created myself a project with a possible implementation of Immutable
Collections using the source code of Java 17.
https://github.com/Aliuken/JavaImmutableCollections
[https://opengraph.githubassets.com/b1aeb5022614cc86e9ca7b0effe8a6298ce1ba62fee0b97021af3ff40e505cea/Aliuken/JavaImmutableC
On Thu, 25 Nov 2021 08:26:56 GMT, Stephen Colebourne
wrote:
>> Naoto Sato has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Replaced integer literals.
>> - Refined wording #2
>
> src/java.base/share/classes/java/time/format/DateTimeFor
> This fix intends to honor the type (std/dst/generic) of parsed zone name for
> selecting the offset at the overlap. Corresponding CSR has also been drafted.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Refined wording. Removed `LE
On Mon, 29 Nov 2021 16:22:30 GMT, Andrew Leonard wrote:
>> Add a new --source-date (epoch seconds) option to jar and jmod
>> to allow specification of time to use for created/updated jar/jmod entries.
>> This then allows the ability to make the content deterministic.
>>
>> Signed-off-by: Andr
On Mon, 29 Nov 2021 16:18:44 GMT, Alan Bateman wrote:
>> Andrew Leonard has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>>Signed-off-by: Andrew Leonar
On Mon, 29 Nov 2021 16:18:44 GMT, Alan Bateman wrote:
>> Andrew Leonard has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>
>>Signed-off-by: Andrew Leonar
On Thu, 25 Nov 2021 19:21:36 GMT, John Neffenger wrote:
>>> A user who’s not familiar with the lingo of [reproducible
>>> builds](https://reproducible-builds.org/docs/source-date-epoch/) will be
>>> mystified by an option named `--source-date`. A user who just wants to set
>>> the timestamp of
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated the pull request increm
On Mon, 29 Nov 2021 16:19:01 GMT, Andrew Leonard wrote:
>> Add a new --source-date (epoch seconds) option to jar and jmod
>> to allow specification of time to use for created/updated jar/jmod entries.
>> This then allows the ability to make the content deterministic.
>>
>> Signed-off-by: Andr
On Fri, 26 Nov 2021 16:24:31 GMT, Lance Andersen wrote:
>> @LanceAndersen java File times can't be before the epoch, but having a test
>> before dostime 1980 would be useful
>
>>
>
> The change to sun/tools/jar/GNUStyleOptions.java does not prevent a negative
> value which can be set via ZipE
On Fri, 26 Nov 2021 16:25:43 GMT, Lance Andersen wrote:
>> For files with large number of entries, alot of LocalDateTime Objects are
>> being created here. Would there be an efficiency gain by converting
>> sourceDate variable to be of type LocalDateTime and simply pass it to the
>> s.setTimeL
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated the pull request increm
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated the pull request with a
On Mon, 15 Nov 2021 21:35:06 GMT, Roman Kennke wrote:
>> The caches in ObjectStreamClass basically map WeakReference to
>> SoftReference, where the ObjectStreamClass also
>> references the same Class. That means that the cache entry, and thus the
>> class and its class-loader, will not get rec
On Mon, 29 Nov 2021 13:47:19 GMT, Roman Kennke wrote:
> I don't quite understand this: If the Class object is still reachable by the
> app,
1. a weak reference would not get cleared and
2. the Class's ClassLoader would not get unloaded.
...but the ObjectStreamClass instance could still get GC-
On Mon, 15 Nov 2021 21:35:06 GMT, Roman Kennke wrote:
>> The caches in ObjectStreamClass basically map WeakReference to
>> SoftReference, where the ObjectStreamClass also
>> references the same Class. That means that the cache entry, and thus the
>> class and its class-loader, will not get rec
On Mon, 15 Nov 2021 19:10:17 GMT, Roman Kennke wrote:
> > If the intent of this change is to alter the lifetimes of the objects in
> > question in a meaningful way, I recommend a CSR for the behavioral
> > compatibility impact.
>
> It would be hard for application code to observe this change:
On Mon, 15 Nov 2021 21:35:06 GMT, Roman Kennke wrote:
>> The caches in ObjectStreamClass basically map WeakReference to
>> SoftReference, where the ObjectStreamClass also
>> references the same Class. That means that the cache entry, and thus the
>> class and its class-loader, will not get rec
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated the pull request increm
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated the pull request increm
On Sat, 20 Nov 2021 10:08:41 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to fix the issue
> reported in https://bugs.openjdk.java.net/browse/JDK-8003417?
>
> The issue notes that this is applicable for `WeakHashMap` which have `null`
> keys. However, the
> Instead of something like
>
> long x;
> long y;
> return (x < y) ? -1 : ((x == y) ? 0 : 1);
>
> we can use `return Long.compare(x, y);`
>
> All replacements are done with IDE.
Сергей Цыпанов has updated the pull request incrementally with one additional
commit since the last revision:
827
On Sat, 27 Nov 2021 22:50:55 GMT, Michael Bien wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8277868: Use Integer.signum() in BasicTableUI
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.
46 matches
Mail list logo
