On Tue, 8 Apr 2025 14:23:06 GMT, Sean Mullan wrote:
>> Please review this change to terminally deprecate the following security
>> related permission classes: `java.security.UnresolvedPermission`,
>> `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`,
>> `javax.security.auth.P
On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan wrote:
> Please review this change to terminally deprecate the following security
> related permission classes: `java.security.AllPermission`,
> `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`,
> `javax.security.auth.AuthPermissi
On Fri, 4 Apr 2025 14:12:55 GMT, Sean Mullan wrote:
> > > Please review this change to terminally deprecate the following security
> > > related permission classes: `java.security.AllPermission`,
> > > `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`,
> > > `javax.security.a
On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan wrote:
> Please review this change to terminally deprecate the following security
> related permission classes: `java.security.AllPermission`,
> `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`,
> `javax.security.auth.AuthPermissi
On Thu, 20 Mar 2025 19:49:33 GMT, David M. Lloyd wrote:
> Provide method overloads to the ClassFile interface of the
> java.lang.classfile API which allow parsing of classes found in memory
> segments, as well as allowing built class files to be output to them.
This pull request
On Fri, 28 Mar 2025 15:53:15 GMT, Adam Sotona wrote:
>> David M. Lloyd has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add a benchmark for class file emission
>
> https://github.com/openjdk/jdk/pull/24297
On Tue, 1 Apr 2025 11:18:14 GMT, Jan Lahoda wrote:
>> src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java
>> line 75:
>>
>>> 73: }
>>> 74: continue READ;
>>> 75: case '\033':
>>
>> If this is meant to be platfo
On Wed, 26 Mar 2025 07:54:48 GMT, Jan Lahoda wrote:
> The `java.io.Console` has several backends: a simple on in `java.base`, a
> more convenient one in `jdk.internal.le` (with line-reading based on JLine)
> and one for JShell.
>
> The backend based on JLine is proving to be a somewhat problem
On Thu, 27 Mar 2025 22:21:00 GMT, Adam Sotona wrote:
> I have two problems with the numbers you measured:
>
> 1. The benchmarked transformation runs on pre-parsed class and does nothing,
> so technically it measures mainly the memory copy process.
> 2. In the discussions there were mentioned me
On Thu, 27 Mar 2025 17:38:49 GMT, David M. Lloyd wrote:
>> Provide method overloads to the ClassFile interface of the
>> java.lang.classfile API which allow parsing of classes found in memory
>> segments, as well as allowing built class files to be output to them.
>
> Provide method overloads to the ClassFile interface of the
> java.lang.classfile API which allow parsing of classes found in memory
> segments, as well as allowing built class files to be output to them.
David M. Lloyd has updated the pull request incrementally with one additiona
On Thu, 27 Mar 2025 16:01:59 GMT, Adam Sotona wrote:
> As the parsing benefits are none due to the memory copy.
The main benefit on the parsing is twofold: reducing the user's boilerplate,
and the future possibility of further optimizing this case. At present the
performance is the same as mak
On Thu, 27 Mar 2025 14:56:17 GMT, Adam Sotona wrote:
> I'm sorry, but I'm still missing the benefits part of this change.
The benefits are that the user can parse and generate class files directly from
and to mapped files, and parse class files directly from buffers given to a
class loader (fo
> Provide method overloads to the ClassFile interface of the
> java.lang.classfile API which allow parsing of classes found in memory
> segments, as well as allowing built class files to be output to them.
David M. Lloyd has updated the pull request incrementally with one additiona
On Tue, 25 Mar 2025 15:27:05 GMT, David M. Lloyd wrote:
>> Provide method overloads to the ClassFile interface of the
>> java.lang.classfile API which allow parsing of classes found in memory
>> segments, as well as allowing built class files to be output to them.
>
> Provide method overloads to the ClassFile interface of the
> java.lang.classfile API which allow parsing of classes found in memory
> segments, as well as allowing built class files to be output to them.
David M. Lloyd has updated the pull request incrementally with two additional
> Provide method overloads to the ClassFile interface of the
> java.lang.classfile API which allow parsing of classes found in byte buffers
> and memory segments, as well as allowing built class files to be output to
> these types.
David M. Lloyd has updated the pull request increm
On Thu, 20 Mar 2025 21:11:41 GMT, Chen Liang wrote:
>> Provide method overloads to the ClassFile interface of the
>> java.lang.classfile API which allow parsing of classes found in byte buffers
>> and memory segments, as well as allowing built class files to be output to
>> these types.
>
> sr
Provide method overloads to the ClassFile interface of the java.lang.classfile
API which allow parsing of classes found in byte buffers and memory segments,
as well as allowing built class files to be output to these types.
-
Commit messages:
- 8352536: Add overloads to parse and b
On Thu, 2 Jan 2025 17:13:17 GMT, David M. Lloyd wrote:
> When loading services by class loader
> (`ServiceLoader.load(Class,ClassLoader)`), the module layers bound to the
> given class loader are searched for services, along with the layers bound to
> class loader's parent, a
When loading services by class loader
(`ServiceLoader.load(Class,ClassLoader)`), the module layers bound to the given
class loader are searched for services, along with the layers bound to class
loader's parent, and so on. For non-hierarchical class loader arrangements,
this breaks down because
On Wed, 18 Dec 2024 18:03:50 GMT, David M. Lloyd wrote:
>> Custom module layers allow for lazy loading, late binding, and full
>> customization of module dependencies through the `Controller` API. However,
>> it is not possible for custom layer users to late-bind s
On Tue, 17 Dec 2024 16:29:13 GMT, David M. Lloyd wrote:
> Custom module layers allow for lazy loading, late binding, and full
> customization of module dependencies through the `Controller` API. However,
> it is not possible for custom layer users to late-bind services, which has
&g
oving to use Java modules.
>
> Add an API to `ModuleLayer.Controller` to allow adding `uses` and `provides`
> relationships after a module has been defined for custom layers.
David M. Lloyd has updated the pull request incrementally with one additional
commit since the last revision:
Ad
oving to use Java modules.
>
> Add an API to `ModuleLayer.Controller` to allow adding `uses` and `provides`
> relationships after a module has been defined for custom layers.
David M. Lloyd has updated the pull request incrementally with one additional
commit since the last revi
Custom module layers allow for lazy loading, late binding, and full
customization of module dependencies through the `Controller` API. However, it
is not possible for custom layer users to late-bind services, which has
prevented some popular application containers from moving to use Java modules
On Thu, 28 Nov 2024 15:22:18 GMT, Jorn Vernee wrote:
>> Allow `captureCallState` and `critical(true)` linker options to be combined.
>> This allows passing a Java array to capture call state.
>>
>> One caveat is that the linker expects the memory to be aligned, which means
>> that at least an
On Thu, 26 Sep 2024 13:30:07 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 eliminate a
&g
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 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
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, 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, 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
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
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 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 M. L
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()
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 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 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 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, 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 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
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
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, 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
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
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, 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 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 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
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.
> 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
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
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 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
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
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
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 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
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
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 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 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 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
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 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
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 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 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 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 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
> 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 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
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
> 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 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
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
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 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-"
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 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 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 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 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 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 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.
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 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:
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 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
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 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 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 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 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
1 - 100 of 133 matches
Mail list logo
