Re: Overloaded Java method handing changes between 2.7.2 and 2.7.3?

Adam Burke <[email protected]> Fri, 7 Jun 2024 21:41:50 +1000
Newsgroups gmane.comp.lang.jython.user
Message-ID <[email protected]>
--===============8384342728827445830==
Content-Type: multipart/alternative; boundary=Apple-Mail-BF2DA319-012B-4A5A-B2FC-11D893523821
Content-Transfer-Encoding: 7bit


--Apple-Mail-BF2DA319-012B-4A5A-B2FC-11D893523821
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div>Would just add the small footnote that=
 default-but-not-contracted sort orders have changed across JVM versions in t=
he past.</div><br id=3D"lineBreakAtBeginningOfSignature"><div dir=3D"ltr">Ad=
am</div><div dir=3D"ltr"><br><blockquote type=3D"cite">=E5=9C=A8 2024=E5=B9=B4=
6=E6=9C=887=E6=97=A5=EF=BC=8C=E4=B8=8B=E5=8D=888:10=EF=BC=8CJeff Allen &lt;j=
[email protected]&gt; =E5=86=99=E9=81=93=EF=BC=9A<br><br></blockquote></div>=
<blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF

 =20
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-8"=
>
 =20
 =20
    <div class=3D"moz-cite-prefix">This is maybe better as an issue,
      although it sounds like one that already defeated us.<br>
    </div>
    <div class=3D"moz-cite-prefix"><br>
    </div>
    <div class=3D"moz-cite-prefix">1. The code by which a call is matched
      to a method always looked somewhat heuristic to me. (I believe
      this comes from a Greek word meaning "luck".) As I understand it,
      it takes the first match, a match ocurring where the arguments say
      they can produce the Java type in the signature. The sort order of
      overloaded methods is therefore important. I think "What Would
      Java Do?" is the aspiration, but I suspect this cannot be achieved
      just by sorting. (Have we changed the sort? I didn't think so.)
      The best expression of expected behaviour is probably in the tests
      `test_joverload.py` and `javatests/Reflection.java`.</div>
    <div class=3D"moz-cite-prefix"><br>
    </div>
    <div class=3D"moz-cite-prefix">2. There has been some work in the
      matching to address variable numbers of arguments, so some code
      change, late in 2.7.3 (I think) and in 2.7.4 (currently in beta).
      I might have blamed:
<a class=3D"moz-txt-link-freetext" href=3D"https://github.com/jython/jython/=
commit/dd271a5edaa06925d45ef2d1477e3ec1cf6adfc7">https://github.com/jython/j=
ython/commit/dd271a5edaa06925d45ef2d1477e3ec1cf6adfc7</a>
      but I think it is later than you need to explain the change.
      However, I think it is a good place to start. These are the source
      files right files (probably).&nbsp; Another possible cause is in
      "normalisations" that can occur during assignment which I think we
      tweaked (to solve another problem, not just for the heck of it).<br>
    </div>
    <div class=3D"moz-cite-prefix"><br>
    </div>
    <div class=3D"moz-cite-prefix">3. You're asking to hook the
      `__tojava__` methods, which I don't *think* you can do. It would
      be on built-in types too.<br>
    </div>
    <div class=3D"moz-cite-prefix"><br>
    </div>
    <div class=3D"moz-cite-prefix">How is it with 2.7.4b2? I think I
      wouldn't delay 2.7.4 for this, but there's always a small hope
      your problem has gone away.<br>
    </div>
    <div class=3D"moz-cite-prefix"><br>
    </div>
    <div class=3D"moz-cite-prefix">Bets wishes,<br>
    </div>
    <div class=3D"moz-cite-prefix">Jeff<br>
    </div>
    <div class=3D"moz-cite-prefix"><br>
    </div>
    <div class=3D"moz-cite-prefix"><br>
    </div>
    <div class=3D"moz-cite-prefix">On 06/06/2024 22:38, John Hubbard
      wrote:<br>
    </div>
    <blockquote type=3D"cite" cite=3D"mid:CAO2imXwGeO1Gh+1i1zT0gAWX0mzoMNzvH=
[email protected]">
      <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-=
8">
      <div dir=3D"ltr">
        <div dir=3D"ltr">Hello,&nbsp;</div>
        <div dir=3D"ltr"><br>
        </div>
        <div dir=3D"ltr">Has something changed between Jython 2.7.2 and
          Jython 2.7.2 with regards to how calls from Jython to an
          overloaded Java method are resolved?&nbsp;&nbsp;<br>
          <div><br>
          </div>
          <div><b>Background</b><br>
          </div>
          <div>I am trying to update our application from Jython 2.7.2
            to Jython 2.7.3 and I have run into what I think is a change
            in how Jython handles overloaded Java methods.&nbsp; The primary=

            motivation for the update is proper handling of * imports
            under JDK 17 (and JUnit 5); see Jython GitHub issues 105,
            304 and maybe 309.&nbsp;&nbsp;</div>
          <div><br>
          </div>
          <div>Our application is primarily Java based but uses Jython
            for high level scripts which perform high level sequencing.&nbsp=
;
            One of the most common things those scripts do is construct
            'bags of data' which are handled by our AttributeTable class
            (full jdoc <a href=3D"https://share.nso.edu/shared/dkist/jhubbar=
d/atst/atst/cs/interfaces/IAttributeTable.html" target=3D"_blank" moz-do-not=
-send=3D"true">here</a>).&nbsp; That
            class is backed by a Map&lt;String, String[]&gt; and stores
            heterogenous data via various via getters and setters like:</div=
>
          <blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0=
px">
            <div><font face=3D"monospace">insert(String name, String
                value)</font></div>
            <div><font face=3D"monospace">insert(String name, int value)</fo=
nt></div>
          </blockquote>
          <blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0=
px">
            <div><font face=3D"monospace">insert(String name, boolean
                value)</font></div>
          </blockquote>
          <blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0=
px">
            <div><font face=3D"monospace">...</font></div>
          </blockquote>
          <blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0=
px">
            <div><font face=3D"monospace">String getString(String name)</fon=
t></div>
          </blockquote>
          <blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0=
px">
            <div><font face=3D"monospace">int getInt(String name)</font></di=
v>
          </blockquote>
          <div><br>
          </div>
          <div>With Jython 2.7.2 I could could write a script like:</div>
          <blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0=
px">
            <div><font face=3D"monospace">tbl =3D AttributeTable();</font></=
div>
            <div><font face=3D"monospace">name =3D 'name'</font></div>
            <div><font face=3D"monospace">value =3D 27</font></div>
            <div><font face=3D"monospace">tbl.insert(name, value)</font></di=
v>
          </blockquote>
          <div>and it would behave as expected.&nbsp; Jython would resolve
            the insert call to&nbsp; the Java AttributeTable.insert(String,
            int) method, the Java side would then convert the integer 27
            into the String "27" and store it in the map for later
            use.&nbsp;&nbsp;</div>
          <div><br>
          </div>
          <div><b>Problem</b></div>
          <div>With Jython 2.7.3 I think that the truthiness of the
            value is being evaluated and AttributeTable.insert(String,
            boolean)&nbsp;is what is getting triggered.&nbsp; For example th=
e
            following code:</div>
        </div>
        <blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px">
          <div>
            <div>
              <div><font face=3D"monospace">def savePropertyValue(appName,
                  propertyName, propertyValue):</font></div>
            </div>
          </div>
          <div>
            <div>
              <div><font face=3D"monospace">&nbsp; print('savePropertyValue(=
' +
                  str(appName) + ', ' + str(propertyName)</font></div>
            </div>
          </div>
          <div>
            <div>
              <div><font face=3D"monospace">&nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; + ', ' +
                  str(propertyValue) + ')')</font></div>
            </div>
          </div>
          <div>
            <div>
              <div><font face=3D"monospace">&nbsp; at =3D AttributeTable()</=
font></div>
            </div>
          </div>
          <div>
            <div>
              <div><font face=3D"monospace">&nbsp; at.insert(propertyName,
                  propertyValue)</font></div>
            </div>
          </div>
          <div>
            <div>
              <div><font face=3D"monospace">&nbsp; at.show('savePropertyValu=
e()
                  AttributeTable ')</font></div>
            </div>
          </div>
        </blockquote>
        <div dir=3D"ltr">
          <div>produces&nbsp;</div>
        </div>
        <blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px">
          <div dir=3D"ltr">
            <div><font face=3D"monospace">savePropertyValue(atst.ics.visp,
                atst.ics.visp.slitStepSz, 0.05)<br>
                savePropertyValue() AttributeTable
                atst.ics.visp.slitStepSz: true</font><br>
            </div>
          </div>
        </blockquote>
        <div dir=3D"ltr">
          <div><br>
          </div>
          <div>So the value 0.05 was passed into the jython
            savePropertyValue function but what ended up being inserted
            into the Java AttributeTable object was the boolean true.&nbsp;&=
nbsp;</div>
          <div><br>
          </div>
          <div><b>Questions</b></div>
          <div>
            <ol>
              <li>What is the expected behavior when interacting with
                overloaded Java objects?&nbsp; Were we just lucky before and=

                this was never expected to work?</li>
              <li>Is anyone aware of changes on the Java side that may
                have triggered this?&nbsp; I'd like some background on what
                might have caused this so I can investigate what might
                be improved to fix this.</li>
              <li>Is it possible to inject custom PyObject --&gt; Java
                Object coercion routines?&nbsp; The interpreters are setup a=
t
                a high level; if I could mask the Java AttributeTable
                class with a Python class that better handled overloaded
                methods and then somehow coerce/convert it to an Java
                AttributeTable before sending it back into Java land I
                might be able to work around this.</li>
            </ol>
            <div>Thanks</div>
          </div>
          <div><br>
          </div>
          <div>
            <div>
              <div dir=3D"ltr" class=3D"gmail_signature">
                <div dir=3D"ltr">--
                  <div>Cheers</div>
                  <div>-john</div>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class=3D"moz-mime-attachment-header"></fieldset>
      <br>
      <fieldset class=3D"moz-mime-attachment-header"></fieldset>
      <pre class=3D"moz-quote-pre" wrap=3D"">_______________________________=
________________
Jython-users mailing list
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:[email protected]=
ceforge.net">[email protected]</a>
<a class=3D"moz-txt-link-freetext" href=3D"https://lists.sourceforge.net/lis=
ts/listinfo/jython-users">https://lists.sourceforge.net/lists/listinfo/jytho=
n-users</a>
</pre>
    </blockquote>
    <pre class=3D"moz-signature" cols=3D"72">--=20

Jeff Allen
</pre>
 =20

<span>_______________________________________________</span><br><span>Jython=
-users mailing list</span><br><span>[email protected]</span=
><br><span>https://lists.sourceforge.net/lists/listinfo/jython-users</span><=
br></div></blockquote></body></html>=

--Apple-Mail-BF2DA319-012B-4A5A-B2FC-11D893523821--


--===============8384342728827445830==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============8384342728827445830==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Jython-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jython-users

--===============8384342728827445830==--