[x3d-public] X3DJSAIL: Exceeding Java String limits on setValue? What do we do?

Don Brutzman brutzman at nps.edu
Sun Mar 26 20:57:40 PDT 2017 

It should be possible to avoid String size limits by using typed values instead.

Latest build has built-in type support for fieldObject and fieldValueObject, allowing a programmer to set and get numeric array values of fields without using String datatypes.  There are tons of typed getValue"Type" and setValue methods provided.

	http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/Core/fieldObject.html#method.summary

	http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/Core/fieldValueObject.html#method.summary

Here are some examples from HelloWorldProgram.java

new ProtoInterfaceObject()
	.addField(new fieldObject()
		.setName("enabled")
		.setType(fieldObject.TYPE_SFBOOL)
		.setAccessType( fieldObject.ACCESSTYPE_INPUTOUTPUT)
		.setValue(true)			  // equivalent, strongly typed
		.setValue(new MFBoolObject(true)) // equivalent
		.setValue(SFBoolObject.TRUE))     // equivalent
	.addField(new fieldObject()
		.setName("diffuseColor")
		.setType(fieldObject.TYPE_SFCOLOR)
		.setAccessType( fieldObject.ACCESSTYPE_INPUTOUTPUT)
		.setValue(new SFColorObject().setValueByString("0.8 0.8 0.8"))	  // equivalent, strongly typed
		.setValue((SFColorObject.toString(SFColorObject.DEFAULT_VALUE)))) // equivalent

Similarly the SF/MF field objects have more methods allowing you to use numeric types more conveniently instead of strings.  Furthermore, support for both float and double arrays exists in most places.  Look at the variety of getValue"Type" and setValue methods provided, for example SFVec3fObject.

	http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/fields/SFVec3fObject.html

There are also typed append() methods for the MF array objects, for example MFVec3f.append(SFVec3fObject newValue) and MFVec3f.append(float[] newValue)

	http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/fields/MFVec3fObject.html

	http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/fields/MFVec3fObject.html#append-float:A-

	http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/fields/MFVec3fObject.html#append-org.web3d.x3d.jsail.fields.SFVec3fObject-

Array-length counting tests are included throughout the source code and documentation, for example:

	"WARNING: newValue array length must correspond to tuple size for base type MFVec3f tuple size of 3."

So hopefully this provides alternative, higher-performance patterns.  Please advise if some of the conversions are still not yielding.

v/r Don


