[x3d-public] setUSE in X3DJSAIL

Don Brutzman brutzman at nps.edu
Fri Jul 21 16:38:28 PDT 2017


John, thanks for these great insights.  Am certainly open to using Nashorn with X3DJSAIL.  It has been part of Java 8 for three years now, and Netbeans even includes a debugger.

	https://docs.oracle.com/javase/8/docs/technotes/guides/scripting/nashorn/
	https://blogs.oracle.com/geertjan/youtube:-debugger-for-jdk8s-nashorn-javascript-in-netbeans-ide

Am working as best possible to migrate to a new machine and issue updates of source/content/application projects prior to SIGGRAPH 30 JUL - 4 AUG.  Travels continue during the following week to annual ISO meeting, in DC this year.

Of course lots and lots of important activity, specification writing, issue resolution etc. is ongoing by X3D Working Group.  This all takes time - all of it valuable and productive.  Lots of opportunities for others to contribute especially for X3Dv4 interoperation with HTML5/DOM Recommendations.

Upcoming: Java 9 release is "feature complete" and public delivery is expected in fall with corresponding improvements in JDK, JRE and Netbeans (and thus X3D-Edit).  We've already got a lot from Java 8 (especially pipeline programming) and no doubt will find that 9 is further useful for interoperability and security.

	https://docs.oracle.com/javase/9
	http://wiki.netbeans.org/NetBeans_9
	http://www.java9countdown.xyz

Key to all of this X3D interoperability progress will be fine-tuning the Object Model for X3D (OM4X3D) and X3D JSON Encoding, with confirmation via our converters and validation tests. Topmost follow, can we resolve this week?
- ProtoInstance USE not needing name
- do we keep using "ROUTE" key to collect ROUTEs together as an array, or treat them similarly to other nodes and maintain ordering?

Of course not dropping synch on past issues remains crucial, getting issues resolved is how we keep building a solid foundation.

Looking forward, am particularly curious to how Nashorn might help us experiment with DOM in JavaScript, possibly advancing X3Dv4 progress even further.  DOM in Java appears to be an open door already for X3DJSAIL.

Am certainly open to extending X3DJSAIL, it is (no kidding) open source.  Most code gets autogenerated from OM4X3D, and it is straightforward to add further functionality and utility code as well.  XSLT stylesheets are just one tool among many, it is a productive way for me to code.  First law of engineering: "if it ain't broke, don't fix it."  I think that it is very healthy to add several approaches for some tasks, rather than replacing, since it really helps with round-trip comparisons (our strongest QA) to get everything rock solid and then deploying capabilities farther/further into other tools and environments.

The more we get each of the growing number of X3D file encodings and language bindings to work correctly/consistently/validly, the cumulative benefits for using X3D get multiplied to good effect in every direction.

Apologies if we haven't done as much integration as you'd like yet - we are certainly running hard in the same directions!  Looking forward to continuing progress together.  Thank Goodness It's Friday.  8)


On 7/20/2017 2:50 PM, John Carlson wrote:
> Don wrote:
> 
>  >Interesting to think that any program could produce .x3d .x3dv .wrl .json .java and maybe someday .js .c++ .python etc.  Perhaps new worlds of interoperability are emerging, all sharing interactive X3D scenes as presentation layer to users.
> 
> We already have .json -> DOM -> .js .py and maybe you don’t realize it in my work yet. .py doesn’t run right now, but I think we are close, since it used to work.
> 
> 
> Don, if **we** do a little research on how to integrate a Nashorn program into Java, perhaps we could bring my JavaScript https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/JavaScriptSerializer.js  and Python https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/PythonSerializer.js  serializers into X3DJSAIL proper.  That is, if you’re open to the idea, and are not restricted to doing the stylesheet thing all the time.   The goal would be to go from X3DJSAIL app -> Java XML -> XML or DOM -> JavaScript DOM -> .js .py.  Then slowly replace them with stylesheets as you and others find the time.
> 
> Then I could work with Roy on a DOM -> .cpp serializer in JavaScript as well.
> 
> Alternatively, you could get on the stick and integrate X3dToJava.xslt with the now old X3dToES5.xslt so we start writing a new language independent stylesheet that we can target at Java, JavaScript, ECMAScript, Python, C++, C#, … with a parameter.
> 
> My Action Needed has fallen by the wayside I see.  That’s OK.
> 
> 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