JME itself is fine with java8. its mostly a one line change in the build file.
Well there is another possible approach btw.
Eg since the blender loader is only for desktop it wont need to run at android anyway.
(As you are supposed to convert and sue j3o’s anyway)
What would be the advantage of compiling with Java8? The baseline for jME 3.1 has been raised to Java 1.6 from Java 1.5 for 3.0, so using Java8 features would not be an option anyway.
@Kaelthas said:
Generally the ability to use lambdas, I think.
Depending on your situation, you may consider writing your game in Scala, it supports all (I think) new features in the Java 8 language and compiles to JVM 6 and 7.
Interoperability with java libraries is transparent so that’s not a problem.
But again, depends on your situation, you may want to give it a try.
@xuan said:
Depending on your situation, you may consider writing your game in Scala, it supports all (I think) new features in the Java 8 language and compiles to JVM 6 and 7.
Interoperability with java libraries is transparent so that's not a problem.
But again, depends on your situation, you may want to give it a try.
Actually I was intending it for the blender importer to simplify a lot of code. It works on collections most of the time.
@normen said:
Ah, so that wouldn't work anyway as said.
Ok, I think I am missing something here
If the sources were compiled with JDK8 then why would lambdas not work ??
@Empire Phoenix said:
Well the linked retrogradle stuff should in theory be able to do it.
The point of the baseline is that you can compile on any system and compiler, e.g. java->native etc. Thats why we kept the 1.5 one for so long. Writing a library against the latest version of Java is not exactly best practice, for applications its okay.
I personally found out that i am using Consumer/Producer in combination with method reference, and default methods in interfaces a lot more than lambdas/streams
Lambdas generally shorten the code.
Regarding Stream/ParallelStream i still have some issues there. Mainly because i loose control. In a real live example one of my requirements was to let the two main threads running, while processing the parallelstreams only on the remaining threads. Sure, it is possible but the solution feels like a hack.
//Add: since jme requires to run on android, java 8 support should not be an option for now. Not sure if its discussable, but from my point of view that could include the engine, while the sdk with all its importers could use a different java version. After all, android itself should never have importers and stuff like that running.
//Add 2: Also Avian currently does not seem to support lang.invoke so no java 1.7/1.8 on ios
I mostly use the java 8 features forthe defaults in interfaces,
I honestly not at perfect terms with the lambda syntax, and rarly use the parrlelstreams, as the reduce my power considerably. (eg leave render thread one cpu)
@zzuegg said:
//Add: since jme requires to run on android, java 8 support should not be an option for now. Not sure if its discussable, but from my point of view that could include the engine, while the sdk with all its importers could use a different java version. After all, android itself should never have importers and stuff like that running.
The blender importer is stuck on desktop anyway because of its AWT dependency and yes, it shouldn’t be run in a production game either. But as it is now its part of the engine in terms of compilation etc. If we’d outsource the importer to a plugin that would make Java8 possible.
And that is the main reason to use them Shorter code is easier to maintain.
Especially in blender importer when very often operations made on collections are quite difficult to read (not to mention - to write).
@zzuegg said:
//Add: since jme requires to run on android, java 8 support should not be an option for now. Not sure if its discussable, but from my point of view that could include the engine, while the sdk with all its importers could use a different java version. After all, android itself should never have importers and stuff like that running.
Maybe that would be worth discussing. SDK is a standalone product and could be compiled with Java 8 as all its plugins. And engine would remain in Java 6 just like @normen said. So that it can be used with older Javas as well.
This can definitely be done but I guess if we make it a complete part of the SDK there would be some moaning from the people that don’t use the SDK. If we made it a plugin we could (with the new plugin system thats being tested right now) provide both a SDK plugin and a jar/maven version. The only thing that would then be a problem is that the plugin would be only optional in the SDK…
But I guess we could somehow change the build process of the SDK so that it includes the plugin in the build… Don’t exactly have an idea on how thats supposed to work yet though… I guess it would only involve checking out the blender plugin and adding it to the default suite… That would make the build process of the SDK slightly more cumbersome (it would have to do the download/checkout of the plugin).
