Message12898

Author jeff.allen
Recipients FraOrolo, jeff.allen, zyasoft
Date 2019-12-25.14:32:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1577284351.32.0.0932380536268.issue2834@roundup.psfhosted.org>
In-reply-to
Content
I have also had some time to experiment (between presents and lunch).

I am not able to create a failure with my test program that imports * from javax.swing.Utilities (a class we won't already have imported, providing static methods as in the OPs case). I've written a unit test where we try to import to an interpreter in a Java Thread (or rather, lots of them). It would be good to have some concurrency unit tests as standard.

I currently suspect logic in the vicinity of PyJavaPackage. I notice that when found by the JavaImporter, the __dict__ of a PyJavaPackage contains entries only for __name__ and further packages. The classes and their attributes seem to get filled in later.

Finding the package happens under the import lock, and the import lock is taken again when filling in (I think), but I'm not yet sure the package can't escape between times. Does the import lock (per system state) anyway really protect objects that come (I think) from a shared structure?

It might be another case of assuming objects need to be synchronised only when modifying them.
History
Date User Action Args
2019-12-25 14:32:31jeff.allensetmessageid: <1577284351.32.0.0932380536268.issue2834@roundup.psfhosted.org>
2019-12-25 14:32:31jeff.allensetrecipients: + jeff.allen, zyasoft, FraOrolo
2019-12-25 14:32:31jeff.allenlinkissue2834 messages
2019-12-25 14:32:31jeff.allencreate