On Tue, 30 Aug 2022 00:04:03 GMT, Joe Darcy wrote:
> Update to remove support for -source/-target/--release 7 from javac.
>
> As seen in the PR, many test fails are affected. Further refactorings of
> javac's implementation that can be made from dropping 7 support are left as
> future work.
t
On Tue, 30 Aug 2022 00:16:09 GMT, Joe Darcy wrote:
> Please also review the accompanying CSR:
>
> https://bugs.openjdk.org/browse/JDK-8293047
>
> Note that the DEFAULT_METHODS enum constant is used indirectly by a test to
> force a class file's minor version bits to be set as if a preview feat
On Tue, 30 Aug 2022 00:04:03 GMT, Joe Darcy wrote:
> Update to remove support for -source/-target/--release 7 from javac.
>
> As seen in the PR, many test fails are affected. Further refactorings of
> javac's implementation that can be made from dropping 7 support are left as
> future work.
P
Update to remove support for -source/-target/--release 7 from javac.
As seen in the PR, many test fails are affected. Further refactorings of
javac's implementation that can be made from dropping 7 support are left as
future work.
-
Commit messages:
- Small refactoring to remove m
On Fri, 22 Jul 2022 21:53:35 GMT, Naoto Sato wrote:
> This PR is to propose supporting the `T` extension to the BCP 47 to which
> `java.util.Locale` class conforms. There are two extensions to the BCP 47,
> one is `Unicode Locale Extension` which has been supported since JDK7, the
> other is t
On Mon, 29 Aug 2022 11:58:15 GMT, Volker Simonis wrote:
>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)`
>> to highlight that it might write more bytes than the returned number of
>> inflated bytes into the buffer `b`.
>>
>> The superclass `java.io.InputStream` sp
On Mon, 29 Aug 2022 17:14:41 GMT, Daniel Fuchs wrote:
>> CleanerTest is failing intermittently on Aarch64, with -Xcomp, and using a
>> VirtualThread for the Cleaner in the test.
>> The extensively relies on references processing and invokes GC on a very
>> short cycle.
>> The existing 10ms dela
On Fri, 26 Aug 2022 19:09:45 GMT, Roger Riggs wrote:
> CleanerTest is failing intermittently on Aarch64, with -Xcomp, and using a
> VirtualThread for the Cleaner in the test.
> The extensively relies on references processing and invokes GC on a very
> short cycle.
> The existing 10ms delay betw
On Wed, 24 Aug 2022 19:31:23 GMT, Andrey Turbanov wrote:
> Couple of package-private classes in `java.text` package still use
> `StringBuffer`: `MergeCollation` and `PatternEntry`.
> StringBuffer is a legacy synchronized class. StringBuilder is a direct
> replacement to StringBuffer which gener
On Wed, 24 Aug 2022 19:22:51 GMT, Andrey Turbanov wrote:
> Field `java.text.DateFormatSymbols#millisPerHour` is unused. It was unused in
> initial OpenJDK sources.
This looks good too.
-
Marked as reviewed by naoto (Reviewer).
PR: https://git.openjdk.org/jdk/pull/10005
On Wed, 24 Aug 2022 19:31:23 GMT, Andrey Turbanov wrote:
> Couple of package-private classes in `java.text` package still use
> `StringBuffer`: `MergeCollation` and `PatternEntry`.
> StringBuffer is a legacy synchronized class. StringBuilder is a direct
> replacement to StringBuffer which gener
On Wed, 24 Aug 2022 19:31:23 GMT, Andrey Turbanov wrote:
> Couple of package-private classes in `java.text` package still use
> `StringBuffer`: `MergeCollation` and `PatternEntry`.
> StringBuffer is a legacy synchronized class. StringBuilder is a direct
> replacement to StringBuffer which gener
Well, yes, this is a solvable problem, albeit with additional copying, but
solvable, which cannot be said about other operations (for example, swap),
I lead to the fact that there are few specialized methods in COW that can
work inside synchronization and cannot be synchronized with by the
COWArray
> Add support for named groups to java.util.regex.MatchResult
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
8065554: MatchResult should provide values of named-capturing groups
-
Changes:
- all: https://git.op
On Mon, 29 Aug 2022 09:33:44 GMT, Сергей Цыпанов wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Touchups
>
> src/java.base/share/classes/jdk/internal/module/ModuleHashes.java line 170:
>
>> 168: static Mo
> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to
> highlight that it might write more bytes than the returned number of
> inflated bytes into the buffer `b`.
>
> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off,
> int len)` will leave t
On Mon, 29 Aug 2022 10:50:03 GMT, Aleksey Shipilev wrote:
> I would be very surprised if we actually verified the module hashes at
> startup! That would take minutes to startup on Zero, as observed by its
> build-time checking. And we don't see that, apparently.
Module hashes are checked at st
On Mon, 29 Aug 2022 09:18:16 GMT, Alan Bateman wrote:
> This issue will require discussion as it potentially impacts usage at
> run-time when the resolver runs at startup or when creating module layers.
Startup with/without CDS:
$ perf stat -r 100 build/linux-x86_64-server-release/images/jdk
> `jmod`/`jlink` are executed during build time to produce the `jmod` and the
> base modules image. On slow hardware (Raspberry Pi -class, for example)
> and/or slow VMs (debug, interpreter-only, for example) this takes a while.
> Profiling shows the considerable time is spent on hashing modules
On Mon, 29 Aug 2022 08:55:06 GMT, Aleksey Shipilev wrote:
> `jmod`/`jlink` are executed during build time to produce the `jmod` and the
> base modules image. On slow hardware (Raspberry Pi -class, for example)
> and/or slow VMs (debug, interpreter-only, for example) this takes a while.
> Profi
On Mon, 29 Aug 2022 08:55:06 GMT, Aleksey Shipilev wrote:
> `jmod`/`jlink` are executed during build time to produce the `jmod` and the
> base modules image. On slow hardware (Raspberry Pi -class, for example)
> and/or slow VMs (debug, interpreter-only, for example) this takes a while.
> Profi
`jmod`/`jlink` are executed during build time to produce the `jmod` and the
base modules image. On slow hardware (Raspberry Pi -class, for example) and/or
slow VMs (debug, interpreter-only, for example) this takes a while. Profiling
shows the considerable time is spent on hashing modules either
> I found out that reading from `DataInputStream` wrapping
> `ByteArrayInputStream` (as well as `BufferedInputStream` or any `InputStream`
> relying on `byte[]`) can be significantly improved by accessing volatile `in`
> field only once per operation.
>
> Current implementation does it for each
On Sun, 28 Aug 2022 22:20:03 GMT, David Holmes wrote:
>> src/java.base/share/classes/java/lang/Thread.java line 70:
>>
>>> 68: * The newly started thread invokes the task's {@link Runnable#run()
>>> run} method.
>>> 69: *
>>> 70: * A platform thread terminates if either its {@code run}
>>>
On Sat, 27 Aug 2022 06:52:19 GMT, Alan Bateman wrote:
>> Сергей Цыпанов has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - 8292937: Fix error C2057
>> - 8292937: Remove unused method
>
> src/java.base/share/native/libjava/io_util.c line
25 matches
Mail list logo
