[Dicussion] An argument for upgrading to Java 8

Now, I know there’s been a few issues and PRs requesting Java 7 support posted here already. Nearly all of them have been closed for various reasons, mostly related to Android and GWT compatibility. Regardless, I would like to discuss the possibility of upgrading source compatibility to Java 8 across the entire codebase.

Why?

Java 7 and 8 come with some language features that, in my opinion, could greatly improve the codebase:

• Diamond operators could be used to reduce generic declaration redundancy
• Default methods could be used in classes like ApplicationListener to automatically provide ApplicationAdapter functionality out of the box without creating a separate abstract class
• Static interface methods could improve code organization
• Listener utility interfaces could be created and used in Scene2D in conjunction with lambdas to provide much cleaner listener support, e.g. button.clicked(e -> System.out.println("Clicked!"))
• Lambdas could be used instead of anonymous classes across the codebase, e.g. when posting Runnables to an application or using gdx.utils.Predicate in Arrays

But isn’t Java 8 unsupported?

No, Java 8 language features are currently supported across all libGDX backends. This includes GWT, Android, Desktop and RoboVM.

What about minimum Android API levels? Will they need to be increased?

No. According to the Android documentation, default interfaces, static interface methods and lambdas work at any minimum API level, even across third party libraries.

But the new Java 7/8 API additions don’t work on Android/GWT/RoboVM!

This is mostly true. java.util.stream, java.util.function and other subpackages and classes are not supported at the current libGDX minimum Android API level. However, they don’t need to be. Many, many packages and classes from Java 6 are already unsupported in Android, and these new 7/8 API additions are no different. The solution is to not use any new API from Java 7 or 8. I am proposing this upgrade for the sake of the new language features, not new API.

What this means is that if you want your game to run on older phones, you don’t use any new Java 7/8 API, just like you don’t use java.lang.reflection.* on GWT or java.awt.geom.* on Android. This is not something that should be a problem. Most modern IDEs warn users when their code uses classes that are not compatible with their minimum API level.

Has Java 8 been tested on these backends to make sure it works?

Yes. If you’re doubtful, I can personally attest to having a game that uses plenty of Java 8 lambdas and default methods, while running fine on older Android phones, iOS and HTML5.

Upgrading to Java 8 will break things!

No, it won’t. The version of the Android plugin used in gdx-setup already supports desugaring Java 8 features, and the current version of GWT supports Java 8 as well. Java 8 has been out for more than 5 years now, and thus most developers should have upgraded to it already.

[MrStahlfelge]

@NathanSweet Thanks for your friendly answer. However, I disagree on some points.

Is libGDX in maintainance mode because there is general lower interest in it, or is lower interest in it because it is in maintainance mode? They casuality may be exactly in the opposite direction as you suggest. If I were a new interested user, I would probably not decide to use libGDX for my game after taking a look at libGDX homepage, the recent release count and the forum threads.

we merge PRs that are clear improvements

Unfortunately, that is not true. There’s PR #4265 still open for two years for a faster GWT bootstrap process. That’s a clear imrpovement. Unfortunately, it cannot be merged any more and the committer is not active any more. If you say this is a more complicated PR - which is true - than take #4137 as an example of a clear improvement that was not merged for two years. What about #3457? It is also a clear improvement because core libGDX scene2d lacks focusable support. But I doubt you will approve it, so please at least make a statement and reject it.

What the project really needs is maintenance help, not backend improvements. 73 PRs and 244 issues as of this writing is already way out of hand. We used to keep it to just a few, but we don’t have the bandwidth anymore. If you want to help out, please consider monitoring issues and PRs.

I do that for the last 12 month, and it is neither help nor satisfying. I can comment on issues, that’s all I can do. I can’t merge PRs that I think are good, I can’t deny ones that I think are not. I cannot discuss with others about the PRs to get things done: Where is the libGDX decision board to address if this issue - upgrading to Java 8 - is rejected or accepted? Same for #5482, I stated my opinion there and it is likely that this PR will never get merged nor rejected. So why should anyone invest a lot of time in testing some other, more complicated PRs or issues if the invested time leads to nothing? You need help from developers, and for the invested time developers don’t want to just support the status quo, but want to have a voice and improve things.

Just to make it clear, I heavily respect the work you and others did here. But in my opinion the project deserves and needs more efforts than it gets the last 12 months. I will end the discussion on this issue now because Anuken is right, it is off topic here. But there was a need to say it.

[NathanSweet]

Likely most of those situations where <> would be useful could also be changed to not use generics at all. Eg, in Array, I assume the 2 “warnings” are:

static public <T> Array<T> of (Class<T> arrayType) {
	return new Array<T>(arrayType);
}
static public <T> Array<T> of (boolean ordered, int capacity, Class<T> arrayType) {
	return new Array<T>(ordered, capacity, arrayType);
}

I would prefer changing both of these to new Array(, which is even fewer characters than <>. I really don’t care about the “usage of a raw type” warning (which we have disabled for libgdx, at least in the Eclipse projects). I happily use raw types to have less typing and less code. I usually do this in my contributions, others may like having duplicate generics on the RHS (eg because they are terrible people).

As for performance, probably Tom-Ski was referring to the stream API stuff or similar, which may allocate (I don’t personally use it, goddamn kids with all their fancy new features!).

Putting aside there are few new additions to libgdx, I don’t feel it’s super important to use Java 8 for new additions since avoiding it is very easy.