The 1.9.0 release of JOML, codename “Halloween” ;), has been released yesterday and is since available on GitHub Release and on Maven Central.
See the 1.9.0 release notes for further information.
People upgrading from 1.8.0 and before should also read the 1.8.1 release notes.
The first Android-compatible version of JOML 1.9.1-SNAPSHOT has been deployed to oss.sonatype.org as an Android Library (.aar file) together with javadocs and sources, ready to be included as such in an Android Application Project. The coordinates are [icode]org.joml:joml-android:1.9.1-SNAPSHOT[/icode].
The features are exactly identical to the current 1.9.1-SNAPSHOT for Desktop.
Make sure you add the oss.sonatype.org snapshot repository to your Gradle buildfile:
repositories {
maven { url "https://oss.sonatype.org/content/repositories/snapshots/" }
}
Starting with the currently published 1.9.2-SNAPSHOT version (on oss.sonatype.org) the next 1.9.2 release will enhance the Java compatibility back to even Java 1.2 ***. JOML already was pretty 1.2-compatible, so it was not a big task. The use-case are people with really ancient (or self-built) JREs, who simply want to use the math classes of JOML and not the NIO interoperability with a Java/OpenGL binding library (NIO classes only exist since 1.4).
So, JOML fully supports 8 major Java versions, from 1.2 to 1.9.
Nevertheless, JOML will focus on being optimized for more recent JREs. Currently, this includes 7, 8 and 9.
*** yes, JOML actually runs on an ancient Sun 1.2.2_017 JRE. 
That’s impressive, why not maybe publish a GWT version too? I can write the GWT module for you, it’s just including an XML file along with Java class files and the sources.
I’ve spent a little trying to port JOML to GWT, but it’s not an easy task. The major problems are:
- classes being used from java.lang, java.io and java.text which are not present in GWT (albeit being present in Java 1.1). Those need to be available as skeletons (for exception types) or correctly ported using GWT’s replacement classes (most notably for java.text classes, such as DecimalFormat and NumberFormat)
- Reflection. JOML has some places where the Java Core Reflection API is being used to detect capabilities of the runtime environment (the existence of certain classes and methods). This can and should now be centralized into a single “Config” class (just like GNU autotools do it for C projects), with various “HAS_…” static methods implemented differently for desktop JREs and for GWT (possibly for GWT just returning false or true).
The goal should be to have the exact same codebase for both desktop JREs and GWT, and using build parameterization (e.g. Maven profiles) to control which classes get included in a build.
First support for GWT has been added in the gwt-new branch.
In order to build a GWT module JAR file from it, the repo needs to be cloned and the branch checked-out and built with
mvn package -Dgwt
This results in a joml-1.9.2-SNAPSHOT-gwt.jar being generated in target/. This can be added to the buildpath/classpath of your GWT application. In order to use the module, simply add [icode][/icode] to your application module xml file.
Current limitation: toString() on JOML objects does not produce the same formatted output as the JRE version of JOML due to DecimalFormat not having been ported yet.
First working version of JOML for GWT has been published to oss.sonatype.org as [icode]org.joml:joml-gwt:1.9.2-SNAPSHOT[/icode]. Interoperability with WebGL through SHC’s excellent WebGL4J via float[] and GWT’s Float32Array emulation.
That’s great, and I started to port the examples to use JOML. Unfortunately I’m greeted with an error message:
:examples:compileGwt
Jan 06, 2017 8:55:28 PM java.util.prefs.WindowsPreferences <init>
WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5.
Compiling module com.shc.webgl4j.examples.client
[ERROR] Errors in 'org/joml/Options.java'
[ERROR] Line 59: Only string constants may be used as property name in System.getProperty()
:examples:compileGwt FAILED
The reason is that [icode]System.getProperty[/icode] calls are inlined by the compiler so they must have constant args. Think of it like a [icode]GWT.create[/icode] call with a String.
Better solution will be to replace [icode]hasOption[/icode] calls with a regex to [icode]System.getProperty()[/icode].
hasOption\((.+)\)
Boolean.parseBoolean(System.getProperty($1));
That is sufficient in my opinion. By the way, the use of pre-processor is a nice idea, does that work with IDE support? I don’t think it works in IDE, but am curious.
You have to define the properties that you use in the module description file, and also set the accepted values.
<define-property name="joml.debug" values="true,false">
Then whenever we want to set the property in the user project, they would add the set property command to their module file like
<set-property name="joml.debug" value="true">
Done! I have updated the examples to use JOML-GWT successfully! Thanks for the work @KaiHH.
New examples can be found here
I just checked whether the GWT compiler optimizes virtual calls and inlines them, just like the HotSpot JIT does when it can be proven that the callsite will only ever see one single incarnation of the receiver type. And in fact, it does! I thought this could become an issue because of those internal “Proxy” classes that the JOML classes have. But it is not.
So, the add function in your screenshot should actually show up other.m00…other.m33. It does for me when I take your WebGL4J Gradle build and just disable obfuscation via:
gwt {
...
compiler { style = 'PRETTY'}
}
When I use Matrix4f.add(Matrix4fc right), then GWT generates this:
function $add_7(this$static, other){
return $_m00(this$static, this$static.m00 + other.m00) , $_m01(this$static, this$static.m01 + other.m01) , $_m02(this$static, this$static.m02 + other.m02) , $_m03(this$static, this$static.m03 + other.m03) , $_m10(this$static, this$static.m10 + other.m10) , $_m11(this$static, this$static.m11 + other.m11) , $_m12(this$static, this$static.m12 + other.m12) , $_m13(this$static, this$static.m13 + other.m13) , $_m20(this$static, this$static.m20 + other.m20) , $_m21(this$static, this$static.m21 + other.m21) , $_m22(this$static, this$static.m22 + other.m22) , $_m23(this$static, this$static.m23 + other.m23) , $_m30(this$static, this$static.m30 + other.m30) , $_m31(this$static, this$static.m31 + other.m31) , $_m32(this$static, this$static.m32 + other.m32) , $_m33(this$static, this$static.m33 + other.m33) , this$static.properties = 0 , this$static;
}
which means it can see through the Matrix4fc interface to the only implementation, Matrix4f, and inline the virtual calls of the m-element accessors.
Pretty cool.
How did you call the GWT compiler so that the getter method calls remained in your shown code?
GWT does optimizations only when not in Super Development Mode. Once you start with gradlew superDev, it just starts with the super dev server, and still runs the WAR it created for production. If you enable the DevMode with the bookmarks (go to localhost:9876 to get the bookmarklets) then a recompile will happen disabling the optimizations so you can debug your program using source maps, right in the browser.
Latest JOML release version 1.9.3 is out!
The most notable change is the full compatibility with GWT >= 2.5.0 (even in strict mode), available as org.joml:joml-gwt:1.9.3 on Maven Central (Gradle setup).
Many thanks to @SHC for his great support to make this possible!
Latest JOML release version 1.9.4 is out!
As usual, thanks to @theagentd for reporting bugs and proposing valuable additions.
Latest JOML version 1.9.6 has been released.
In addition to some bug fixes, it adds Java 9 module and OSGi bundle support. For those who worry, JOML of course will remain Java 1.2 compatible.
Get the new release via the GitHub Release page, Maven Central or as part of a LWJGL 3 download.
New JOML 1.9.8 release contains multiple bugfixes, additions and performance improvements for many Matrix4/Matrix4x3 methods.