[x3d-public] Node.js for X3DJSAIL. Beginnings in X3DJSONLD. typecast issues

Brutzman, Donald (Don) (CIV) brutzman at nps.edu
Sat Oct 20 09:08:36 PDT 2018


Continuing this line of thought: on further consideration, creating two versions of X3DJSAIL (strict or lenient) doesn't make sense because it leads to unportable source code and entirely new avenues for errors, by programmers or within the library itself.  Not a good option.

For wrapping in support of JavaScript numbers type being double precision, I think the door is mostly open to typecast mappings already if you use X3D's native types: SFFloat SFInt32 etc.  Explanation follows.

Notice that X3DJSAIL constructors and accessor methods for each of these types are quite thorough already.  For example, in addition to variously typed setValue(newValue) methods:

----------------------------------
http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/fields/SFFloatObject.html#constructor.summary

Constructor Summary
Constructors Constructor and Description
* SFFloatObject() Constructor for SFFloatObject performs value initialization.
* SFFloatObject(double newValue)Constructor using double as new initial value.
* SFFloatObject(float newValue) Constructor for SFFloatObject using a corresponding Java primitive float as new initial value.
* SFFloatObject(int newValue) Constructor using int as new initial value.
* SFFloatObject(SFFloatObject newValue) Constructor to copy an SFFloatObject value as initial value for this new field object.

----------------------------------
http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/fields/SFFloatObject.html#setValueByString-java.lang.String-

* public SFFloatObject setValueByString(java.lang.String newValue)
                                throws InvalidFieldValueException

Utility accessor for SFFloatObject using String value (which must pass parsing validation checks).
Warning: this method is not type safe at compile time! Best practice for X3DJSAIL programmers is to use strongly typed methods instead, in order to avoid potential for run-time errors.
----------------------------------

In general I recommend avoiding setValueByString(java.lang.String newValue) methods whenever possible. Numeric data should be handled numerically.

Am expecting that the existing methods should give you most everything you want.  As additional usage alternatives, have added the following unit-testing code block to HelloWorldProgram.java fieldTests() method.  Java programmers have lots of ways to "do the right thing" with X3DJSAIL already.

         // typecast tests
         MaterialObject myMaterialObject = new MaterialObject();
         myMaterialObject.setAmbientIntensity((float) 0.123456789d);
         myMaterialObject.setAmbientIntensity(new SFFloatObject(0.123456789d));
         myMaterialObject.setAmbientIntensity((float) new SFDoubleObject(0.123456789d).getValue());

         // consider adding downcast methods such as SFDoubleObject.toFloat() .toInt() etc.
         // consider adding typecast methods for use of boolean values with numeric types

When inspecting each of the example usages above, the source clearly indicates what is happening with type conversions from double to float.  This also addresses Java's general insistence on strict typing (manifested by compiler warnings) that programmers should not be implicitly/silently vulnerable to unintended loss of precision in their data.

If we want to carefully add more type-conversion flexibility in X3DJSAIL, adding them to the existing X3D field types (as shown above) will be the right way to go.  Avoids API bloat and keeps typecast activity localized within the field types themselves, where all conversions can be carefully calibrated and checked.

Please keep us all posted on your experimental progress.  If further careful typecasting is justifiable when mapping X3DJSAIL to JavaScript or Python, we will be able to accomplish that.

Having fun with X3D 3.30000000000000 !  8)


On 10/19/2018 11:00 PM, Brutzman, Donald (Don) (CIV) wrote:
> Hi John.  Thanks for this interesting example.
> 
> As the error logs indicate, accessor methods using double types are not provided for X3D fields having SFFloat/MFFloat types in the current X3DJSAIL implementation.  Javadoc confirmation:
> 
> 	http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/Shape/MaterialObject.html#setAmbientIntensity-float-
> 	http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/Shape/MaterialObject.html#setAmbientIntensity-org.web3d.x3d.jsail.fields.SFFloatObject-
> 
> Java compilation issues warnings when source code tries putting a double into a float, so that the programmer knows a reduction in precision is occurring.
> 
> In a source program, a programmer can address this and silence warnings by deliberate casting, i.e. saying something like
> 
> 	myMaterialObject.setAmbientIntensity((float) 0.123456789d);
> 
> Two general solution approaches would seem to present themselves:
> 
> a. keep X3DJSAIL accessor methods strict so that authors (or conversion tools) must explicitly handle type-casting in a deliberate fasion.
> b. make X3DJSAIL overloaded with various types so that programmers don't know  and aren't notified when downcasting and loss of precision occurs.
> 
> Given that X3D presentation might have really strict usage requirements (for example CAD parts fitting together) the current X3DJSAILdesign is to stay strict throughout.  Downcasting and type conversion is certainly possible but must be deliberately accomplished by authors.
> 
> Yes agreed that JavaScript and JSON are always double precision.  This is unavoidably allowed by X3D ECMAScript language binding and X3D JSON encoding regardless of X3D Architecture and X3DUOM requirements.
> 
> It will be interesting to see if you can adapt/wrap things as indicated.  We will likely to again face the exact same issue in a Python binding, since the Python language puts a high premium on completely hiding typecasting from the programmer.
> 
> A future design option might be to provide such overloading, perhaps even selectively deployed as x3djsail-strict and x3djsail lenient builds.
> 
> As with JSON, we don't particularly want JavaScript programmers to have to worry about this all the time.
> 
> Good luck!
> 
> On 10/17/2018 8:12 PM, John Carlson wrote:
>> I am beginning to port X3DJSAIL to Node.js, using the java npm module to interface node.js to java.  I have seen a tiny bit of success, but am beginning to see hard problems that can might be solved by modifying X3DJSAIL, perhaps significantly, or undesirably, due to JavaScript or node limitations, not found in Nashorn.
>>
>> [...]
>>
>> Error: Could not find method "setAmbientIntensity(java.lang.Double)" on class "class org.web3d.x3d.jsail.Shape.MaterialObject". Possible matches:
>>
>>     public org.web3d.x3d.jsail.Shape.MaterialObject org.web3d.x3d.jsail.Shape.MaterialObject.setAmbientIntensity(org.web3d.x3d.jsail.fields.SFFloatObject)
>>
>>     public org.web3d.x3d.sai.Shape.Material org.web3d.x3d.jsail.Shape.MaterialObject.setAmbientIntensity(float)
>>
>>     public org.web3d.x3d.jsail.Shape.MaterialObject org.web3d.x3d.jsail.Shape.MaterialObject.setAmbientIntensity(float)
>>
>>       at Object.<anonymous> (C:\Users\coderextreme\X3DJSONLD\src\main\node\net\coderextreme\data\flipp.js:27:75)
>>
>>       at Module._compile (module.js:652:30)
>>       at Object.Module._extensions..js (module.js:663:10)
>>       at Module.load (module.js:565:32)
>>       at Function.Module._load (module.js:497:3)
>>       at Function.Module.runMain (module.js:693:10)
>>       at bootstrap_node.js:609:3
>>
>> Note that all JavaScript numbers are doubles I believe.  I will have to investigate the npm module to see if it supports floats.
>>
>> Indeed it does, the syntax is:
>>
>> |var f = java.newFloat(3.14);|
>>
>> Back to work.
>>
>> This should probably be mentioned in any JavaScript API which uses X3DJSAIL.
>>
>> John
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


More information about the x3d-public mailing list