Move to Java 8

[nhojpatrick]

Hamcrest future

Bump minimum version of Java to Java 8.

Most projects in my view that are using Java 5, 6 or 7, are stable, they are happy with the features currently provided in Hamcrest v1.3, or would be find using version 1.3 if they wanted to use Hamcrest. Not bumping the version I feel holds back hamcrest as after decades of years between Java versions it is now only 6 months before potential new changes are out and hamcrest should be reworked to handle the sudden step change.

Rebel Labs via Zero Turnaround did a conference, and 86.9% are using Java 8 for their main production application, with 6% Java 7 and 2.8% Java 6 or older.

9:52 mark in this Devoxx UK 2018 video
https://www.youtube.com/watch?v=vPqMWPJNSoA&index=90&list=PLRsbF2sD7JVpRvLpv_Cub94zsM1aHm-Op

[sf105]

This is obviously an important move. I think that Java 8 is a big enough change that it probably should have a new version and an API that exploits new features. A first step, however, would be to get everything to compile.

What I'm seeing is that more people than you might expect still have Java 7 code, so we should be careful about leaving them behind.

[nhojpatrick]

What about starting multiple parallel branches per java version. Then merge into the correct branch and forward and fix as required.
v2.x Java 7 or newer
v3.x Java 8 or newer
v4.x Java 11 or newer [NOTE 1]

Not sure what else to suggest otherwise those that do more to Java 9/10/11 will experience potentially more and more issues and might not be able to use hamcrest depending what the issues are.

NOTE 1 - no point Java 9 as already EOL, Java 10 will be EOL sept 2018 when Java 11 is out and that is LTS. And it might take a few months to decied and agree what approach to take and start implementing changes required.

[thespags]

@sf105 what's the biggest hurdle or blockers for updating to java8? Is it technical like overcoming generics or having the capacity to work on it?

If it's technical, I like to better understand the root of the problem. If it's capacity, I keep looking for places where I can help, but I need to see what are the challenges.

[sf105]

challenges.

• I fear we still need to support Java 7, but maybe that could just be frozen.
• for similar reasons we probably ought to support Java 8 for a while.
• it's screaming for a more functional solution, but I haven't quite got the confidence about how to get there from here.

I like @nhojpatrick's numbering scheme.

[ghost]

What I'm seeing is that more people than you might expect still have Java 7 code, so we should be careful about leaving them behind.

@sf105 @tumbarumba these people can still use java 7 compatible old versions. What you probably do not see is that java 8+ based projects use hamcrest 1.3 + 3rd party extensions or own matchers libraries. E.g. mine MoreMatchers class has about 10 new methods. It's a nice coding exercise, but I'd prefer to take it from the standard lib.

Also I still do not understand your argument. What is the problem to support two generations of hamcrest simultaneously (like spring does; spring 4 does not require java 8; spring 5 requires java 8+) with separate set of versions?

[nhojpatrick]

I am a person that was until recently still developing a Java 1.6 application, it was finally upgraded to Java 1.8. But the code changes were minor upgrades and patches.

I accepted that the project would be left behind as we are running on out of support java and frameworks. Also we would not be actively looking at new features from frameworks, we would be using new features as use cases as supporting reasons the project needs to be uplifted so it is in supported version...

Another reason we should upgrade to Java 1.8, you can no longer do a fresh checkout and build of hamcrest using Java 1.7.

$ java -version && rm -rf ~/.gradle/wrapper && ./gradlew --version
java version "1.7.0_80"
Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
Downloading https://services.gradle.org/distributions/gradle-4.10.2-bin.zip

Exception in thread "main" javax.net.ssl.SSLException: Received fatal alert: protocol_version
	at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
	at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
	at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1979)
	at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1086)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1332)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1359)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1343)
	at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1301)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254)
	at org.gradle.wrapper.Download.downloadInternal(Download.java:66)
	at org.gradle.wrapper.Download.download(Download.java:51)
	at org.gradle.wrapper.Install$1.call(Install.java:62)
	at org.gradle.wrapper.Install$1.call(Install.java:48)
	at org.gradle.wrapper.ExclusiveFileAccessManager.access(ExclusiveFileAccessManager.java:69)
	at org.gradle.wrapper.Install.createDist(Install.java:48)
	at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:107)
	at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:61)
$

Circa 2004-2012, everyone complained that Java was slow to update, it took a few more years but since Java 9 it is being rolled out every 6 months with LTS every 8 releases, and Java 17 LTS is out Sept 2021.

All open source projects need to start doing roadmaps regarding dropping older version and supporting newer versions. So users when picking up newer versions know how long they have that major version in support for. Like debian, it's clear https://wiki.debian.org/DebianReleases