On Wed, 29 May 2024 19:27:17 GMT, Chen Liang wrote:
>> I propose to add type-checked ConstantPool.entryByIndex and
>> ClassReader.readEntryOrNull taking an extra Class parameter, which throws
>> ConstantPoolException instead of ClassCastException on type mismatch, which
>> can happen to malfor
On Thu, 30 May 2024 21:47:02 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/classfile/ClassReader.java line 142:
>>
>>> 140: * @throws ConstantPoolException if the index is out of range of
>>> the
>>> 141: * constant pool size, or zero, or the entry is not of
The new method additions ClassReader.readEntryOrNull(int, Class) and
ConstantPool.entryByIndex(int, Class) have incorrect since tags; they should be
`@since 23`.
-
Commit messages:
- 812: Incorrect since tags on new ClassReader and ConstantPool methods
Changes: https://git.ope
On Fri, 31 May 2024 13:04:03 GMT, David M. Lloyd wrote:
> The new method additions ClassReader.readEntryOrNull(int, Class) and
> ConstantPool.entryByIndex(int, Class) have incorrect since tags; they should
> be `@since 23`.
This pull request has now been integrated.
Changeset:
Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support
for functionality required to continue to support IIOP and custom serializers
in light of additional module-based restrictions on reflection. It was expected
that these libraries would use `sun.misc.Unsafe` in order t
On Thu, 13 Jun 2024 14:31:06 GMT, David M. Lloyd wrote:
> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added
> support for functionality required to continue to support IIOP and custom
> serializers in light of additional module-based restrictions on reflection.
On Thu, 27 Jun 2024 08:08:13 GMT, Alan Bateman wrote:
>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added
>> support for functionality required to continue to support IIOP and custom
>> serializers in light of additional module-based restrictions on reflection.
>> It was
On Fri, 28 Jun 2024 14:04:13 GMT, David M. Lloyd wrote:
>> Indeed, if you look at the previous revision, that's how I implemented it.
>> However, the generator currently needs access to `Lookup.IMPL_LOOKUP` in
>> order to generate a nestmate class and accessors for
On Mon, 1 Jul 2024 05:35:37 GMT, Chen Liang wrote:
>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added
>> support for functionality required to continue to support IIOP and custom
>> serializers in light of additional module-based restrictions on reflection.
>> It was exp
On Mon, 1 Jul 2024 12:46:18 GMT, David M. Lloyd wrote:
>> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line
>> 441:
>>
>>> 439: }
>>> 440:
>>> 441: return
>>> SerializationBytecodeGenerator.defau
On Fri, 28 Jun 2024 22:03:36 GMT, ExE Boss wrote:
>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added
>> support for functionality required to continue to support IIOP and custom
>> serializers in light of additional module-based restrictions on reflection.
>> It was expe
On Fri, 28 Jun 2024 13:09:19 GMT, David M. Lloyd wrote:
>> src/java.base/share/classes/java/lang/invoke/SerializationBytecodeGenerator.java
>> line 43:
>>
>>> 41: * The private serialization bytecode generator used by {@code
>>> sun.misc.ReflectionFacto
On Tue, 16 Jul 2024 18:34:00 GMT, Roger Riggs wrote:
> Is there a high level description of how these methods would be used?
They would be used identically to how the `readObjectForSerialization` and
`writeObjectForSerialization` methods are used. The caller would pass the
object as a pseudo-"
w for the reading of
> serialization-specific private static final fields from classes which have
> them.
>
> With the addition of these methods, serialization libraries no longer need to
> rely on `Unsafe` for serialization/deserialization activities.
> cc: @AlanBateman
David
w for the reading of
> serialization-specific private static final fields from classes which have
> them.
>
> With the addition of these methods, serialization libraries no longer need to
> rely on `Unsafe` for serialization/deserialization activities.
> cc: @AlanBateman
David
On Mon, 12 Aug 2024 18:18:04 GMT, Roger Riggs wrote:
> The tests should include serializing some sample JDK classes that include a
> hierarchy of 2-4 levels. It would help fles any interactions in the
> sequencing of calling the default serialization for each of a concrete
> class's supertypes
Please review this small documentation change to ConstantPoolBuilder to fix a
typo and clarify the usage of the `constantValueEntry` method.
-
Commit messages:
- 8339329: ConstantPoolBuilder#constantValueEntry method doc typo and
clarifications
Changes: https://git.openjdk.org/jdk
> Please review this small documentation change to ConstantPoolBuilder to fix a
> typo and clarify the usage of the `constantValueEntry` method.
David M. Lloyd has updated the pull request incrementally with one additional
commit since the last revision:
Review co
Please review this change, which reduces the number of allocations in
`StackMapDecoder::writeFrames` by using a sorted array instead of a
`TreeMap` to sort and uniquify entries before writing.
Tested using `StackMapsTest`.
-
Commit messages:
- 8339492: StackMapDecoder::writeFrames
On Tue, 3 Sep 2024 16:13:39 GMT, David M. Lloyd wrote:
> Please review this change, which reduces the number of allocations in
> `StackMapDecoder::writeFrames` by using a sorted array instead of a
> `TreeMap` to sort and uniquify entries before writing.
>
> Tested using `Stack
> Tested using `StackMapsTest`.
David M. Lloyd has updated the pull request incrementally with one additional
commit since the last revision:
Review feedback: reject duplicate stack map entries
-
Changes:
- all: https://git.openjdk.org/jdk/pull/20841/files
- new: https://git.openjdk.
On Mon, 21 Nov 2022 16:46:43 GMT, Strahinja Stanojevic wrote:
>> This PR introduces an option to output stable names for the lambda classes
>> in the JDK. A stable name consists of two parts: The first part is the
>> predefined value `$$Lambda$` appended to the lambda capturing class, and the
The class generated for lambda proxies is now defined as a hidden class. This
means that the counter, which was used to ensure a unique class name and avoid
clashes, is now redundant. In addition to performing redundant work, this also
impacts build reproducibility for native image generators wh
On Wed, 15 Feb 2023 17:32:38 GMT, David M. Lloyd wrote:
> The class generated for lambda proxies is now defined as a hidden class. This
> means that the counter, which was used to ensure a unique class name and
> avoid clashes, is now redundant. In addition to performing redun
On Wed, 15 Feb 2023 17:32:38 GMT, David M. Lloyd wrote:
> The class generated for lambda proxies is now defined as a hidden class. This
> means that the counter, which was used to ensure a unique class name and
> avoid clashes, is now redundant. In addition to performing redun
On Wed, 15 Feb 2023 17:32:38 GMT, David M. Lloyd wrote:
> The class generated for lambda proxies is now defined as a hidden class. This
> means that the counter, which was used to ensure a unique class name and
> avoid clashes, is now redundant. In addition to performing redun
s would also replace #10024.
David M. Lloyd has refreshed the contents of this pull request, and previous
commits have been removed. The incremental views will show differences compared
to the previous content of the PR. The pull request contains one new commit
since the last revision:
829
On Wed, 15 Feb 2023 22:44:21 GMT, David M. Lloyd wrote:
>> The class generated for lambda proxies is now defined as a hidden class.
>> This means that the counter, which was used to ensure a unique class name
>> and avoid clashes, is now redundant. In addition to performing
s would also replace #10024.
David M. Lloyd has updated the pull request incrementally with two additional
commits since the last revision:
- Import
- Beter timestamp placement
-
Changes:
- all: https://git.openjdk.org/jdk/pull/12579/files
- new: https://git.openjdk.org/jd
s would also replace #10024.
David M. Lloyd has updated the pull request incrementally with two additional
commits since the last revision:
- Fix LambdaAsm test
- Fix stack walker test
-
Changes:
- all: https://git.openjdk.org/jdk/pull/12579/files
- new: https://git.openj
On Thu, 16 Feb 2023 01:42:16 GMT, David M. Lloyd wrote:
>> The class generated for lambda proxies is now defined as a hidden class.
>> This means that the counter, which was used to ensure a unique class name
>> and avoid clashes, is now redundant. In addition to performing
s would also replace #10024.
David M. Lloyd has updated the pull request incrementally with one additional
commit since the last revision:
Use `Instant.now()` for more precise timestamps.
Using `currentTimeMillis` is imprecise enough that tests may sporadically
fail if two lambda classes fro
On Thu, 16 Feb 2023 14:06:54 GMT, David M. Lloyd wrote:
>> The class generated for lambda proxies is now defined as a hidden class.
>> This means that the counter, which was used to ensure a unique class name
>> and avoid clashes, is now redundant. In addition to performing
On Thu, 16 Feb 2023 14:06:54 GMT, David M. Lloyd wrote:
>> The class generated for lambda proxies is now defined as a hidden class.
>> This means that the counter, which was used to ensure a unique class name
>> and avoid clashes, is now redundant. In addition to performing
s would also replace #10024.
David M. Lloyd has updated the pull request incrementally with one additional
commit since the last revision:
Use a unique index for the dumped lambda class instead of a time stamp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/12579/files
- new:
On Thu, 16 Feb 2023 19:37:18 GMT, ExE Boss wrote:
>> David M. Lloyd has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Use a unique index for the dumped lambda class instead of a time stamp
>
> src/java.base/
On Thu, 16 Feb 2023 22:23:09 GMT, ExE Boss wrote:
>> The Lamdba class name already ends in `$` - is there a reason we'd need a
>> second one when dumping?
>
> I suggested removing it in:
> https://github.com/openjdk/jdk/pull/12579#discussion_r1108941733
Ah I missed that. Sure, I guess that's f
On Thu, 16 Feb 2023 19:35:54 GMT, David M. Lloyd wrote:
>> The class generated for lambda proxies is now defined as a hidden class.
>> This means that the counter, which was used to ensure a unique class name
>> and avoid clashes, is now redundant. In addition to performing
s would also replace #10024.
David M. Lloyd has updated the pull request incrementally with one additional
commit since the last revision:
Updated to use hidden class suffix for dumps when possible, else use the
counter with a `failed` suffix. Also, remove the extra trailing `$` from the
lambda
On Fri, 17 Feb 2023 15:18:25 GMT, Vojin Jovanovic wrote:
> We didn't use the cryptographic hash as it is not resilient to the changes
> that happen to the bytecode generators of hidden classes. If anything in the
> bytecode generation (e.g., in `InnerClassLambdaMetafactory`) changes, the
> has
On Fri, 17 Feb 2023 16:55:28 GMT, Ioi Lam wrote:
> Java doesn't guarantee to use unique names even for "regular" classes. You
> can use two class loaders that load two completely different classes with the
> exact same name.
>
> How does Graal and qbicc handle this?
In qbicc, we keep separate
s would also replace #10024.
David M. Lloyd has updated the pull request incrementally with two additional
commits since the last revision:
- Many tests have patterns for lambda class names; update them
- Update comments and javadoc showin the old pattern
-
Changes:
- all: https
On Fri, 17 Feb 2023 02:11:10 GMT, Mandy Chung wrote:
>> David M. Lloyd has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Use a unique index for the dumped lambda class instead of a time stamp
>
> `this_class
On Fri, 17 Feb 2023 19:37:59 GMT, David M. Lloyd wrote:
>> The class generated for lambda proxies is now defined as a hidden class.
>> This means that the counter, which was used to ensure a unique class name
>> and avoid clashes, is now redundant. In addition to performing
On Fri, 17 Feb 2023 19:37:59 GMT, David M. Lloyd wrote:
>> The class generated for lambda proxies is now defined as a hidden class.
>> This means that the counter, which was used to ensure a unique class name
>> and avoid clashes, is now redundant. In addition to performing
s would also replace #10024.
David M. Lloyd has updated the pull request incrementally with one additional
commit since the last revision:
Apply formatting suggestions and update copyright notices
-
Changes:
- all: https://git.openjdk.org/jdk/pull/12579/files
- new: https://git
On Thu, 23 Feb 2023 23:50:16 GMT, Mandy Chung wrote:
>> David M. Lloyd has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Many tests have patterns for lambda class names; update them
>> - Update comme
s would also replace #10024.
David M. Lloyd has updated the pull request incrementally with one additional
commit since the last revision:
Remove final keyword
-
Changes:
- all: https://git.openjdk.org/jdk/pull/12579/files
- new: https://git.openjdk.org/jdk/pull/12579/files/
On Fri, 24 Feb 2023 16:16:51 GMT, David M. Lloyd wrote:
>> The class generated for lambda proxies is now defined as a hidden class.
>> This means that the counter, which was used to ensure a unique class name
>> and avoid clashes, is now redundant. In addition to performing
On Wed, 15 Feb 2023 17:32:38 GMT, David M. Lloyd wrote:
> The class generated for lambda proxies is now defined as a hidden class. This
> means that the counter, which was used to ensure a unique class name and
> avoid clashes, is now redundant. In addition to performing redun
On Mon, 21 Nov 2022 16:46:43 GMT, Strahinja Stanojevic wrote:
>> This PR introduces an option to output stable names for the lambda classes
>> in the JDK. A stable name consists of two parts: The first part is the
>> predefined value `$$Lambda$` appended to the lambda capturing class, and the
On Fri, 24 Mar 2023 16:41:02 GMT, Michael Osipov wrote:
>> A bit of a quibble, several internet sources identify Linux as an operating
>> system (including Redhat).
>
> Well, no. It is just a kernel. Without a userland not an OS. That is why they
> call it GNU/Linux. Kernel + userland.
If you
On Wed, 29 Mar 2023 11:28:53 GMT, Aleksey Shipilev wrote:
> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The
> documentation for that method clearly says the precision and accuracy are
> dependent on the underlying system behavior. However, it always rounds up
> `nan
On Wed, 29 Mar 2023 11:28:53 GMT, Aleksey Shipilev wrote:
> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The
> documentation for that method clearly says the precision and accuracy are
> dependent on the underlying system behavior. However, it always rounds up
> `nan
On Thu, 6 Apr 2023 08:00:43 GMT, ExE Boss wrote:
>> Roger Riggs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Correct spelling of isAARCH64 in WIndows AttachProviderImpl
>
> src/java.base/share/classes/jdk/internal/util/Architecture.ja
On Fri, 5 May 2023 13:43:43 GMT, Daniel Fuchs wrote:
> Several Handlers class use monitors to synchronize when formatting /
> publishing LogRecords.
> When logging within a VirtualThread, holding this monitor can cause the
> carrier thread to be pinned.
> Handlers could use jdk.internal.misc.In
On Fri, 5 May 2023 16:31:18 GMT, Daniel Fuchs wrote:
> Thanks for your observations David!
>
> Use of synchronization in these handler classes has two purposes: one is
> visibility. Since Handlers are used by multiple (logging) threads, and
> potentially configured from different threads (e.g.
On Wed, 4 Sep 2024 01:06:10 GMT, Shaojin Wen wrote:
> It looks good, but can you provide the codeSize before and after the change?
> For example, add the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions
> -XX:+PrintInlining` to find `writeFrames` and see if this PR will change from
> les
On Wed, 4 Sep 2024 13:08:49 GMT, Claes Redestad wrote:
> LGTM
>
> AFAICT before this we'd only call `DirectCodeBuilder::labelToBci` once per
> label, but now we'll do so roughly `2*n*log(n) + n` times. I would assume
> getting rid of the `TreeMap` and `Integer` key allocations more than makes
On Wed, 4 Sep 2024 14:18:09 GMT, Claes Redestad wrote:
> > If so, then this amounts to a fairly minimal and direct code path, thus I
> > approached this as being an "obvious" (as opposed to theoretical)
> > improvement.
>
> I agree that it looks like the typical path is trivial, but I don't ha
On Wed, 4 Sep 2024 15:27:40 GMT, Chen Liang wrote:
> > I'll see if I can get the benchmarks in
> > `test/micro/org/openjdk/bench/jdk/classfile` working. It looks like there
> > may be one or more of them which would reach into this code.
>
> Just checked; no benchmark is currently supplying a
On Tue, 3 Sep 2024 16:13:39 GMT, David M. Lloyd wrote:
> Please review this change, which reduces the number of allocations in
> `StackMapDecoder::writeFrames` by using a sorted array instead of a
> `TreeMap` to sort and uniquify entries before writing. It also
> adds a validati
On Thu, 5 Sep 2024 17:54:46 GMT, Alan Bateman wrote:
>> This PR proposes to add a JDK-specific monitoring and management interface
>> for the virtual thread scheduler. The interface is named
>> [VirtualThreadSchedulerMXBean](https://download.java.net/java/early_access/loom/docs/api/jdk.manageme
Please review this small change to fix a misspelling. The constant is not used
directly; rather it is used by ordinal, which explains why the error was not
found sooner.
-
Commit messages:
- 8340200: Misspelled constant
`AttributesProcessingOption.DROP_UNSTABLE_ATRIBUTES`
Changes
On Mon, 15 Jan 2024 02:30:39 GMT, ExE Boss wrote:
>> Chen Liang has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains ten commits:
>>
>> - Merge branch 'master' into fix/typearg-model
>> - redundant line
>> - Fix a test in langtools,
On Tue, 15 Oct 2024 15:33:03 GMT, Daniel Fuchs wrote:
>> This is a bit of forced move. Same thing with Thread.checkAccess and
>> ThreadGroup.checkAccess that also have to be re-specified to throw
>> unconditionally. They are called out in the CSR.
>
> OK
While I disagree with this change on th
On Tue, 15 Oct 2024 16:14:58 GMT, Sean Mullan wrote:
> While making `LogManager.checkAccess` be a no-op might be more convenient, it
> could unconditionally permit operations that formerly required a permission
> check: clearly a bad idea. Always throwing a `SecurityException` is the
> safest
On Wed, 25 Sep 2024 12:58:20 GMT, David M. Lloyd wrote:
>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added
>> support for functionality required to continue to support IIOP and custom
>> serializers in light of additional module-based restrictions on
w for the reading of
> serialization-specific private static final fields from classes which have
> them.
>
> With the addition of these methods, serialization libraries no longer need to
> rely on `Unsafe` for serialization/deserialization activities.
> cc: @AlanBateman
David
On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Fri, 18 Oct 2024 12:37:10 GMT, David M. Lloyd wrote:
>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added
>> support for functionality required to continue to support IIOP and custom
>> serializers in light of additional module-based restrictions on
ion pressure, in
> this code by simplifying it so that the `switch` is itself run directly
> within the `try`/`catch`.
David M. Lloyd has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains two commits:
- Make sure that we record ever
On Fri, 30 Aug 2024 15:08:20 GMT, David M. Lloyd wrote:
> Please review this small documentation change to ConstantPoolBuilder to fix a
> typo and clarify the usage of the `constantValueEntry` method.
This pull request has now been integrated.
Changeset: 20f36c66
Author: David M.
w for the reading of
> serialization-specific private static final fields from classes which have
> them.
>
> With the addition of these methods, serialization libraries no longer need to
> rely on `Unsafe` for serialization/deserialization activities.
> cc: @AlanBateman
David
On Mon, 21 Oct 2024 14:13:35 GMT, David M. Lloyd wrote:
>> Currently, `ParserVerifier#verifyConstantPool` uses a `switch` to produce a
>> `Runnable`, which is consumed by a `Consumer` (instantiated within
>> a loop) which runs the task inside if a `try`/`catch`. We can elim
On Wed, 30 Oct 2024 08:54:55 GMT, kabutz wrote:
> The ArrayBlockingQueue has had a readObject() method since Java 7, which
> checks invariants of the deserialized object. However, it does not have a
> writeObject() method. This means that the ArrayBlockingQueue could be
> modified whilst it is
On Tue, 22 Oct 2024 12:49:08 GMT, David M. Lloyd wrote:
>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added
>> support for functionality required to continue to support IIOP and custom
>> serializers in light of additional module-based restrictions on
On Wed, 13 Nov 2024 15:37:26 GMT, Roger Riggs wrote:
> With the SecurityManager (jep 486) integrated, cleanup of referernces to
> SecurityManager etc will need to be cleanedup. It can be done as a separate
> PR or included in this PR.
I already did this as part of the upstream merge (there was
On Wed, 13 Nov 2024 16:01:54 GMT, Roger Riggs wrote:
>> This is used down below on line 423:
>>
>>
>> private static boolean hasDefaultOrNoSerialization(Class cl) {
>> return ! Serializable.class.isAssignableFrom(cl)
>> || cl.isInterface()
>> || cl.isArray()
w for the reading of
> serialization-specific private static final fields from classes which have
> them.
>
> With the addition of these methods, serialization libraries no longer need to
> rely on `Unsafe` for serialization/deserialization activities.
> cc: @AlanBateman
David M. L
On Wed, 13 Nov 2024 13:17:31 GMT, David M. Lloyd wrote:
>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added
>> support for functionality required to continue to support IIOP and custom
>> serializers in light of additional module-based restrictions on
On Wed, 13 Nov 2024 15:49:55 GMT, Roger Riggs wrote:
>> David M. Lloyd has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 37 commits:
>>
>> - Merge remote-tracking branch 'upstream-jdk/master' into
On Wed, 13 Nov 2024 17:47:57 GMT, Chen Liang wrote:
>> David M. Lloyd has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 37 commits:
>>
>> - Merge remote-tracking branch 'upstream-jdk/master' into
w for the reading of
> serialization-specific private static final fields from classes which have
> them.
>
> With the addition of these methods, serialization libraries no longer need to
> rely on `Unsafe` for serialization/deserialization activities.
> cc: @AlanBateman
David
Currently, `ParserVerifier#verifyConstantPool` uses a `switch` to produce a
`Runnable`, which is consumed by a `Consumer` (instantiated within a
loop) which runs the task inside if a `try`/`catch`. We can eliminate a number
of lambdas and method references, plus some allocation pressure, in this
ion pressure, in
> this code by simplifying it so that the `switch` is itself run directly
> within the `try`/`catch`.
David M. Lloyd has updated the pull request incrementally with one additional
commit since the last revision:
Make sure that we record every error instead of stopping
On Thu, 26 Sep 2024 13:41:31 GMT, Chen Liang wrote:
>> David M. Lloyd has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Make sure that we record every error instead of stopping at the first
>> error in a pa
On Fri, 30 Aug 2024 18:12:38 GMT, David M. Lloyd wrote:
>> Please review this small documentation change to ConstantPoolBuilder to fix
>> a typo and clarify the usage of the `constantValueEntry` method.
>
> David M. Lloyd has updated the pull request incrementally with one ad
On Tue, 16 Jul 2024 18:17:00 GMT, Roger Riggs wrote:
>> David M. Lloyd has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address review feedback
>
> src/java.base/share/classes/jdk/internal/reflect/Refl
w for the reading of
> serialization-specific private static final fields from classes which have
> them.
>
> With the addition of these methods, serialization libraries no longer need to
> rely on `Unsafe` for serialization/deserialization activities.
> cc: @AlanBateman
David
On Fri, 20 Sep 2024 20:27:00 GMT, Roger Riggs wrote:
>> David M. Lloyd has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address review comment
>
> src/java.base/share/classes/jdk/internal/reflect/Refl
On Mon, 30 Sep 2024 10:03:57 GMT, Shaojin Wen wrote:
> The new API loadConstant(int) can shorten the calling path and can replace
> ldc when the parameter is of int/Integer type.
I was also curious about a few other seemingly "obvious" small optimizations,
like loading `-1L` as `iconst_m1; i2l
> Please review this small documentation change to ConstantPoolBuilder to fix a
> typo and clarify the usage of the `constantValueEntry` method.
David M. Lloyd has updated the pull request incrementally with one additional
commit since the last revision:
Review fe
w for the reading of
> serialization-specific private static final fields from classes which have
> them.
>
> With the addition of these methods, serialization libraries no longer need to
> rely on `Unsafe` for serialization/deserialization activities.
> cc: @AlanBateman
David
On Tue, 17 Sep 2024 13:37:19 GMT, Chen Liang wrote:
>> Per Minborg has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Update javadoc
>> - Rename utility class
>
> I think a better approach to this problem might be converting these static
On Mon, 16 Sep 2024 12:56:14 GMT, David M. Lloyd wrote:
> Please review this small change to fix a misspelling. The constant is not
> used directly; rather it is used by ordinal, which explains why the error was
> not found sooner.
This pull request has now been integrated.
On Tue, 17 Sep 2024 17:31:58 GMT, Alan Bateman wrote:
> Looks like test/jdk/jdk/classfile/OptionsTest.java was missed.
Ah. I did a code search in the IDE but I forgot that my import doesn't have
complete test coverage; I should have grep'd to be sure. Sorry about that.
-
PR Commen
On Thu, 14 Nov 2024 15:10:37 GMT, David M. Lloyd wrote:
>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added
>> support for functionality required to continue to support IIOP and custom
>> serializers in light of additional module-based restrictions on
On Thu, 13 Jun 2024 14:31:06 GMT, David M. Lloyd wrote:
> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added
> support for functionality required to continue to support IIOP and custom
> serializers in light of additional module-based restrictions on reflection.
On Thu, 14 Nov 2024 15:10:37 GMT, David M. Lloyd wrote:
>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added
>> support for functionality required to continue to support IIOP and custom
>> serializers in light of additional module-based restrictions on
1 - 100 of 133 matches
Mail list logo
