<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">(Moving to core-libs-dev)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 14, 2024 at 9:40 AM Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com">Alan.Bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
  <div>
    On 14/05/2024 14:42, David Lloyd wrote:<br>
    <blockquote type="cite">
      
      <div dir="ltr"><div class="gmail_quote"><div><div style="font-family:arial,helvetica,sans-serif">ReflectionFactory
              allows access to serialization facilities without any
              access checking (other than the defunct SecurityManager
              checks). Perhaps this class could gain some more methods,
              like this:</div>
            <div style="font-family:arial,helvetica,sans-serif"><br>
            </div>
            <div style="font-family:arial,helvetica,sans-serif">*
              `newGetterForSerialization(Field field)` - includes
              ability to access `objectStreamFields` and
              `serialVersionUID`, or these could be separate methods</div>
            <div style="font-family:arial,helvetica,sans-serif">*
              `newSetterForSerialziation(Field field)`</div>
          </div>
          <div><br>
          </div>
          <div>
            <div style="font-family:arial,helvetica,sans-serif">Does this
              seem workable?</div>
            <br>
          </div>
        </div>
      </div>
    </blockquote>
    The intention with ReflectionFactory is that serialization libraries
    go through the readObject/writeObject and other magic methods, to
    avoid field access.<br>
    <br>
    Probably best to being this to core-libs-dev for further discussion.<br></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">This doesn't match my recollection. The `readObject` and `writeObject` methods are optional private methods which serializable classes *may* provide when they want a bespoke serialization strategy (and the other methods that are accessed via this special class are similar in this regard). They are not in any way magical in that they do not provide the means to perform this part of the serialization process, and thus they are not a substitute for field access in serialization. According to JDK-8164908, these methods were added because at the time, Unsafe was still state of the art for custom serialization and IIOP to access fields (with libraries using Field actively moving to Unsafe instead). However Unsafe did not and does not provide access to methods, so in order to avoid the aforementioned `add-opens` explosion, these methods were added as a compromise. Now that Unsafe is being deprecated, it is my opinion that this does need to be revisited because at the time, Unsafe was the recommended approach.</div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">[1] <a href="https://bugs.openjdk.org/browse/JDK-8164908">https://bugs.openjdk.org/browse/JDK-8164908</a></div><br></div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">- DML • he/him<br></div></div></div>