[Poll] Drop support for Java 6/7, require Java 8

[Spasi]

If you're in favor, add a +1 reaction (see the upper-right corner of this message).

If you're against, please add a comment explaining your use-case and why Java 6/7 compatibility is important to you.

---

The LWJGL 3.0.0 release is long overdue, but this gives us an opportunity to reconsider our choice of minimum supported JDK version.

What's the big deal?

Lambdas and default methods in interfaces.

What will change?

Changes in the public API will be limited to callbacks. It will be possible to implement callbacks with lambdas directly, instead of going through factory methods.

The rest will be internal changes.

Why now?

Many other libraries, frameworks and tools are moving to Java 8+ compatibility. Even Android supports Java 8 now.

Why not Java 7?

Java 7 has a very limited set of new features and APIs over Java 6. Java 8 on the other hand is a major upgrade.

Java 8 is also widely used these days and Java 7 is already obsolete; no public updates since April 2015.

What about Java 9?

Java 9 is also a major upgrade, but LWJGL will be able to take advantage of it transparently. See Multi-Release JAR files.

What's the plan for future versions?

The current plan is for LWJGL 4 to be the next major release that will break API compatibility. It will come at a time after Java 10 is available and will be designed to take advantage of value types and Project Panama, in whatever form they make it into the JDK.

[intrigus]

Against.
I think that Java 8 is still not enough used.
See http://www.baeldung.com/java-8-adoption-march-2016

I'm fine with dropping Java 6.

[renannprado]

@intrigus I believe that the kind of software developed with LWJGL (games, in general) shouldn't rely on the JDK/JRE that is in the user's machine, so it would be a better practice to bundle the JDK/JRE which is known to work with your software and it's much better experience for the end user.

I don't see why not upgrade to JDK8. 👍

[huhlig]

@intrigus Java 7 had its end of life in April of 2015. Also the article you mentioned seems to be specifically indicating server side. Client side I am betting is much much higher, given the nag screens oracle implemented in 7. Since most customers running lwjgl will be desktop users who likely are running whatever latest version is available and NOT have a severely locked down machine. I doubt this will be much of an issue. I do admit that if you're running on a server for OpenCL/Cuda this might be an issue however. I vote for 👍

[kappaOne]

Just some points to note, dropping Java 6 will mean dropping support for OS X 10.6 (and lower) as Java 7 requires OS X 10.7+. Dropping Java 7 will mean dropping support for OS X 10.7 (and lower) as Java 8 requires OS X 10.8+. Although it should be noted that subsequent OS X updates have been free for most, so shouldn't be that much of an issue.

[intrigus]

Dropping Java 6 should be ok, since GLFW doesn't support OS X 10.6 anymore.

[darkyellow]

I think LWJGL should move with the times and push forward with a modern jvm, Java 8 has been out for 2 years so its not new and its not unreasonable to assume a large proportion of non corporate users will be on this version

[pakoito]

Many other libraries, frameworks and tools are moving to Java 8+ compatibility. Even Android supports Java 8 now.

Beware. Android supports lambdas at compiler level, and some APIs if you target the latest version or above. It'll be at least 5 years until the transition is complete, as we're still in Android 4.1.1 cutoff, and Android 5.1 at ~6%

If you break Java 6 compatibility by using any of the Java 7/8 APIs, you're cutting any Android possibility out. Maybe that's what's intended.

[JustGregory-zz]

@pakoito I think in some respects, yes this needs to happen. Consumers will have to push-back against the Android implementations not upgrading at all, or not upgrading so speedily. I will 1000% prefer dropping compatibility with older Java releases, so long as the long-term outcome will be better down the road.

I mean, the older lwjgl versions will still be available, will they not? So that forward-looking developers will be required to update their Javas as well, and those who want to stay with an older lwjgl release still have an option; just not the most current.

[gustav3d]

its time to move forward to java 8, people who need older platforms can use older LWJGL.
There will always be arguments to stay at 10 year old technologies, but no one forces them to upgrade to latest LWJGL

[quazi-irfan]

Does the only benefit "Lambdas and default methods in interfaces." justifies ignoring the widespread uses of Java 7?

[JustGregory-zz]

I believe providing default method implementations means that an implementation of an interface no longer has to provide their own methodology for interface methods in which a default methodology will suffice -- thereby reducing to an extent the duplication of code which might be common across all uses of said interface.

I would admit to not having all that much practice with usage of lambdas; where my IDE gives conversion to a lambda as an option, I hesitate, perhaps because I hold to some legacy-code way of doing some things... But, I'm getting there....

[pakoito]

If you open up lambdas you open up functional and reactive programming, including the Stream apis, CompletableFutures, and more QOL improvements Java users have to get used to. They're also available in Java 6/7 through frameworks too, but it gets very verbose.

[Spasi]

Does the only benefit "Lambdas and default methods in interfaces." justifies ignoring the widespread uses of Java 7?

No, it doesn't. Callbacks have a very small API surface and most improvements will only be felt by the project maintainers.

On the other hand, the widespread use of Java 7 does not justify not moving LWJGL 3 to Java 8. Most such uses are in server applications, stuck on legacy frameworks. The point is that there is no good reason to NOT require Java 8. The votes/responses so far confirm this. LWJGL 3 is not Spring, it isn't backwards compatible and there are no existing huge codebases that need support. We could support Java 6 (or 1.4 even), but we don't have to.

On Android support: The current assumption is that it won't be possible to download "LWJGL for ARM" and have it work on Android without changes. It will be possible for systems like the Raspberry PI, but Android will probably require special handling and changes to the library core and even the binding APIs. This means a fork maintained separately, we could make a different choice for the required Java version there.

Disclaimer: I have zero experience with Android development, I don't know what the best approach will be and the above is subject to change. LWJGL 3 depends on low JNI overhead, good NIO buffer performance and Unsafe intrinsics. The situation on Android (no "real" JVM, AOT compilation, the NDK) is complicated and everything will be determined by actual testing.

FWIW, I ordered an Nvidia Shield today and will start experimenting some time after 3.0.0 is released.

[dustContributor]

Android LWJGL doesn't seems reasonable until Google has OpenJDK running on most of the devices.

The whole mix and match between Apache Harmony libs and Google's stuff is a pain in the butt to work with honestly, at least coming from desktop Java.

[Spasi]

With the #182 changes, the transition to Java 8 is now complete.

Java 8 compatibility enabled another nice improvement to the public API: MemoryStack now implements AutoCloseable (a Java 7 feature really), which means it is now possible to write code like:

try ( MemoryStack stack = stackPush() ) {
    // ...use the stack...
}
// no pop() required!

This is the relevant commit.