Re: Overloaded Java method handing changes between 2.7.2 and 2.7.3?
Jeff Allen <[email protected]> Fri, 7 Jun 2024 10:37:08 +0100
| Newsgroups | gmane.comp.lang.jython.user |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============2660355449810218602==
Content-Type: multipart/alternative;
boundary="------------AfSGdTDJAL7u0n7VoVcl1Xow"
Content-Language: en-GB
This is a multi-part message in MIME format.
--------------AfSGdTDJAL7u0n7VoVcl1Xow
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
This is maybe better as an issue, although it sounds like one that
already defeated us.
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`.
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:
https://github.com/jython/jython/commit/dd271a5edaa06925d45ef2d1477e3ec1cf6adfc7
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). 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).
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.
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.
Bets wishes,
Jeff
On 06/06/2024 22:38, John Hubbard wrote:
> Hello,
>
> 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?
>
> *Background*
> 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. 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.
>
> Our application is primarily Java based but uses Jython for high level
> scripts which perform high level sequencing. One of the most common
> things those scripts do is construct 'bags of data' which are handled
> by our AttributeTable class (full jdoc here
> <https://share.nso.edu/shared/dkist/jhubbard/atst/atst/cs/interfaces/IAttributeTable.html>).
> That class is backed by a Map<String, String[]> and stores
> heterogenous data via various via getters and setters like:
>
> insert(String name, String value)
> insert(String name, int value)
>
> insert(String name, boolean value)
>
> ...
>
> String getString(String name)
>
> int getInt(String name)
>
>
> With Jython 2.7.2 I could could write a script like:
>
> tbl = AttributeTable();
> name = 'name'
> value = 27
> tbl.insert(name, value)
>
> and it would behave as expected. Jython would resolve the insert call
> to 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.
>
> *Problem*
> With Jython 2.7.3 I think that the truthiness of the value is being
> evaluated and AttributeTable.insert(String, boolean) is what is
> getting triggered. For example the following code:
>
> def savePropertyValue(appName, propertyName, propertyValue):
> print('savePropertyValue(' + str(appName) + ', ' + str(propertyName)
> + ', ' + str(propertyValue) + ')')
> at = AttributeTable()
> at.insert(propertyName, propertyValue)
> at.show('savePropertyValue() AttributeTable ')
>
> produces
>
> savePropertyValue(atst.ics.visp, atst.ics.visp.slitStepSz, 0.05)
> savePropertyValue() AttributeTable atst.ics.visp.slitStepSz: true
>
>
> 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.
>
> *Questions*
>
> 1. What is the expected behavior when interacting with overloaded
> Java objects? Were we just lucky before and this was never
> expected to work?
> 2. Is anyone aware of changes on the Java side that may have
> triggered this? I'd like some background on what might have
> caused this so I can investigate what might be improved to fix this.
> 3. Is it possible to inject custom PyObject --> Java Object coercion
> routines? The interpreters are setup at 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.
>
> Thanks
>
> --
> Cheers
> -john
>
>
> _______________________________________________
> Jython-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jython-users
--
Jeff Allen
--------------AfSGdTDJAL7u0n7VoVcl1Xow
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">This is maybe better as an issue,
although it sounds like one that already defeated us.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="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="moz-cite-prefix"><br>
</div>
<div class="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="moz-txt-link-freetext" href="https://github.com/jython/jython/commit/dd271a5edaa06925d45ef2d1477e3ec1cf6adfc7">https://github.com/jython/jython/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). 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="moz-cite-prefix"><br>
</div>
<div class="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="moz-cite-prefix"><br>
</div>
<div class="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="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Bets wishes,<br>
</div>
<div class="moz-cite-prefix">Jeff<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 06/06/2024 22:38, John Hubbard
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAO2imXwGeO1Gh+1i1zT0gAWX0mzoMNzvHWp=WqeGXZUp70U=jQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">Hello, </div>
<div dir="ltr"><br>
</div>
<div dir="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? <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. 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. </div>
<div><br>
</div>
<div>Our application is primarily Java based but uses Jython
for high level scripts which perform high level sequencing.
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="https://share.nso.edu/shared/dkist/jhubbard/atst/atst/cs/interfaces/IAttributeTable.html"
target="_blank" moz-do-not-send="true">here</a>). That
class is backed by a Map<String, String[]> and stores
heterogenous data via various via getters and setters like:</div>
<blockquote
style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div><font face="monospace">insert(String name, String
value)</font></div>
<div><font face="monospace">insert(String name, int value)</font></div>
</blockquote>
<blockquote
style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div><font face="monospace">insert(String name, boolean
value)</font></div>
</blockquote>
<blockquote
style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div><font face="monospace">...</font></div>
</blockquote>
<blockquote
style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div><font face="monospace">String getString(String name)</font></div>
</blockquote>
<blockquote
style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div><font face="monospace">int getInt(String name)</font></div>
</blockquote>
<div><br>
</div>
<div>With Jython 2.7.2 I could could write a script like:</div>
<blockquote
style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div><font face="monospace">tbl = AttributeTable();</font></div>
<div><font face="monospace">name = 'name'</font></div>
<div><font face="monospace">value = 27</font></div>
<div><font face="monospace">tbl.insert(name, value)</font></div>
</blockquote>
<div>and it would behave as expected. Jython would resolve
the insert call to 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. </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) is what is getting triggered. For example the
following code:</div>
</div>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div>
<div>
<div><font face="monospace">def savePropertyValue(appName,
propertyName, propertyValue):</font></div>
</div>
</div>
<div>
<div>
<div><font face="monospace"> print('savePropertyValue(' +
str(appName) + ', ' + str(propertyName)</font></div>
</div>
</div>
<div>
<div>
<div><font face="monospace"> + ', ' +
str(propertyValue) + ')')</font></div>
</div>
</div>
<div>
<div>
<div><font face="monospace"> at = AttributeTable()</font></div>
</div>
</div>
<div>
<div>
<div><font face="monospace"> at.insert(propertyName,
propertyValue)</font></div>
</div>
</div>
<div>
<div>
<div><font face="monospace"> at.show('savePropertyValue()
AttributeTable ')</font></div>
</div>
</div>
</blockquote>
<div dir="ltr">
<div>produces </div>
</div>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div dir="ltr">
<div><font face="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="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. </div>
<div><br>
</div>
<div><b>Questions</b></div>
<div>
<ol>
<li>What is the expected behavior when interacting with
overloaded Java objects? 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? 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 --> Java
Object coercion routines? The interpreters are setup at
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="ltr" class="gmail_signature">
<div dir="ltr">--
<div>Cheers</div>
<div>-john</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Jython-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/jython-users">https://lists.sourceforge.net/lists/listinfo/jython-users</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Jeff Allen
</pre>
</body>
</html>
--------------AfSGdTDJAL7u0n7VoVcl1Xow--
--===============2660355449810218602==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--===============2660355449810218602==
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
--===============2660355449810218602==--