<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:inherit;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"inherit",serif;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"inherit",serif;}
span.od
{mso-style-name:od;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=EN-US><div class=WordSection1><p class=MsoNormal>Don wrote:</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>John, wondering if you can just map all the concrete nodes in a scene graph to the corresponding concrete objects in X3DJSAIL. That will avoid all of the "abstract method not found" errors. The X3D abstract classes are specification-defined and helpful and good to expose programmatically, but they are never needed when translating .x3d or other file encodings (uh, since they are abstract).</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>* "A concrete class is a class that can be instantiated, as opposed to abstract classes, which cannot."</p><div style='mso-element:para-border-div;border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'><p class=MsoNormal style='border:none;padding:0in'> https://en.wikipedia.org/wiki/Class_(computer_programming)#Abstract_and_concrete</p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I guess you’re talking about abox.future.py, and this error:</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>python abox.future.py</p><p class=MsoNormal>Traceback (most recent call last):</p><p class=MsoNormal> File "abox.future.py", line 63, in <module></p><p class=MsoNormal> .setProtoField("myShape") \</p><p class=MsoNormal> File "jnius\jnius_export_class.pxi", line 760, in jnius.JavaMethod.__call__</p><p class=MsoNormal> File "jnius\jnius_conversion.pxi", line 78, in jnius.populate_args</p><p class=MsoNormal> File "jnius\jnius_utils.pxi", line 205, in jnius.check_assignable_from</p><p class=MsoNormal>jnius.JavaException: Invalid instance of 'org/web3d/x3d/jsail/X3DConcreteNode' passed for a 'org/web3d/x3d/sai/Core/X3DNode'</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I don’t know what’s causing this. Maybe PyJNIus is buggy. It looks really weird</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Here is the import, as far as I can tell:</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>from org.web3d.x3d.jsail.Core.connectObject import connectObject as connect</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Here is the implementing code of the Python/Java class:</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>from jnius import autoclass</p><p class=MsoNormal>connectObject = autoclass('org.web3d.x3d.jsail.Core.connectObject')</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I suggest we punt on this error for a while, and work on the AttributeError’s? You’re seeing those?</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Please check in a new X3D file that we can test with into the pyjnius folder. Thanks!</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I suggest this one:</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>processSingleScene.pythonValidation:</p><p class=MsoNormal> [echo] processSingleScene.python C:\x3d-code\www.web3d.org\x3d\content\examples\X3dForWebAuthors\Chapter02GeometryPrimitives\GeometryPrimitiveNodes.future.py</p><p class=MsoNormal> [echo] Loading X3D model as .py program, if successful then saving as round-trip .x3d version:</p><p class=MsoNormal> [exec] Traceback (most recent call last):</p><p class=MsoNormal> [exec] File "C:\x3d-code\www.web3d.org\x3d\content\examples\X3dForWebAuthors\Chapter02GeometryPrimitives\GeometryPrimitiveNodes.future.py", line 63, in <module></p><p class=MsoNormal> [exec] .setTranslation([-5,0,0]) \</p><p class=MsoNormal> [exec] AttributeError: 'org.web3d.x3d.sai.Grouping.Transform' object has no attribute 'addChild'</p><p class=MsoNormal> [exec] Result: 1</p><p class=MsoNormal> [echo] =====================</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Note the use of the interface here. There is no addChild on the interface. Thus much of our “pipelining” will fail </p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Here I the declaration of Transform:</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>from org.web3d.x3d.jsail.Grouping.TransformObject import TransformObject as Transform</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>concrete. Where is the interface coming from? Let’s look at setTranslation.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>In the interface, it’s listed as:</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>public Transform setTranslation(float[] newValue);</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Transform comes from the sai.Grouping package in this interface. So it returns an interface, right?</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Let’s look at the concrete class in jsail/Grouping/TransformObject.java:</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>public TransformObject setTranslation(float[] newValue)</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>It doesn’t return the same type as the interface. Isn’t this breaking the interface contract that TransformObject pledges to have when it implements the interface?</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>So since the interface is broken, the next line of code fails:</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>.addChild(Shape() \</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Subtle, huh? I do not know why the Java compiler doesn’t throw tons of exceptions about this.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I would report the error to Oracle. They should at least report a potential issue with a broken contract.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I suggest that all setters return something in the sai code. I think that will clean up a bunch of our errors as you repair X3DJSAIL.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>That sucks, right? I suggest that we abandon *.future.py until we get a pure python API. Have I stated my reasoning appropriately?</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Sorry it took me so long to describe this, and all my irateness. It was my fault for knowing what the problem was and not describing it adequately before.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>John</p><p class=MsoNormal><o:p> </o:p></p></div></body></html>