[x3d-public] X3DJSAIL, X3dToJava.xslt updates
brutzman at nps.edu
Sun Apr 22 23:13:06 PDT 2018
Release announcement: lots of improvements checked in and deployed tonight.
X3D Java Scene Access Interface Library (X3DJSAIL) supports programmers with
standards-based X3D Java interfaces and objects, all as open source.
1. X3D Example Archives testing and X3DJSAIL improvements.
Added X3DJSAIL CommandLine -toJava switch.
Great suggestion to focus on serious testing to shake out the DOM loader.
Figured out a new Ant build.xml task that invokes X3DJSAIL CommandLine class to -validate all .java translations in each archive.
Fixed a number of Prototype problems, most of which resulted when we said ProtoInstance USE nodes no longer include a name attribute. A few warnings remain but most appear to be fixed. Diagnostic testing and improvements continue.
Best part of -validate testing is that it really exercises the expected majority of all DOM-based X3DLoader tests. Made a number of valuable fixes. Added design pattern to handle setting ProtoInstance as an SFNode field. Will need another pattern for handling addition of a single ProtoInstance to an MFNode field (other than X3DGroupingNode and similar children), which are rare but important cases.
John: I think that you will find a number of your prior problem cases are fixed now.
2. X3dToJava.xslt stylesheet (converts .x3d model to X3DJSAIL .java code)
a. Improved self-validation diagnostics output.
b. Lots of work trying to get past the 64K method limit in compiled Java for very-large CAD and scan scenes. Limited success, but the autogenerated code is highly modularized for large arrays and likely provides more coverage now. Minor tuning on split values may continue. Links and snippet follow.
private float getCoordinate_11_27_point_15 ()
/** Large attribute array: Coordinate point field, scene-graph level=11, element #27, 4326 total numbers made up of 1442 3-tuple values
* Provide large array value via a separate method, in order to avoid 'code too large' Java compilation errors.
* Individual Java methods (including aggregated initializations) are limited to 64KB.
* @see https://stackoverflow.com/questions/2407912/code-too-large-compilation-error-in-java
* @see https://stackoverflow.com/questions/11437905/java-too-many-constants-jvm-error
private MFVec3fObject getCoordinate_11_27_point ()
/* splitting up long array to improve readability */
MFVec3fObject Coordinate_11_27_point = new MFVec3fObject()
3. More to follow.
John your examples were very helpful and focused me on several key problems that needed remedying. A lot is fixed, more is needed.
Better and better... I will stick with the organized review of DOM-based X3DLoader.java to try to achieve thoroughness, probably next weekend.
As requested, I added an ant build.xml task "get.X3DJSAIL.update" which allows end users to update the copy of X3DJSAIL contained within each of the X3D Example Archives. Console excerpt:
get latest X3DJSAIL update from http://www.web3d.org/specifications/java/X3DJSAIL.html
Download complete, lib/X3DJSAIL.3.3.full.jar size 30355885 bytes
BUILD SUCCESSFUL (total time: 1 minute 54 seconds)
In general I keep library updates as a feature deliberately triggered by developers, and not automatic, since such libaries get tested with the content that gets deployed and we don't want to break local-user content when future changes occur.
Have fun with X3D and Java! 8)
On 4/18/2018 7:16 PM, John Carlson wrote:
> It will be important for the JSON to DOM loader, once we start stress testing that.
> On Wed, Apr 18, 2018, 10:09 PM Don Brutzman wrote:
> [cc: list, now that we've diagnosed the cause]
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