Menu
▾
▴
Re: [Jython-users] Overloaded Java method handing changes between 2.7.2 and 2.7.3?
|
From: John H. <jhu...@ns...> - 2024-06-10 19:45:45
|
Jeff, Thanks again for pointing me in the right direction. For anyone else who stumbles across this thread I tracked the issue down and have opened [1]. [1] https://github.com/jython/jython/issues/335 -- Cheers -john On Fri, Jun 7, 2024 at 4:52 PM John Hubbard <jhu...@ns...> wrote: > 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 >> > |
