[x3d-public] advance notice: X3DJSAIL internal configuration defaults transitioning to JDK 17

[Brutzman, Donald (Don) (CIV)]

X3D Java Scene Access Interface Library (X3DJSAIL) supports programmers with standards-based X3D Java interfaces and objects, all as open source.


  *   https://www.web3d.org/specifications/java/X3DJSAIL.html

BLUF: we are upgrading our default Java version to 17, with no expected loss in backwards compatibility.  Details follow.

JDK 17 is a Long-Term Support (LTS) release and guaranteed long-term stable.  We have gotten past our prior transition problems 16 -> 17.  This LTS version is also more secure.


  *   Press Release: Oracle Releases Java 17, September 14, 2021
  *   https://www.oracle.com/news/announcement/oracle-releases-java-17-2021-09-14

Oracle also has announced limited support for JDK8 in the future.

  *   Java SE 8 has gone through the End of Public Updates process for legacy releases.  Oracle will continue to provide free public updates and auto updates of Java SE 8 indefinitely for Personal, Development and other Users via java.com.
  *   https://www.oracle.com/java/technologies/java-se-support-roadmap.html

Up until now we have remained very conservative and maintained JDK8 (aka Java SE 8) compatibility in all our releases.  Hasn't been too hard, but I sometimes wonder if performance and optimization have not kept up.  Meanwhile our code compatibility continues to keep up remarkably well over all these versions of Java (JDK 8 through JDK 17.1) without flaw.  Further we have not seen any differences in correct capabilities when comparing OpenJDK and Oracle JDK.  I think that the underlying reason for this is that when they add Java language features, they seem to figure out seamless prior-version support in the JVM bytecode that gets produced by the updated Java compiler.


  *   Savage Developers Guide: Java
  *   https://savage.nps.edu/Savage/developers.html#Java

There is one important Java language feature that I'd like to use freely (when converting X3D to Java) which finally arrived in JDK 15: multiline text blocks, which are delimited by triple-quote """ characters.


  *   JEP 378: Text Blocks
  *   https://openjdk.java.net/jeps/378

As an example of improved clarity with this construct, avoiding line-by-line string constructs, here is an excerpt of converted Java code:


  *   https://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14Prototypes/MaterialModulatorIndex.html
  *   https://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14Prototypes/MaterialModulator.java

        .addChild(new Script("MaterialModulatorScript").setSourceCode("""
ecmascript:
function initialize ()
{
    newColor = diffuseColor; // start with original color
}
function clockTrigger (timeValue)
{
    if (!enabled) return;
    red   = newColor.r;
    green = newColor.g;
    blue  = newColor.b;

    // note different modulation rates for each color component, % is modulus operator
    newColor = new SFColor ((red + 0.02) % 1, (green + 0.03) % 1, (blue + 0.04) % 1);
               if (enabled)
               {
                              Browser.print ('diffuseColor=(' + red +',' + green + ',' + blue + ') newColor=' + newColor.toString() + '\n');
               }
}
function set_enabled (newValue)
{
               enabled = newValue;
}
""")
          .addField(new field().setName("enabled").setType(field.TYPE_SFBOOL).setAccessType(field.ACCESSTYPE_INPUTOUTPUT))


Stably achieving best-possible performance and security is certainly an important "best practice" to strive for.  Following a variety of testing, we are now beginning transition to OpenJDK 17 as our baseline for development.   It isn't hard to configure build scripts and properties to 1.8, and comments are in place showing how to do that, but we can't support regular unit testing of both.  I have not seen any impact on the various 3rd-party Java libraries that we also use, internally or externally.  Based on testing to date and continued stable evolution of Java, we do not expect to see any backwards-compatibility problems with this strengthening of X3DJSAIL.

If anyone eventually has trouble using forthcoming X3DJSAIL releases with older versions of Java in the future, please advise.  Am expecting that it will remain straightforward to embed fixes or document workarounds if any problems emerge.  Trouble reports always welcome.

Welcome to the third decade of the twenty-first century... Have fun using Java for X3D!  8)

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 https:// faculty.nps.edu/brutzman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220116/c33862f5/attachment-0001.html>