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
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 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, 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
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 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, 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
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
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
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 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
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
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, 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.
David M. Lloyd has updated the pull request increm
> 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
> 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 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.
>
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
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 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 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 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, 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 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 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
> 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
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.
>
101 - 133 of 133 matches
Mail list logo
