Message11924

Author jeff.allen
Recipients jeff.allen, zyasoft
Date 2018-04-27.22:34:38
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1524868479.37.0.682650639539.issue2662@psf.upfronthosting.co.za>
In-reply-to
Content
I've dealt with most of the warnings about PyReflectedFunction by defining a test of accessibility that takes into account whether the containing package is exported to the unnamed module. Of course, the apparatus for that doesn't exist until Java 9, not even the class Module, but I access it reflectively so I can fail safely on Java 7.

I include the test here where currently we test for "public":
https://hg.python.org/jython/file/tip/src/org/python/core/PyJavaType.java#l383

This fixes it in all cases where the inaccessible class has a parent that is accessible (exported), but it fails for the ISO2022_JP_2 codec where the parent is ISO2022_JP which is still not accessible. I'll see if I simply need to include the same test here:
https://hg.python.org/jython/file/tip/src/org/python/core/PyJavaType.java#l1086
but what bugs me about that is that the test comes after we already processed the implementation of the method as found in the immediate parent. Surely we ought to go up the tree until we find a public API of which this is merely the implementation?

There are a lot of things about the way we build a PyReflectedFunction that do not seem quite right to me. Done right, I sense we might eliminate the need to disrespect Java accessibility in almost every case.
History
Date User Action Args
2018-04-27 22:34:39jeff.allensetmessageid: <1524868479.37.0.682650639539.issue2662@psf.upfronthosting.co.za>
2018-04-27 22:34:39jeff.allensetrecipients: + jeff.allen, zyasoft
2018-04-27 22:34:39jeff.allenlinkissue2662 messages
2018-04-27 22:34:38jeff.allencreate