<div dir="ltr"><div dir="ltr">Em sex., 15 de set. de 2023 às 12:34, Rony G. Flatscher <<a href="mailto:Rony.Flatscher@wu.ac.at">Rony.Flatscher@wu.ac.at</a>> escreveu:<br></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div>This person must add whatever initialization flags are
            appropriate and/or required whenever they become appropriate
            and/or required.</div>
          <div>Suppose this person assembles an application including
            component XPTO, and this person desires to upgrade XPTO to
            new version 123 that adds a new feature that uses the new
            FFI: during this upgrade, this person also adds
            --enable-native-access to the initialization flags, and all
            is good. If this person is not aware of this need, it will
            become aware during testing, because the JVM will alert of
            this necessity.</div>
        </div>
      </div>
    </blockquote>
    <p>This is about deployment scenarios where no new applications get
      created from scratch, but there are Java applications and little
      Java utilitiy programs, but also native applications and little
      native utilities that have been deployed with a JRE available,
      possibly for many years. Take also into account that older
      versions may be deployed on newer JREs and the like. This warning
      aimed at application authors should never be placed in front of
      (end) users.<br>
    </p>
    </div></blockquote></div><div><br></div><div>This hypothetical situation where warnings are shown to end users can only happen when the application is upgraded to (1) use a new JVM, and (2) use (a new version of a component that uses) the new restricted methods of the new FFI.<br></div><div>I have been reading the discussion on the new warnings and so far have not visualized a concrete situation where these two upgrades would happen in such a way that it is severely inconvenient to modify the application launcher to add new flags.</div><div><br></div><div>I can only assume that the deployment scenarios being considered are all about dropping modified JARs into preexisting CLASSPATHs of preinstalled applications with no other configuration action.</div><div>But such "on the fly upgrades" requires a level of module compatibility justified only by "bugfix" changes.</div><div>Upgrading the native bindings of an application does not seem to me a change to be made "on the fly" like this.</div><div>Even if the module ABI is preserved, this would be too severe a change.</div><div><br></div><div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Pedro Lamarão</div></div></div></div></div>