On 3/25/2017 10:52 AM, Don Brutzman wrote:
> ... so, in other words, an alternative is changing something like this
>
>     new CoordinateObject()
>         .setPoint(new float[] {-8f,-9f,4f, [...]
>
> to
>     new CoordinateObject()
>         .setPoint(new MFVec3fObject().setValue(-8f,-9f,4f, [...]
>
> or even
>     new CoordinateObject()
>         .setPoint(new MFVec3fObject().setValue(-8f,-9f,4f, [...]
>
> Continuing on that path, I add a variety of other constructor and setValue methods to the field objects to facilitate use of either floats or doubles as needed.
>
> Example invocations, tested in HelloWorldProgram.java
> ======================================================
>         // test alternate type forms
>         boxCoordinateNode.setPoint(new MFVec3fObject(new float[] {-8f,-9f,4f,-7f,-7f,5f,-3f,0f,5f}));                //  floats to  float array to MFVec3f
>         boxCoordinateNode.setPoint(new MFVec3fObject(new double[] {-8f,-9f,4f,-7f,-7f,5f,-3f,0f,5f}));                //  floats to double array to MFVec3f
>         boxCoordinateNode.setPoint(new MFVec3fObject(new double[] {-8,-9,4,-7,-7,5,-3,0,5}));                        //    ints to double array to MFVec3f
>         boxCoordinateNode.setPoint(new MFVec3fObject(new double[] {-8.0,-9.0,4.0,-7.0,-7.0,5.0,-3.0,0.0,5.0}));        // doubles to double array to MFVec3f
> //        original SAI interface returns void, cannot be pipelined, candidate specification change
> //        boxCoordinateNode.setPoint(new MFVec3fObject().setValue(new float[] {-8f,-9f,4f,-7f,-7f,5f,-3f,0f,5f}));    //  floats to float array to MFVec3f
>         boxCoordinateNode.setPoint(new MFVec3fObject().setValue(new double[] {-8f,-9f,4f,-7f,-7f,5f,-3f,0f,5f}));    //  floats to double array to MFVec3f
>         boxCoordinateNode.setPoint(new MFVec3fObject().setValue(new double[] {-8,-9,4,-7,-7,5,-3,0,5}));            // doubles to double array to MFVec3f
>         boxCoordinateNode.setPoint(new MFVec3fObject().setValue(new double[] {-8.0,-9.0,4.0,-7.0,-7.0,5.0,-3.0,0.0,5.0}));// doubles to double array to MFVec3f
>         boxCoordinateNode.setPoint(boxPathPointArray); // restore
> ======================================================
>
> Deployment update complete.
>
> On 3/25/2017 1:08 AM, Don Brutzman wrote:
>> OK as hypothesized below, added a whole pile of paired float[] and double[] setValue() methods are now provided in the jsail.fields SF/MF field objects for flexible initialization there.
>>
>>     Package org.web3d.x3d.jsail.fields
>>     The fields subpackage is provided for creating typed X3D field values and also includes various utility capabilities.
>>     http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/fields/package-summary.html
>>
>> Meanwhile fieldObject and fieldValueObject remain string based (as in XML), that design will take further consideration.
>>
>>
>> On 3/24/2017 8:36 PM, Don Brutzman wrote:
>>> [...]
>>>
>>> b. for floating point arrays, perhaps overloaded methods for double arrays when a float array is expected, avoiding the need for "f" after each value.
>>>
>>> however this could bloat the API quite a lot, also be more confusing.
>>>
>>> so, type conversion of individual complex-type values like that might be best accomplished in a deliberate fashion, so it might be better to concentrate such type-conversion methods in the SF/MF field object classes.
>>>
>>> For example, MFDouble.  existing methods can be found at
>>>
>>>     http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/fields/MFDoubleObject.html#method.summary
>>>
>>>     void     setValue(double newValue)
>>>         Assign a single double as new array value.
>>>     void     setValue(double[] newValue)
>>>         Assign a new double[] value to this field.
>>>
>>> perhaps some additional set methods like
>>>
>>>     void     setValue(int newValue)
>>>         Assign a single int as new array value.
>>>     void     setValue(int[] newValue)
>>>         Assign a new int[] value to this field.
>>>
>>>     void     setValue(float newValue)
>>>         Assign a single float as new array value.
>>>     void     setValue(float[] newValue)
>>>         Assign a new float[] value to this field.
>>>
>>> The Java compiler must worry about the general case and thus can be pretty picky about type coercion, often requiring the programmer to coerce types explicitly so that no unintended loss of numerical fidelity occurs.  In terms of X3D scene graph, however, the typed precision of each value is strictly defined in the abstract specification, so there is no ambiguity about what the end-state is.  So there might be legitimate room for additions here while avoiding the creation of trapdoors for programmers to fall into.
>>>
>>> comments welcome.  i'll start by looking at setValue utility methods on objects like MFDoubleObject etc.
>>>
>>>
>>> On 3/24/2017 8:25 AM, yottzumm at gmail.com wrote:
>>>> There’s one with floating point numbers which is even bigger.  At least the previous message one is scrollable.
>>>>
>>>> John
>>>>
>>>> *From: *Don Brutzman <mailto:brutzman at nps.edu>
>>>> *Sent: *Friday, March 24, 2017 11:17 AM
>>>> *To: *yottzumm at gmail.com <mailto:yottzumm at gmail.com>
>>>> *Cc: *X3D Graphics public mailing list <mailto:x3d-public at web3d.org>
>>>> *Subject: *Re: X3DJSAIL: Exceeding Java String limits on setValue? What do we do?
>>>>
>>>> On 3/24/2017 5:33 AM, yottzumm at gmail.com wrote:
>>>>
>>>>> There are a couple of files where setValue exceeds Java string limits.  What should we do?  Would passing an array help?
>>>>
>>>> - please share example
>>>>
>>>> - ("splitting strings" + " is easy enough" + " for passed parameters")
>>>>
>>>> - arrays are definitely more efficient and more compact for compilation and storage
>>>>
>>>> - better understanding will likely lead to even further options

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