On Fri, 9 Aug 2024 03:28:53 GMT, Jasmine Karthikeyan
wrote:
>> Jatin Bhateja has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains three additional
>
On Thu, 1 Aug 2024 04:11:24 GMT, Prasadrao Koppula wrote:
> Using SharedSecrets, I attempted to expose FileInputStream::path information.
> After implementing the fix, I validated the startup performance tests.
> Observed no consistent pattern of performance drops or gains, can disregard
> the
> Using SharedSecrets, I attempted to expose FileInputStream::path information.
> After implementing the fix, I validated the startup performance tests.
> Observed no consistent pattern of performance drops or gains, can disregard
> the occasional performance drop observed in 1 or 2 runs.
Prasa
On Sun, 11 Aug 2024 22:25:40 GMT, Rafael Winterhalter
wrote:
> When a type uses a type variable without a declaration, no exception is
> thrown. This change triggers a `TypeNotFoundException` to be thrown.
src/java.base/share/classes/java/lang/TypeNotPresentException.java line 37:
> 35: * th
On Mon, 10 Jun 2024 03:51:40 GMT, Glavo wrote:
>> Things have changed since https://github.com/openjdk/jdk/pull/14636 was
>> closed, so let me reopen it.
>>
>> https://github.com/openjdk/jdk/pull/15386 confirmed that `VarHandle` in BALE
>> caused a startup regression. In order to not have any
Hi Stephen,
I agree: there's no way to get defined packages for the boot class loader
directly via Package.getDefinedPackage. They are not accessible via the
system or platform class loaders. The alternative approaches via
Package.getDefinedPackages() or getPackage() can be intercepted by custom
cl
On Sun, 11 Aug 2024 at 17:19, Alan Bateman wrote:
> Package.getPackage is deprecated a long time, I don't think we've seen too
> many complaints. Nowadays it's probably not too useful except to get to
> package annotations (everything else in that API dates from JDK 1.2 and the
> since removed
When a type uses a type variable without a declaration, no exception is thrown.
This change triggers a `TypeNotFoundException` to be thrown.
-
Commit messages:
- JDK-8337302: Throw exception upon search for type variable without
representation.
Changes: https://git.openjdk.org/jdk
On Sun, 11 Aug 2024 07:30:12 GMT, Chris Hennick wrote:
>> This provides a slightly more accurate bounding limit for
>> `computeNextExponentialSoftCapped`. Currently, if the maximum is specified
>> as 12.0, it won't actually return a value larger than `1.5 * exponentialX0`
>> (11.35391204122209
On Mon, 10 Jun 2024 02:12:11 GMT, Glavo wrote:
> Things have changed since https://github.com/openjdk/jdk/pull/14636 was
> closed, so let me reopen it.
>
> https://github.com/openjdk/jdk/pull/15386 confirmed that `VarHandle` in BALE
> caused a startup regression. In order to not have any more
On Sat, 27 Jul 2024 15:00:51 GMT, Archie Cobbs wrote:
>> `GZIPInputStream` supports reading data from multiple concatenated GZIP data
>> streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In
>> order to do this, after a GZIP trailer frame is read, it attempts to read a
>
> `GZIPInputStream` supports reading data from multiple concatenated GZIP data
> streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In
> order to do this, after a GZIP trailer frame is read, it attempts to read a
> GZIP header frame and, if successful, proceeds onward to d
On 11/08/2024 15:17, Stephen Colebourne wrote:
I make use of Package.getPackage in Joda-Convert but the method has
now been deprecated. I'd like to update my code, but AFAICT the
suggested alternative does not work.
The Joda-Convert code allows a user to convert a Package object to a
String, and
I make use of Package.getPackage in Joda-Convert but the method has
now been deprecated. I'd like to update my code, but AFAICT the
suggested alternative does not work.
The Joda-Convert code allows a user to convert a Package object to a
String, and back again. Reading the deprecation, I'm aware t
> By removing the redundant code logic in
> DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be
> reduced and the performance can be improved.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
breaking out the p
On Sat, 27 Jul 2024 15:00:51 GMT, Archie Cobbs wrote:
>> `GZIPInputStream` supports reading data from multiple concatenated GZIP data
>> streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In
>> order to do this, after a GZIP trailer frame is read, it attempts to read a
>
On Sun, 11 Aug 2024 10:13:35 GMT, Stephen Colebourne
wrote:
> A more productive direction might be to move `LocalDate.formatTo` and
> `LocalTime.formatTo` to a JDK internal class (eg. in `jdk.internal.util`?),
> and then edit `LocalTime.formatTo` to handle `fractionalDigits` directly as
> ano
On Sat, 27 Jul 2024 13:45:11 GMT, Shaojin Wen wrote:
> Similar to PR #20321, this improves performance by providing a method that
> passes in a StringBuilder to avoid unnecessary object allocation.
Below are the performance numbers on the MacBook M1 Pro. In the
zonedDateTimeToString scenario,
On Sun, 11 Aug 2024 10:17:08 GMT, Shaojin Wen wrote:
>> By removing the redundant code logic in
>> DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be
>> reduced and the performance can be improved.
>
> Shaojin Wen has updated the pull request incrementally with one addi
On Sat, 27 Jul 2024 13:45:11 GMT, Shaojin Wen wrote:
> Similar to PR #20321, this improves performance by providing a method that
> passes in a StringBuilder to avoid unnecessary object allocation.
Change looks fine, but is it actually faster?
-
Marked as reviewed by scolebourne (
On Sun, 11 Aug 2024 10:13:12 GMT, Shaojin Wen wrote:
>> By removing the redundant code logic in
>> DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be
>> reduced and the performance can be improved.
>
> Shaojin Wen has updated the pull request incrementally with one addi
> By removing the redundant code logic in
> DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be
> reduced and the performance can be improved.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
copyright
---
> By removing the redundant code logic in
> DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be
> reduced and the performance can be improved.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
Update
src/java.b
On Sun, 28 Jul 2024 15:52:03 GMT, Shaojin Wen wrote:
>> By removing the redundant code logic in
>> DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be
>> reduced and the performance can be improved.
>
> Shaojin Wen has updated the pull request incrementally with one addi
Dear list,
The Pattern Javadoc does not specify whether “Any character” includes
line terminators in “Any character except a, b, or c (negation)”
([^abc]) or “Any character except one in the Greek block (negation)”
(\P{InGreek}), or whether it depends on DOTALL or MULTILINE being set.
As a result
> This provides a slightly more accurate bounding limit for
> `computeNextExponentialSoftCapped`. Currently, if the maximum is specified as
> 12.0, it won't actually return a value larger than `1.5 * exponentialX0`
> (11.353912041222094); and the error gets worse as we go further into the
> tai
26 matches
Mail list logo
