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

[John H. <jhu...@ns...>]

Thanks Jeff for the quick reply.

The GH-221 tickets that the commit addressed sounds kind of like this
because our AttributeTable class does in fact use varargs but there is a
comment[1] in the ticket for what sounds exactly like my issue and
tpoliaw's reply suggests that this isn't intended to fix it though.

I went ahead and built the latest version of master locally and used that
for testing and unfortunately it doesn't address my problem.  Now that I've
actually built this myself, and armed with a pointer at where to look, I'll
see if I can identify where things changed and work on a solution.  Don't
worry about holding off on a 2.7.4 on our account.

Thanks again!

[1] https://github.com/jython/jython/issues/221#issuecomment-1784005688
--
Cheers
-john


On Fri, Jun 7, 2024 at 4:10 AM Jeff Allen <ja...@fa...> wrote:

> 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 lis...@li...https://lists.sourceforge.net/lists/listinfo/jython-users
>
> --
>
> Jeff Allen
>
> _______________________________________________
> Jython-users mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-users
>