More readme

[jzy3d]

#4

[jzy3d]

I am not sure about the sbt run command suggested in the readme since I got this error when the build starts testing on my M1. It can't (yet) load a platform so it fails to initialize. Is there a way to bypass the test ?

martin@osxm1 ~/D/j/p/vtk-java-natives (main) [1]> sbt run                                                                                                                                                    (base) 
[info] welcome to sbt 1.6.2 (Oracle Corporation Java 17-panama)
[info] loading settings for project vtk-java-natives-build from plugins.sbt ...
[info] loading project definition from /Users/martin/Dev/jzy3d/public/vtk-java-natives/project
[info] loading settings for project root from build.sbt ...
[info] set current project to root (in build file:/Users/martin/Dev/jzy3d/public/vtk-java-natives/)
[info] compiling 1 Java source to /Users/martin/Dev/jzy3d/public/vtk-java-natives/target/classes ...
[info] running ch.unibas.cs.gravis.vtkjavanativelibs.Main 
vtk-native version: 0.1
Java version: 17-panama
Current platform: mac_x86_64
Will unpack to : /var/folders/d2/85g_sxm91rg71yyky4gg6l6h0000gn/T
Initialization failed with NullPointerException, stacktrace follows.
java.lang.NullPointerException: Cannot invoke "java.net.URL.getFile()" because "<local5>" is null
	at ch.unibas.cs.gravis.vtkjavanativelibs.VtkNativeLibraries.initialize(VtkNativeLibraries.java:64)
	at ch.unibas.cs.gravis.vtkjavanativelibs.Main.main(Main.java:27)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at sbt.Run.invokeMain(Run.scala:143)
	at sbt.Run.execute$1(Run.scala:93)
	at sbt.Run.$anonfun$runWithLoader$5(Run.scala:120)
	at sbt.Run$.executeSuccess(Run.scala:186)
	at sbt.Run.runWithLoader(Run.scala:120)
	at sbt.Defaults$.$anonfun$bgRunTask$6(Defaults.scala:1983)
	at sbt.Defaults$.$anonfun$termWrapper$2(Defaults.scala:1922)
	at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
	at scala.util.Try$.apply(Try.scala:213)
	at sbt.internal.BackgroundThreadPool$BackgroundRunnable.run(DefaultBackgroundJobService.scala:369)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:831)
stacktrace above.```

[marcelluethi]

Thanks for suggesting these improvements. I am happy to merge them.

Regarding your question: The problem seems to be here. It does not yet distinguish between M1 and Intel Macs and hence reports as a platform just mac_x86_64 and then tries to load the native libs for x86, which fails. If we would distinguish the different architectures correctly, a proper exception would be thrown here.