Issue1438

classification
Title: respectJavaAccessibility=False changes behavior
Type: behaviour Severity: major
Components: Core Versions: 2.5.0
process
Status: closed Resolution: invalid
Dependencies: Superseder:
Assigned To: Nosy List: cgroves, fabioz
Priority: Keywords:

Created on 2009-08-15.23:11:08 by fabioz, last changed 2009-08-16.10:44:50 by cgroves.

Messages
msg5032 (view) Author: Fabio Zadrozny (fabioz) Date: 2009-08-15.23:11:07
When running with the -Dpython.security.respectJavaAccessibility=false,
the way the code is run which can break programs.

E.g.: 

The code:

frame = JFrame()
frame.visible = True 

will call the setVisible() method, whereas with
respectJavaAccessibility=False it will change the internal variable
'visible'.

This shouldn't happen... when there's a set/get for it, that should be
used as the default access regardless of respectJavaAccessibility (maybe
those internal variables could be exposed with some sort of name
mangling, as python does for its internal variables).

Note: This is pretty important for the pydev debugger, as it'll run with
respectJavaAccessibility=False to be able to gather information on the
java classes, but with that change, the behavior is so different from
running without that flag that it becomes unusable on code using the
property access (and without it, it cannot get information on the java
fields, which is pretty important too). 

Another option would be removing the property access altogether and
force users to use the set/get methods, but I guess that could break
many clients already using it.
msg5044 (view) Author: Charlie Groves (cgroves) Date: 2009-08-16.10:44:50
I'm afraid no matter what, respectJavaAccessibility is going to change what things are available to Python. My 
preference has always been to make it act as close to regular lookup as possible, just making everything public.  That 
makes it more sane for a user trying to figure out what is being exposed as it doesn't have a completely different set 
of rules.

Basically, respectJavaAccessibility is a hack, and I don't think it should be used for anything other than interactive 
exploration.  If I were implementing Jython from scratch, there's no way I would've added it, and I'm hoping to remove 
it altogether in Jy3k.  I highly recommend that you use regular Java reflection to look things in pydev.  It'll be much 
more reliable.
History
Date User Action Args
2009-08-16 10:44:50cgrovessetstatus: open -> closed
resolution: invalid
messages: + msg5044
nosy: + cgroves
2009-08-15 23:11:08fabiozcreate