Remove build on OpenJDK 7 because it's deprecated

[krichter722]

No description provided.

[sf105]

This one is tricky because, although Java 7 is deprecated, a great many sites are still using it. Similarly for Java 8.

[krichter722]

I proposed this in order to facilitate #214 which you vetoed, but it can be realized by enforcing checkstyle version 6.18 which runs on JDK 7 versions, like I proposed in #216. The rulesets format changes with 7.x or 8.x which requires to update a small number of rules as soon as builds on JDK 7 is no longer supported and the checkstyle version upgraded.

[krichter722]

I think that it's not overkill to only support JDK version >= 8 for building while they can still be used with versions < 8. Users who still run their applications which use JavaHamcrest using JDK version <8 will not notice the change. Oracle and OpenJDK 8 are long term support versions afaik (like version 11) and will be supported for a long time while 9 is already deprecated again. Up-to-date versions are supported by Travis CI only through Docker.

[sf105]

I agree with you for desktop/server. There's still the problem of the Android users (I've had no luck finding someone there to talk to). I'm increasingly convinced that we should split the project into <=7, and >=8 builds. Noone seems to have noticed the new java-hamcrest artefact, so time to revert to upgrading hamcrest-all?

[krichter722]

@sf105 FYI, I rebased this PR to remove all old Java versions (11 already is deprecated, but might be in use) and include the latest OpenJDK versions in Travis. Maybe you've changed your mind about this. I didn't stumble over JDK <= 7 for years, now.

[sf105]

Again, Joe's call. I'm at a client that is in the process of writing a lot of new code in Java 8 (!). Maybe it is time to drop 7 as no-one in the Android world will even answer an email.

[tumbarumba]

I'm inclined to leave the Java 7 dependency in for the moment. I don't have a clear picture of the full scope of where people use Hamcrest, and what their needs are. Having said that, I think that Hamcrest needs a very conservative policy on backwards compatibility. It interesting to note that JUnit 4.13 still supports Java 5, even though that has been unsupported for years.

Even with the above, I think Hamcrest needs to grow, and adopt more modern language features.
Issues #206 and #207 are a good place to discuss exactly how we do that (there are already some good suggestions in those issues).

I'm closing this PR, and we can continue discussion in the other issues mentioned.