<div dir="ltr"><div dir="ltr">Em sex., 15 de set. de 2023 às 11:48, Rony G. Flatscher <<a href="mailto:Rony.Flatscher@wu.ac.at">Rony.Flatscher@wu.ac.at</a>> escreveu:</div><div dir="ltr"><br></div><div class="gmail_quote"><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">
    </blockquote>
    <p>Actually the code already is able to configure the JVM. However,
      this can be done only, if BSF4ooRexx loads the JVM (and the
      environment variable BSF4Rexx_JavaStartupOptions is set). It
      cannot be done if the JVM got already loaded by someone else and
      the BSF4ooRexx bridge gets loaded into the process.</p></div></blockquote><div><br></div><div>Whoever sets up the JVM must maintain the JVM initialization flags.</div><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>I cannot visualize what hypothetical situation is this in which whoever assembles the application and sets up the JVM is somehow incompetent or incapable to apply this change.</div><div>Are we considering situations where people blindly upgrade components of their architecture with no preparation nor testing to only discover the consequences in production?</div></div><div><br></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>