On Tue, Jun 11, 2024 at 12:57 PM Alan Bateman
wrote:
>
>
> On 11/06/2024 18:19, David Lloyd wrote:
>
> :
>
> I thought that might be where Alan was headed with this. I would support
> this solution; it would solve the problem for conformant serialization
> libraries. If a class has a
> On 11 Jun 2024, at 18:19, David Lloyd wrote:
>
> I would support this solution; it would solve the problem for conformant
> serialization libraries. If a class has a `readObject`/etc. then we use it -
> we wouldn't care if it was "natural" or generated. This also gives us the
> option to
On 11/06/2024 18:19, David Lloyd wrote:
:
I thought that might be where Alan was headed with this. I would
support this solution; it would solve the problem for conformant
serialization libraries. If a class has a `readObject`/etc. then we
use it - we wouldn't care if it was "natural" or
On Tue, Jun 11, 2024 at 11:58 AM Ron Pressler
wrote:
>
>
> > On 11 Jun 2024, at 17:27, David Lloyd wrote:
> >
> >
> >
> > On Tue, Jun 11, 2024 at 10:17 AM Alan Bateman
> wrote:
> > On 06/06/2024 18:37, David Lloyd wrote:
> >> Just bumping this one more time. I intend to start by opening a JIRA
> On 11 Jun 2024, at 17:27, David Lloyd wrote:
>
>
>
> On Tue, Jun 11, 2024 at 10:17 AM Alan Bateman wrote:
> On 06/06/2024 18:37, David Lloyd wrote:
>> Just bumping this one more time. I intend to start by opening a JIRA to add
>> the two proposed methods to `ReflectionFactory`, and go
On Tue, Jun 11, 2024 at 11:38 AM Alan Bateman
wrote:
>
>
> On 11/06/2024 17:27, David Lloyd wrote:
>
> :
>
> Yes, all of the method-access methods on ReflectionFactory are used, not
> just for readObject/writeObject but also readObjectNoData, readResolve, and
> writeReplace, the constructor
On 11/06/2024 17:27, David Lloyd wrote:
:
Yes, all of the method-access methods on ReflectionFactory are used,
not just for readObject/writeObject but also readObjectNoData,
readResolve, and writeReplace, the constructor accessors, and the
factory methods for OptionalDataException. We
On Tue, Jun 11, 2024 at 10:17 AM Alan Bateman
wrote:
> On 06/06/2024 18:37, David Lloyd wrote:
>
> Just bumping this one more time. I intend to start by opening a JIRA to
> add the two proposed methods to `ReflectionFactory`, and go from there. I
> guess that we might need a JEP for the proposed
On 06/06/2024 18:37, David Lloyd wrote:
Just bumping this one more time. I intend to start by opening a JIRA
to add the two proposed methods to `ReflectionFactory`, and go from
there. I guess that we might need a JEP for the proposed serialization
restrictions, which is going to be
On Fri, Jun 7, 2024 at 1:19 PM Ron Pressler wrote:
>
> > On 6 Jun 2024, at 18:37, David Lloyd wrote:
> >
> > Just bumping this one more time. I intend to start by opening a JIRA to
> add the two proposed methods to `ReflectionFactory`, and go from there. I
> guess that we might need a JEP for
> On 6 Jun 2024, at 18:37, David Lloyd wrote:
>
> Just bumping this one more time. I intend to start by opening a JIRA to add
> the two proposed methods to `ReflectionFactory`, and go from there. I guess
> that we might need a JEP for the proposed serialization restrictions, which
> is going
Just bumping this one more time. I intend to start by opening a JIRA to add
the two proposed methods to `ReflectionFactory`, and go from there. I guess
that we might need a JEP for the proposed serialization restrictions, which
is going to be considerably more involved, so I'm putting that off as
Indeed, ReflectionFactory. newConstructorForSerialization can be used to
access otherwise-private constructors. Before JDK-8315810, it could even
allocate one class and call the constructor of another class.
I strongly support your proposal to restrict ReflectionFactory.
Regards, Chen
On Wed,
On Tue, May 14, 2024 at 10:01 AM David Lloyd wrote:
> (Moving to core-libs-dev)
>
> On Tue, May 14, 2024 at 9:40 AM Alan Bateman
> wrote:
>
>> On 14/05/2024 14:42, David Lloyd wrote:
>>
>> ReflectionFactory allows access to serialization facilities without any
>> access checking (other than the
(Moving to core-libs-dev)
On Tue, May 14, 2024 at 9:40 AM Alan Bateman
wrote:
> On 14/05/2024 14:42, David Lloyd wrote:
>
> ReflectionFactory allows access to serialization facilities without any
> access checking (other than the defunct SecurityManager checks). Perhaps
> this class could gain
On Fri, May 3, 2024 at 1:20 PM Ron Pressler wrote:
>
>
> > On 3 May 2024, at 18:33, David Lloyd wrote:
> > It seems to me that the JDK could fill this gap by introducing some API
> which can construct and provide access to an array or something like it,
> with striding and/or alignment
P.S. I didn’t directly address David’s request for that magic number N.
I would just assume 32 bits as the conservative element size (for oops)
and work from there. If the cache line size is 64 bytes, then N=16.
These are robust assumptions, even if they waste a little space
when N could be 8
Some of these sorts of use cases could be covered by somehow discovering
a platform-specific parameter N such that a[I] and a[I+N] are not likely
to have false sharing in a data cache, for any I. (Or a series of N0,
N1, … that prevent a[N0], a[N1]… from being falsely shared.) David is
right that
> On 3 May 2024, at 18:33, David Lloyd wrote:
>
>
> On Fri, May 3, 2024 at 10:12 AM Mark Reinhold
> wrote:
> https://openjdk.org/jeps/471
>
> Summary: Deprecate the memory-access methods in sun.misc.Unsafe for
> removal in a future release.
>
>
> We still use Unsafe fairly often in
19 matches
Mail list logo
