I’ve been reading through the documentation, but I’m still a bit confused as to what exactly the difference is between the SDK, the Engine, and the Gradle project.
Also, I was trying to set up the SDK to use OpenJDK11 (both from inside the IDE, and by modifying the jmonkeyplatform.conf as described in the documentation) but I’m seeing a ‘Fatal Error : unable to find java.lang’ message.
I’m using OpenJDK11 in non-jme projects with NB11 on Windows10, so I’m not sure what’s going on.
And since you mentioned Java 11 and NB 11, it is worth mentioning that the SDK is based on NB. NB version 8. It doesn’t support Java 11. You are stuck with Java 8 with the SDK currently. SDK based on NB 11.2 is around the corner yes…
So at the moment maybe your best shot is to use the NB 11 with Java 11 you are accustomed to. Just create a Gradle based project with references to the JME binaries. There was the official Gradle JME project example somewhere in the forums… Or the docs…?
@oxplay2 & @tonihele : Oh, so the JDK1.8 platform is really OpenJDK ? That’s fine too for now.
I’m also confused about the lwjgl/ lwjgl3/ jogl dependencies. Can I just pick whatever I like and everything will still work ? Or is there some setup involved as well ?
Also, @oxplay2, when you say ‘use the SDK for asset management’ : do you mean creating the model binaries etc ? Do you also create the scenes there, or is that through code ?
I don’t really understand the sentence. But I’m talking about Java versions. Whether you use OpenJDK or Oracle JDK, it is up to you. Yep, multiple implementations of the standard exists. The thing is that the IDE needs to support the version you want to use. Netbeans 8 doesn’t support Java 11. It think it just goes up to Java 8. Java 11 is the current long term support (LTS) Java version. Version 8 is still also supported for awhile, at least the Oracle JDK one.
@tonihele : I meant I don’t really care too much about what version of Java I’m using at this point. I just don’t really want to use the legacy Oracle jdk, because if I understood correctly, we’re no longer supposed to use that in commercial products …
One more option is to create regular maven project (if you’re familiar with maven) and just import the dependencies you need that way. I don’t know if step by step is documented anywhere. I used this page to find the dependencies I needed.
That is a bit more complicated issue yes. I don’t know if you can call them legacy really. And I think it is more to do with distributing them, the license change you are referring to. And commercial support kinda thing. But sure, with OpenJDK you have to worry much less of these since the more liberal license.
An even easier way is to just add this to your gradle build,
apply plugin: "java"
buildDir = rootProject.file("build/assets")
I use the SDK for coding gradle projects as well. I create a folder in the resource directory the SDK uses and in that folder I start a standard jme mygame project for asset management.
I create a gradle project in the same folder, using my own forked, fixed, version of bootmonkey. Because the gradle project has those two statements, when ever I reload the gradle project or run the gradle project, it will sync the assets of the mygame project into the gradle project and properly build the jars of the gradle project distribution by excluding everything thats not supposed to be in the build jars, exactly as the SDK does.
Sync is real fast as it only adds or removes new items. This gives access to all the goodies of the SDK and all the goodness of gradle from the same SDK, best of both worlds.
To me it depends on the type of development. If I’m using a bunch of already built assets or textures then it’s no big deal to bundle them in a jar because they rarely/never change… and gradle won’t rebuild the jar unless things change.
…but if it’s a project that’s mostly about the assets and all I’m doing is tweaking assets, running, tweaking assets, running… then a directory is better. At least until the assets are done and/or approaching release.
using txt file for something (that might edit often, dialogues? some settings?)
using lipsync files(not often but just as example)
also having GB of 4k textures increase wait time (try have a lot of it…)
i could give more examples. Like you said “depends on the type of development”. but there are a lot more of situations you didnt write.
Well, most people do “light-weight” games, so i understand its not a problem. But its not everyone.
edit: anyway we will need “cleanup assets a little(make 50% of weight or even less - have trash files)” because already needed “tasks.distZip.zip64 = true”
but since JAR is not builded in development, its not important.