Groovy on JDK9 #unhappy

Getting compiled with jdk9.

Tried using javapackager. No difference in error.

Java invocation:

.\jre\bin\java.exe -Xmx512m ^
 -DsuppressSwingDropSupport=true -Djava.net.preferIPv4Stack=true ^
 -Dawt.useSystemAAFontSettings=lcd -Dswing.aatext=true ^
 -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintClassHistogram ^
 "-XX:ErrorFile=%USERPROFILE%\java_err.txt" "-XX:HeapDumpPath=%USERPROFILE%" ^
 --add-modules java.base,java.xml,java.xml.bind,java.desktop,java.compiler -cp lfclient.jar;commons-lang3-3.2.jar;glazedlists_java15-1.9.0.jar;jfreechart-fse-1.0-SNAPSHOT.jar;jmathplot.jar;jmathio.jar;miglayout-4.0-swing.jar;groovy.jar;groovy-swing.jar;.\ ^
 candela.lanforge.lfclient

Am wondering if there is like something similar to the ‘tools.jar’ that I should be preparing. All of the errors below appear to be from things missing in the java environment.

Loading plugins...
java.lang.ExceptionInInitializerError
        at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
        at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
        at java.base/java.lang.reflect.Constructor.newInstance(Unknown Source)
        at candela.lanforge.GroovyScriptFrame.register(GroovyScriptFrame.java:347)
        at candela.lanforge.GroovyScriptFrame.registerBuiltinPlugins(GroovyScriptFrame.java:225)
        at candela.lanforge.LANforgeMgr$1.run(LANforgeMgr.java:1675)
Caused by: groovy.lang.MissingMethodException: No signature of method: static java.util.regex.Pattern.compile() is applicable for argument types: (java.lang.String) values: [--lfver (\d+\.\d+\.
\d+)]
        at groovy.lang.MetaClassImpl.invokeStaticMissingMethod(MetaClassImpl.java:1503)
        at groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java:1489)
        at org.codehaus.groovy.runtime.callsite.StaticMetaClassSite.call(StaticMetaClassSite.java:53)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
        at candela.lanforge.GroovyCheckUpdates.(script14907583229861182367337.groovy:40)
        ... 7 more
1490758323: Free-mem: 146093224 totalMemory: 268435456 maxMemory: 1073741824 mem-space-left: 951399592
java.lang.reflect.InvocationTargetException
        at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
        at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
        at java.base/java.lang.reflect.Constructor.newInstance(Unknown Source)
        at candela.lanforge.GroovyScriptFrame.register(GroovyScriptFrame.java:347)
        at candela.lanforge.GroovyScriptFrame.registerBuiltinPlugins(GroovyScriptFrame.java:225)
        at candela.lanforge.LANforgeMgr$1.run(LANforgeMgr.java:1675)
Caused by: groovy.lang.MissingMethodException: No signature of method: java.lang.String.equalsIgnoreCase() is applicable for argument types: (java.lang.String) values: [gainspeed]
        at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:58)
        at org.codehaus.groovy.runtime.callsite.PojoMetaClassSite.call(PojoMetaClassSite.java:49)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
        at candela.lanforge.GroovyPortMonitor.(script14907583237002070177117.groovy:35)
        ... 7 more

IntelliJ configuration notes on using HugePages

Java has supported Linux Hugepages for a while, but it is not on by default. I like to squeeze the most performance out of my IDE so I turned it on. And here are the settings I used for Intellij now:

> cat idea64.vmoptions
-XX:+UseLargePages
-XX:LargePageSizeInBytes=2m
-Xms256m
-Xmx768m
-server
-XX:+UseG1GC
-XX:MaxGCPauseMillis=15
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-Djsse.enableSNIExtension=false
-Dawt.useSystemAAFontSettings=lcd

Building faster with Netbeans and SSDs

The build directories that Netbeans uses are pounded a lot, and chances are you have enough ram to leverage tmpfs. Let do it! Start with our /etc/rc.local file:

echo deadline > /sys/block/sda/queue/scheduler
echo 1 > /sys/block/sda/queue/iosched/fifo_batch

D=/home/jreynolds/.cache/netbeans
rm -rf   $D/*
mount    $D
chown -R jreynolds:jreynolds $D

D=/home/jreynolds/NetBeansProjects/MyProject/build
rm -rf   $D/*
mount    $D
# dont furgit the ram directory wants to be regularly deleted by netbeans
mkdir    $D/ram
chown -R jreynolds:jreynolds $D

D=/home/jreynolds/build/build-lib/
rm -rf   $D/*
mount    $D
mkdir    $D/jar
mkdir    $D/classes
chown -R jreynolds:jreynolds $D
exit 0

Next we make our /etc/fstab match:

none /var/tmp                            tmpfs    defaults,noatime  0 0
none /tmp                                tmpfs    defaults,noatime  0 0
none /home/jreynolds/.cache/chromium     tmpfs    noatime,noexec    0 0
none /home/jreynolds/.cache/netbeans     tmpfs    noauto,noatime    0 0
none /home/jreynolds/NetBeansProjects/MyProject/build        tmpfs defaults,noatime,noauto 0 0
none /home/jreynolds/.mozilla/firefox/0m31s0ag.default/Cache tmpfs defaults,noatime,noexec 0 0
none /home/jreynolds/build/myproject-lib tmpfs    noauto,noatime    0 0

Java3D, JOGL…jReality?

I’ve been reading up on where Java3D is at, and in brief, the Java3D federation effectively concluded its work in 2008 but left it…unmarketed. The API was left complete, but interaction with the AWT and Swing libraries apparently left a lot to be desired…esp if you tried running it on OSX.

There are a lot of scene-graph libraries that use JOGL, which is a thinner wrapper around OpenGL or DirectX and apparently many people seem to appreciate this foundation more. jReality is the first project that I’ve spotted that clearly states it suggests being used for mathematical visualization.

jReality | Home.