I’m experimenting with writing JVM apps in languages other than Java, both:
scripting languages that can run on a JVM via JSR 223 (such as Python, JavaScript/ECMAScript, Groovy, and Lua) and also
languages can be compiled directly to JVM classes, such as Kotlin, Groovy, Scala, and Clojure.
In the past, I’ve heard of people writing JME apps in languages other than Java, but the details are buried in old Forum posts. I’m curious who’s doing this today and how common it is. Also what tools people find useful for doing this and any languages not on the above lists.
To jumpstart discussion, here is a simple poll. Please indicate which languages you’ve attempted to use JMonkeyEngine with:
I use Groovy (JSR 223) for my current game’s level design. But I’ve also been using Kotlin in a few toy projects just to see how it goes. I like the results so far, and I’ll probably use Kotlin as the primary language for my next project.
I am currently using three different JVM languages for my games:
scala: a core framework I reuse for my games and my level editor are written in scala.
I started them some years ago since I really liked scala as a language. I also wanted to try a specific lib (akka-actor, now pekko) that was common in scala community.
Now I regret that decision a bit, while I still like scala, java has improved in the recent years and the scala tooling is not very good (currently using neovim+metals).
Also scala releases tend to break backward compatibility so some migration work needs to be done, currently I haven’t made the jump from 2.13 to 3.x and I’m not sure if I will.
Another slight problem is that it’s easy to use java libraries from scala but not the other way around, so my framework is hard to use from java (as you’ll see).
groovy: my framework handles scripting, this includes game logic (behavior for game objects) and a DSL to define game and level data (imagine a fancier json - I can provide examples).
My plan is to let the users modify these files or create mods without having to use compilers or any external tool (other than the level editor), just text.
java: Finally the actual game is a small java program that includes a few implementations needed by the framework, plus some custom states and post processing filters and all the groovy scripts. I could have used scala here but it’s more convenient not having to deal with the scala tooling, only problem is dealing with those scala classes from the framework (but there are just a few and I made a facade to hide the ugly code).
So overall it’s a bit complex arrangement, but I like having the core tools separated from the game logic. I might prefer to have them in plain java for simplicity at the expense of losing conciseness and expressiveness.
Mythruna is (hopefully well known by now) a hybrid of Java and groovy. The core engine is Java and the game logic is groovy with some built in modules to make it feel more like a DSL.
I have also done tools and prototypes that were essentially a thin Java boot-strap that runs scripts.
Part of the MOSS set of open source packages (unreleased) is also a module system that allows for dependencies, overriding existing modules, runtime reload, etc.. I use this for almost everything I add scripting to… or at least eventually do because I often think “It will just be easier to call groovy directly here…” then a few hours later want the dependency loading and auto imports and stuff again.
I just remembered that I was able to run C# code from Java. The trick was loading the CLR into the JVM and use JNI for the interop. It worked but it was fragile and it was necessary to convert data types from one language to the other. Not so good experience overall.
My apologies, I should’ve written this right after I voted.
I mainly use Java with JME3 as usual, however I also wanted a scripting implementation for my game, and after a bit of digging I found a library called luaj. Suits me since I’m quite familiar with lua.
After a bit of tinkering and figuring out the docs, I got the hang of it. At first I used simple java<>lua conversion methods offered by the library to directly convert any existing java objects into lua and use/modify them as needed in lua scripts (kind of like through wrappers I suppose). Later, instead of continuing to use the java<>lua wrappers, I decided to get a bit more fancy and started writing a fully custom tailored lua API for my game (with luaj), as the wrappers exposed a bit too much “under the hood” stuff, since they include all fields and methods of every object in question with no filtering. I’m a control freak when it comes to external scripting APIs for my games, so I want to have 100% control over what classes, fields and methods are available there. Luaj certainly made that possible.
That’s about as far as I’ve gone with JME-on-Kotlin, unfortunately, because I’m a NetBeans user, and NetBeans doesn’t offer good support for Kotlin.
I imagine some developers might be interested in using “duck typing”. Duck typing isn’t well supported by Java, though I gather Zay-ES implements it. OTOH, duck typing is essential to many of the other languages on my list.
Yes that’s correct.
According to ChatGPT, most of the languages were developed originally in Java (actually all of them except Eta which was developped in Huskell) and most of them are still implemented in Java:
I also share my experience. I started a small project with Kotlin using JME Java dependencies. It went smoothly. I did it to introduce myself to Kotlin. I like the language features it has, I could work faster than in Java because it reduces boilerplate.
I’m nervous about using Luaj in my projects because org.luaj hasn’t published a release to MavenCentral since 2015. The GitHub site shows releases in 2017 and 2019, but I don’t know where to find pre-built JARs for those releases. The last visible commit was in 2020.
As long as things just work, this is fine, but what if I need support? Do you know if there’s a user community for Luaj?
I put Kotlin more in the scripting category. I used it before when I was learning and writing Android Applications. I was using it as a form of scripting language to build the Settings Activity logic, but I would say I prefer low-level languages when it comes to infrastructure, you will anyway write the infrastructure only once, so it’d better be clean and precise.
Nowadays, Kotlin has its native compiler that is independent of the Java platform, and it can compile Kotlin natively to a wide variety of platforms including Web and iOS platforms.
I would say, Kotlin will much fit the category of writing AppStates logic much easier than Java, but major APIs had better be in Java, and ofc Kotlin DSL is used as a substitute for Groovy for Gradle build logic.
