Re: [External] : Re: New candidate JEP: 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

On Thu, Jun 13, 2024 at 9:01 AM Alan Bateman wrote: > On 13/06/2024 14:22, David Lloyd wrote: > > : > > I've updated with a few commits today which solve (I think) the access > control issue, moves constant descriptors to constants in a holder class, > moves the bootst

Re: [External] : Re: New candidate JEP: 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

On Thu, Jun 13, 2024 at 8:39 AM Alan Bateman wrote: > On 12/06/2024 15:23, David Lloyd wrote: > > > : > . > > I have a *very* rough prototype up [1]. It adds two new accessor methods > to `ReflectionFactory`: `defaultReadObjectForSerialization` and > `defaultWriteObje

Re: [External] : Re: New candidate JEP: 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

On Wed, Jun 12, 2024 at 9:23 AM David Lloyd wrote: > > > On Tue, Jun 11, 2024 at 1:08 PM David Lloyd > wrote: > >> >> >> On Tue, Jun 11, 2024 at 12:57 PM Alan Bateman >> wrote: >> >>> >>> >>> On 11/06/2024 18:19, Dav

Re: [External] : Re: New candidate JEP: 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

On Tue, Jun 11, 2024 at 1:08 PM David Lloyd wrote: > > > 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 w

Re: [External] : Re: New candidate JEP: 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

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. I

Re: [External] : Re: New candidate JEP: 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

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 t

Re: [External] : Re: New candidate JEP: 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

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 > wr

Re: [External] : Re: New candidate JEP: 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

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 f

Re: [External] : Re: New candidate JEP: 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

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 t

Re: [External] : Re: New candidate JEP: 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

constructor of another class. > > I strongly support your proposal to restrict ReflectionFactory. > > Regards, Chen > > On Wed, May 15, 2024 at 6:23 PM David Lloyd > wrote: > >> >> >> On Tue, May 14, 2024 at 10:01 AM David Lloyd >> wrote: >> >&g

Re: [External] : Re: New candidate JEP: 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

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 &

Re: [External] : Re: New candidate JEP: 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

(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 c

Re: [External] : Re: New candidate JEP: 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

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 s

Re: Generalizing binary search

On Thu, Apr 25, 2024 at 2:09 PM Pavel Rappo wrote: > > > > On 25 Apr 2024, at 19:41, David Lloyd wrote: > > > > The JDK contains a few collection- and array-oriented implementations of > binary search. For the most part, they all work the same way: search the > tar

Generalizing binary search

The JDK contains a few collection- and array-oriented implementations of binary search. For the most part, they all work the same way: search the target "thing" by index using the obvious bisection strategy, returning either /index/ or /-index-1/ depending on whether it was found at the end of the

Re: Vector (and integer) API: unsigned min/max

tor) search, so we may do something there for > specific integral types. > > Paul. > > > On Apr 17, 2024, at 7:13 AM, David Lloyd wrote: > > > > I've been trying the the incubating Vector API and one thing I've missed > on integer-typed vectors is having uns

Vector (and integer) API: unsigned min/max

I've been trying the the incubating Vector API and one thing I've missed on integer-typed vectors is having unsigned min/max operations. There is a signed min/max operation, and unsigned comparison, but no unsigned min/max. I guess this is for symmetry with `Math`, which only has signed `min`/`max

Re: Revisiting JDK-4512189: ZipConstants leaking into public APIs

On Tue, Nov 28, 2023 at 10:38 AM Eirik Bjørsnøs wrote: > > > On Tue, Nov 28, 2023 at 5:28 PM David Lloyd > wrote: > >> I agree, I always thought that this was a bizarre thing to expose in a >> public API so it being accidental does explain things. But maybe the

Re: Revisiting JDK-4512189: ZipConstants leaking into public APIs

On Tue, Nov 28, 2023 at 10:01 AM Eirik Bjørsnøs wrote: > Hi, > > JDK-4512189 [1] raised the issue that ZipFile, ZipEntry, ZipInputStream > and ZipOutputStream all implement the non-public ZipConstants interface. > While the interface itself is non-public, the constants defined > unfortunately lea

Re: Unsigned long to double and back

do the conversion to double and if the > sign bit was present (if value < 0) add Long.MAX_VALUE + 1 > (9223372036854775808) as a double. > > I've got 9.223372036854776E18 as the result of > BigInteger.valueOf(Long.MAX_VALUE).add(BigInteger.ONE).doubleValue() > > Rém

Re: Unsigned long to double and back

Well, I typed this out from memory so there's an error, of course. `(tmp & 1)` should be `(input & 1)`. On Fri, Nov 11, 2022 at 8:31 AM David Lloyd wrote: > I encountered this issue as well; for now I'm using the following > transformation: > > long tmp = input >

Re: Unsigned long to double and back

I encountered this issue as well; for now I'm using the following transformation: long tmp = input >>> 1; double output = ((double) tmp) * 2.0 + (tmp & 1); I... *think* it's correct but I'm not 100% sure and have a long-standing TODO to try and figure it out... On Sat, Nov 5, 2022 at 7:17 PM Joh

Re: Handling of USR2 signal in JVM on Linux

On Fri, Jun 17, 2022 at 1:05 AM Thomas Stüfe wrote: >> >> >> > > >> > > I see your point. I dislike crashes, especially ones they can be >> > > reliably triggered from outside. You never can be sure about the >> > > security implications either. >> > > >> > > If you dislike ignoring the signal, an

Re: Handling of USR2 signal in JVM on Linux

On Thu, Jun 16, 2022 at 8:17 AM David Holmes wrote: > On 16/06/2022 12:09 am, Thomas Stüfe wrote: > > On Wed 15. Jun 2022 at 15:06, David Holmes > > wrote: > > Nor do I. SIGUSR2 is reserved for use by the VM and we document > > that. If > > you start th