On Sun, 30 Jun 2024 18:21:52 GMT, Shaojin Wen wrote:
>> We need a String format solution with good performance. String Template was
>> once expected, but it has been removed. j.u.Formatter is powerful, but its
>> performance is not good enough.
>>
>> This PR implements a subset of j.u.Formatte
> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic
> instructions. But when run with JDK 11, there is no such problem. The reason
> is the removed biased locking.
> The DecimalFormat uses StringBuffer everywhere, and St
Today, the JDK includes support for generating random UUIDs ("v4") and
name-based UUID's ("v3"). These two types have random leading bits, and
that results in poor performance in database systems that have sorted
indexes (i.e. most of them).
RFC 9562 [1], an update to the original UUID RFC, solves
The code you point to below is leveraging ZipFS, which provided as a demo in
JDK 8 and was not a supported part of Java until JDK 9 at which point ZipFS
did not use ZipError.
So I understand your point but we also need to keep in mind that demo !=
supported as we consider the eventual removal
> We need a String format solution with good performance. String Template was
> once expected, but it has been removed. j.u.Formatter is powerful, but its
> performance is not good enough.
>
> This PR implements a subset of j.u.Formatter capabilities. The performance is
> good enough that it is
> We need a String format solution with good performance. String Template was
> once expected, but it has been removed. j.u.Formatter is powerful, but its
> performance is not good enough.
>
> This PR implements a subset of j.u.Formatter capabilities. The performance is
> good enough that it is
On Sun, 30 Jun 2024 04:54:35 GMT, Shaojin Wen wrote:
>> We need a String format solution with good performance. String Template was
>> once expected, but it has been removed. j.u.Formatter is powerful, but its
>> performance is not good enough.
>>
>> This PR implements a subset of j.u.Formatte
On Sun, 30 Jun 2024 14:57:26 GMT, David Schlosnagle wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> laze init for `decimal fast path locale`
>
> src/java.base/share/classes/java/lang/StringFormat.java line 142:
>
>
I am the maintainer of HMCL and we need to catch ZipError in our program
because our program needs to be compatible with Java 8:
https://github.com/HMCL-dev/HMCL/blob/85b68ad135267bc33e03c3624b1bced9b7804c39/HMCLCore/src/main/java/org/jackhuang/hmcl/util/io/CompressingUtils.java#L218-L220
I'd lov
Hi Eirik,
The removal of ZipError from ZipFile/ZipFileSystem/ZipFileSystemProvider
occurred via 8145260 and 8037394 for JDK 9
The test should also be re-written at this point
Jai or I can make a pass to see if there are any external usages via a corpus
search but I tend to doubt it
On Jun 30
On Sat, 1 Jun 2024 11:49:39 GMT, Viktor Klang wrote:
> This PR improves the test failure output for the failing test case, and the
> underlying issue is likely going to be addressed by
> https://github.com/openjdk/jdk/pull/19131 /cc @DougLea
@AlanBateman @stuart-marks @PaulSandoz This is a PR
On Sun, 30 Jun 2024 04:54:35 GMT, Shaojin Wen wrote:
>> We need a String format solution with good performance. String Template was
>> once expected, but it has been removed. j.u.Formatter is powerful, but its
>> performance is not good enough.
>>
>> This PR implements a subset of j.u.Formatte
Hi!
The java.util.zip.ZipError class seems unused in OpenJDK. I assume this is
legacy from the native ZIP implementation in Java 8.
This exception class extends InternalError and seems to have been added in
Java 6 to help compatibility with existing code catching InternalError
(JDK-4615343)
This
13 matches
Mail list logo
