[x3d-public] python pyjnius mapping

John Carlson yottzumm at gmail.com
Tue May 14 23:13:21 PDT 2019


My best guess for addChild and setIS is to traverse up the hierarchy in reflect.py (override autoclass, include autoclass from reflect) and do not add empty or abstract methods to the classDict or something similar.  That’s the best thing I have right now.

Sent from Mail for Windows 10

From: Brutzman, Donald (Don) (CIV)
Sent: Tuesday, May 14, 2019 11:48 PM
To: John Carlson
Cc: X3D Graphics public mailing list
Subject: Re: python pyjnius mapping

On 5/14/2019 5:53 AM, John Carlson wrote:
> *The return value from many methods has an abstract class type*, would be my best guess.  I have found many instances in jsail.

you found many because this is correct use of Java.

> I can provide help finding them if necessary.  I would suggest searching for “public X3D” initially.

No need, they are correctly working and are all directly inspectable.

> When you point a finger, there’s three fingers pointing back at you.

If you are looking to blame guilty parties, that is a different job.  Good luck with that - not what I'm trying to do.  You have my applause + thanks, while code gets close scrutiny as we continue the debug journey.

Simply stated, I think what we are doing is trying to map X3DJSAIL Java classes and methods to a useful Python syntax through Pyjnius.  This is software engineering.  We have made much progress and still have some blockers while trying to coherently align object models in two similar-but-separate object-oriented programming languages.

A Java @Override annotation is... an annotation, a description, that a method deliberately overrides a similar one in a superclass.  It is persistent in docs but is not part of the object contract.  The methods themselves are part of the contract.  The @Override annotation is also used by the compiler to confirm that a method indeed has the role intended by the programmer, otherwise a warning is printed during compilation into bytecode.

	https://docs.oracle.com/javase/tutorial/java/annotations/predefined.html

Whenever a the type of method return value is cast to an abstract type, that is because it can be used equivalently by multiple concrete types implementing that same abstract type.  This is simply object-oriented Java, not something to fix per se.

Isolating instances exhibiting the problem can help us understand the mismatch better, but we have to remember that
(a) the jsail object hierarchy works,
(b) the abstract types are specifically defined in the X3D Architecture Specification,
(c) the SAI interfaces are defined in the X3D Java SAI Specification,
(d) the X3D design is intended to work satisfactorily across a variety of programming languages.

Tracking down .addChild within X3DJSAIL code generation will be complex, the X3D parent-child model is not trivial and we also have to honor X3D design requirements (b) and (c) above.   So even upon finding them all, there isn't something to do differently.

So I think the task remains, why does Pyjnius mapping deviate and get lost looking for methods in the wrong places, when there is an underlying Java design that works with methods in the right places?

Meanwhile:

e. I applied your memory settings to classpath.py - thanks, good catch, didn't fail, certainly looks good, but didn't seem to help the examples I tested.  Perhaps an incremental improvement in some of the build cases, perhaps something is needed in ant build.xml as well.  Revised version checked in:

================
# https://pyjnius.readthedocs.io/en/stable/api.html#jvm-options-and-the-class-path

import jnius_config

jnius_config.add_options('-Xss1g', '-Xmx8g')
jnius_config.set_classpath('.', 'c:/x3d-code/www.web3d.org/x3d/stylesheets/java/jars/X3DJSAIL.3.3.full.jar', '../../../jars/X3DJSAIL.3.3.full.jar')
================

f. Building on that idea, I also tried moving the block of import statements from HelloWorld.py into classpath.py but couldn't get that to work:

from org.web3d.x3d.jsail.Core.X3DObject import X3DObject as X3D
from org.web3d.x3d.jsail.fields.SFStringObject import SFStringObject as SFString
from org.web3d.x3d.jsail.Core.headObject import headObject as head
[...]

> John
> 
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
> 
> *From: *Brutzman, Donald (Don) (CIV) <mailto:brutzman at nps.edu>
> *Sent: *Monday, May 13, 2019 11:54 PM
> *To: *John Carlson <mailto:yottzumm at gmail.com>
> *Cc: *X3D Graphics public mailing list <mailto:x3d-public at web3d.org>
> *Subject: *Re: python pyjnius mapping
> 
> On 5/13/2019 4:13 AM, John Carlson wrote:
> 
>  > I see.  Great!  It’s like breaking the contract on purpose, but letting people know you did it.
> 
> yes, @Override annotation is useful
> 
>  > I understand now.  Just took a few nights sleep.  I’m catching up!  I’m usually 5 years behind state of research :😉
> 
> far better than the international average...
> 
>  > One think I did was verify all class names, abstract class names and interfaces had unique names.
> 
>  >
> 
>  > We could also tack Object back on the jsail names, if necessary.
> 
> Good thinking.  We definitely don't want pyjnius to be looking at the oversimplistic/insufficient org.web3d.x3d.sai interfaces.
> 
> Was thinking we should use fully qualified concrete class names for zero ambiguity, but it looks like you have that pattern correctly listed already:
> 
> HelloWorld.py
> 
> =============
> 
> import classpath
> 
> from org.web3d.x3d.jsail.Core.X3DObject import X3DObject as X3D
> 
> from org.web3d.x3d.jsail.fields.SFStringObject import SFStringObject as SFString
> 
> from org.web3d.x3d.jsail.Core.headObject import headObject as head
> 
> etc.
> 
> =============
> 
> Is there another way we might be mistakenly triggering pyjnius to mistakenly look at abstract classes?
> 
>  > Cool.
> 
>  >
> 
>  > John
> 
>  >
> 
>  > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
> 
>  >
> 
>  > *From: *Brutzman, Donald (Don) (CIV) <mailto:brutzman at nps.edu>
> 
>  > *Sent: *Sunday, May 12, 2019 2:23 PM
> 
>  > *To: *John Carlson <mailto:yottzumm at gmail.com>
> 
>  > *Cc: *X3D Graphics public mailing list <mailto:x3d-public at web3d.org>
> 
>  > *Subject: *Re: python pyjnius mapping
> 
>  >
> 
>  > agreed it is confusing... reflection can be very tricky.
> 
>  >
> 
>  > good observation that we should look hard at what setDEF() returns.
> 
>  >
> 
>  >                  .addChild(Viewpoint().setDEF("ViewUpClose").setCenterOfRotation(0,-1,0).setDescription("Hello world!").setPosition(0,-1,7))
> 
>  >
> 
>  >                  AttributeError: 'org.web3d.x3d.sai.Navigation.X3DViewpointNode' object has no attribute 'setCenterOfRotation'
> 
>  >
> 
>  > from ViewpointObject, the method is explicitly declared/customized to Override the parent abstract class.
> 
>  >
> 
>  >                  @Override
> 
>  >
> 
>  >                  public final ViewpointObject setDEF(String newValue)
> 
>  >
> 
>  > also available
> 
>  >
> 
>  >                  public ViewpointObject setCenterOfRotation(double x, double y, double z)
> 
>  >
> 
>  >                  public ViewpointObject setCenterOfRotation(float x, float y, float z)
> 
>  >
> 
>  >                  @Override
> 
>  >
> 
>  >                  public ViewpointObject setCenterOfRotation(float[] newValue)
> 
>  >
> 
>  > yes still confusing.  i think we need to throughly review logic in your classes first before making a conclusive claim against pyjnius...  make sure it always looks at classes, not abstract superclasses.
all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190515/c1dd7f43/attachment-0001.html>


More information about the x3d-public mailing list