On Fri, 10 May 2024 10:06:55 GMT, Alan Bateman wrote:
> This is the implementation changes for JEP 471.
>
> The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated
> for removal. This means a removal warning at compile time. No methods have
> been removed. A deprecated me
On Sun, 12 May 2024 21:44:56 GMT, Alan Snyder wrote:
> I was not using the Zip file system. I was processing a Zip file.
They are equivalent, the suggestion to look at the sym link support in the zip
file system provider is that it's a much better fit for this extension. It
already has optiona
This is the implementation changes for JEP 471.
The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated
for removal. This means a removal warning at compile time. No methods have been
removed. A deprecated message is added to each of the methods but unlikely to
be seen as
On Thu, 7 Mar 2024 05:33:16 GMT, Korov wrote:
>> When the specified key did not associated with a value, should check the
>> `key` and `value` type.
>
> Korov has updated the pull request incrementally with one additional commit
> since the last revision:
>
> Use testNG builtin functionaliti
Hello Alessandro,
I've moved this discussion to net-dev mailing list which is more
relevant for this discussion (and Bcced core-libs-dev). If you haven't
already subscribed to net-dev, then you can do it here
https://mail.openjdk.org/mailman/listinfo/net-dev.
-Jaikiran
On 13/05/24 3:28 am,
On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie wrote:
>> WIP
>>
>> This changeset contains hsdis for Windows/gcc Port. It supports both the
>> binutils and capstone backends, though the LLVM backend is left out due to
>> compatibility issues encountered during the build. Currently, which
Hi Mike,
I think this particular field has been renamed a few times; and ZipEntry
only exposes part of the ZIP format's fields. So most likely there isn't
sufficient information for most 3rd-party ZIP processing libraries. I
personally don't really use ZipFile so am not quite sure of the recent API
>
> I’m not an expert on ZIp files, but from your description it would seem best
> to create a new field.
>
> I agree that the version made by field is also needed.
>
>
>> On May 12, 2024, at 1:56 PM, - wrote:
>>
>> Hi Alan Snyder,
>> Currently, JDK ZipEntry populates that extraAttributes (
Hello, my name is Alessandro Autiero and I'd like to propose three
enhancements for the java core libraries to better support proxies in
network components of the JDK.
There are three classes in the java.net package that have proxy support:
- java.net.Socket
Introduced in Java 1.0, supports
Hi Alan Snyder,
Currently, JDK ZipEntry populates that extraAttributes (proposed to rename
to externalFileAttributes in JDK-8321274, PR #16952) only if the high byte
of the "version made by" field is 3 (indicating Linux compatibility) and
only records the most significant 2 bytes for the copied Zip
On Sun, 12 May 2024 13:12:24 GMT, Doug Lea wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments with
> It might be interesting to explore that in the context of the zip file system
> provider, less sure about the java.util.zip APIs.
I was not using the Zip file system. I was processing a Zip file.
Alan
> On May 12, 2024, at 7:32 AM, Chen Liang wrote:
>
> On Sun, 12 May 2024 02:48:31 G
Code cleanup, please review this simple change.
To help with the review, this was added back in
https://bugs.openjdk.org/browse/JDK-8191905
TIA
-
Commit messages:
- add an `@since` and modify Copyright header
Changes: https://git.openjdk.org/jdk/pull/19189/files
Webrev: https://w
On Sat, 11 May 2024 15:39:04 GMT, Nizar Benalla wrote:
> Code cleanup, please review this simple change.
> To help with the review, this was added back in
> https://bugs.openjdk.org/browse/JDK-8191905
> TIA
I believe `jdk.nashorn` is under core-libs
-
PR Comment: https://git.openj
On Thu, 9 May 2024 19:52:12 GMT, Sonia Zaldana Calles
wrote:
>> Hi folks,
>>
>> This PR aims to fix
>> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>>
>> I think the regression got introduced in
>> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>>
>> In the is
On Mon, 6 May 2024 18:24:25 GMT, Adam Sotona wrote:
>> Hi,
>> During performance optimization work on Class-File API as JDK lambda
>> generator we found some static initialization killers.
>> One of them is `java.lang.classfile.Attributes` with tens of static fields
>> initialized with individu
On Fri, 8 Mar 2024 09:34:05 GMT, Eirik Bjørsnøs wrote:
>> Please consider this PR which suggests we rename `ZipEntry.extraAttributes`
>> to `ZipEntry.externalFileAttributes`.
>>
>> This field was introduced in
>> [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under
>>
On Sun, 12 May 2024 02:48:31 GMT, xiaotaonan wrote:
> Add API to access ZipEntry.extraAttributes
Also see #16952, another patch that renames this field, which is planning for
an integration soon; this PR will be out-of-date when that one is integrated.
-
PR Comment: https://git.op
On Sun, 12 May 2024 09:48:42 GMT, xiaotaonan wrote:
> This issue was reported by a person named Alan Snyder, I don't have his or
> her contact information, how to create a CSR in this situation.
He came to core-libs-dev in Dec 2023 [1] to discuss this. The context at the
time was symbolic link
On Sun, 12 May 2024 02:48:31 GMT, xiaotaonan wrote:
> Add API to access ZipEntry.extraAttributes
For example, with a quick check, you can find that this field itself is not a
good candidate for direct setter exposure:
1. For context, this is part of [the central directory file
header](https://
On Sat, 11 May 2024 15:00:09 GMT, Alan Bateman wrote:
>> A compromise between performance and readability is:
>>
>> if (JFRTracing.isEnabled()) {
>> ...
>> }
>>
>> One additional class is loaded, but it's more clear where it comes from. I
>> didn't want to do that for the ThrowableTracer
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with large numbers of cores
Doug Lea has updated the pull r
On Sat, 11 May 2024 23:39:04 GMT, Viktor Klang wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Fri, 10 May 2024 12:20:27 GMT, Doug Lea wrote:
>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 978:
>>
>>> 976: * of two, at least 2. See above.
>>> 977: */
>>> 978: static final int INITIAL_QUEUE_CAPACITY = 1 << 7;
>>
>> @DougLea Interesting change—w
On Sun, 12 May 2024 09:48:42 GMT, xiaotaonan wrote:
>> Add API to access ZipEntry.extraAttributes
>
>> /csr
> @AlanBateman
>
> This issue was reported by a person named Alan Snyder, I don't have his or
> her contact information, how to create a CSR in this situation.
@xiaotaonan Since you app
On Sun, 12 May 2024 02:48:31 GMT, xiaotaonan wrote:
> Add API to access ZipEntry.extraAttributes
> /csr
@AlanBateman
This issue was reported by a person named Alan Snyder, I don't have his or her
contact information, how to create a CSR in this situation.
-
PR Comment: https://g
Some tests are not migrated to the ClassFile API in previous migrations.
- Some are simple oversights that didn't remove usages of
com.sun.tools.classfile;
- The CallerSensitive ones used an old utility, replaced by CF API-based new
code;
- many in javac are because the files are compiled wit
On Sat, 11 May 2024 19:31:34 GMT, Erik Gahlin wrote:
> If an event class is loaded before JFR is started, the event class needs to
> be retransformed, but if it is loaded later, we can add instrumentation on
> class load and avoid the retransformation. More happens when an event class
> is loa
28 matches
Mail list logo