Re: [Jython-users] Overloaded Java method handing changes between 2.7.2 and 2.7.3?

[Jeff A. <ja...@fa...>]

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
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-users

-- 

Jeff Allen