Java9 support

[mudlee]

Hi.

Can you update the project to be able to use it under java9 with modules?

[DaanVanYperen]

Hi @mudlee, Thanks for the suggestion! Bit of a ramble coming up, sorry!

Unless there is a way to support modules while still targeting java 8, I don't think this will happen soon.

Currently we are stuck on language level 8:

• GWT is holding us back (see 2.8.2 notes at http://www.gwtproject.org/release-notes.html).
• Most of our users also target LibGDX. The LibGDX team has stated LibGDX is in maintenance mode and stated there is insufficient reason to move beyond JDK 7 (just yet). [Dicussion] An argument for upgrading to Java 8 libgdx/libgdx#5487
• We currently can't even compile the project on a JDK 9+ because of artemis-odb-gwt-integration-test does not compile on JDK9+ #534
• Android?

The Java game development world seem to have been pulled into a bit of a schism as Java as a language is now outpacing established projects (GWT, LibGDX) in the maintenance end of their life cycle, and the landscape has changed a lot if you want to target other platforms.

The LibGDX team says it is committed to maintaining the project. As it stands now it is unlikely to evolve much further and will probably stick to java 7 for the foreseeable future. The framework is still solid, their discord is thriving and pull requests are anything but dead. I'm just hoping they can find the time to put the community to better use. Not sure if they have the time to review and streamline the contributions, let alone support a new major version.

Question is where that leaves artemis-odb. If nothing changes we'll have to make do with java 8 for the foreseeable future. While there are plans the framework is pretty feature complete and I suspect the main thing users want is some bugfixes, help on the more obscure features, and guaranteed support for the coming years.

My real concern is the what happens when a significant rewrite of LibGDX is required when the GWT backend eventually needs to be replaced. A fork of LibGDX doesn't seem viable. It's more likely the community will move on to alternatives like https://github.com/libktx/ktx. For me personally the familiarity with Java and the ability to target web is the main reason I've stuck around.

Interested to hear what you guys think. Blank spot for me is where you guys are headed. Are you sticking with LibGDX? Are you looking at alternatives?

[manabreak]

I've been working with LibGDX and Artemis for quite some time now, and I plan to stick with it at least until I finish my current project which might take another year or so. I actually had to write my own GLES 3.0 support for it, since the current support in LibGDX is quite lacking. Surprisingly, it wasn't that big of a task, as most changes were really minor.

Since I'm an Android developer by day, I can shed some light on that. It's true that Android only recently got "official" support for Java 8. However, this post by Jake Wharton suggests that the runtime on Android should support all the upcoming Java features. I'm a tad cautious, but based on that, it should be possible to bump up LibGDX and Artemis to post-8 versions.

As someone who's been working with and enjoying both of these libraries, I might be able to spare some manpower towards maintenance and upgrading if needed.

[DaanVanYperen]

Thanks for the reply @manabreak! Looks like this is a very active topic in the libGDX community so we'll just have to see where things land. We're committed to maintaining things on our end (and perhaps put a buck in the other end where needed 🐙).

[jrb0001]

There is a maven plugin "moditect" which supports creating the module descriptor with javac 8 (and maybe 7? not sure). The much bigger issue is that modules can only depend on other modules. There are three different situations with that:

1. The dependency is modularized as well. This is the optimal case
2. The dependency isn't modularized but defines Automatic-Module-Name in META-INF/MANIFEST.MF. This makes it an automatic module with a stable name if it ends up on the module path.
3. The dependency isn't modularized and doesn't define Automatic-Module-Name. Same as option 2 except that the module name depends on the filename. Avoid this at all cost in my opinion.

Java 9+ makes it really easy to create specialized runtime images with a single command. Such an image contains the platform dependent JRE, all needed modules and wrappers for easier launching. The size is also reduced compared to a standalone JRE/JDK because it only includes the modules (and dependencies) which you specify. This obviously doesn't work as soon as there is a single automatic module (option 2 and 3) because they depend on the whole module path implicitly.

[Mr00Anderson]

I am excited for Java 13+. have been hanging back with Java 8 because of the Unsafe Buffer removal and the performance it gives Networking on direct buffer reads. I decided to use this library so I could skip out on libgdx and move up to the newest one when its time (Value Types, Valhalla, ext ext) if GWT and libgdx do not push on. I would think a lot of people are waiting to move on from Java 8, until something better comes along like reified generics, value types and generic specialization.