Drop Java 8
Hmm.. We decided to drop Java 8 for Play, see https://github.com/playframework/playframework/issues/11078. The problem is more and more libraries Play depends on are not getting published anymore for Java 8, see https://github.com/playframework/playframework/issues?q=author%3Ascala-steward+label%3Atopic%3Ajdk-next+is%3Aclosed+ Also slick just dropped support for Java 8: https://github.com/slick/slick/pull/2557
I guess, as soon as we publish Play with artifacts that are build with bytecode for Java 11+ you will have a problem with anorm (?) since you depend on Play libraries. We can wait to merge this here, but in the end I think there will not really be a choice. I know some projects still use Java 8, but there are no public releases anymore and more projects dropping it already...
Anorm 2.6.x and 2.7.x still support Java 8, right? If yes, I think it's a good compromise with the ability to move forward 🚀
Anorm 2.6.x and 2.7.x still support Java 8, right?
Yes, I am now just working against the main branch. So there could still be new 2.7.x releases with support for Java 8 (and Scala 2.11)
At least the pr is green now. I will convert it to a draft pull request. We can wait to merge it at the very end, after Play has a release with Java 11+ only support.
Hmm.. We decided to drop Java 8 for Play, see playframework/playframework#11078. The problem is more and more libraries Play depends on are not getting published anymore for Java 8, see https://github.com/playframework/playframework/issues?q=author%3Ascala-steward+label%3Atopic%3Ajdk-next+is%3Aclosed+ Also slick just dropped support for Java 8: slick/slick#2557
I guess, as soon as we publish Play with artifacts that are build with bytecode for Java 11+ you will have a problem with anorm (?) since you depend on Play libraries. We can wait to merge this here, but in the end I think there will not really be a choice. I know some projects still use Java 8, but there are no public releases anymore and more projects dropping it already...
I'm strongly against that choice. I would rather cut the dependencies (not many) that would be broken.
@cchantep Cedric, are you against with drop support Java 8 for Play or for Anorm?
The problem is a lot of people support dropping Java 8 in Play, see https://github.com/playframework/playframework/issues/11078
I would rather cut the dependencies (not many) that would be broken.
This is not possbile, some essential libraries do not publish Java 8 anymore. This is also becoming a security problem if we can not upgrade libraries anymore.... I think we have to realize that it's time to move on... We can not support Java 8 forever.
@cchantep Do you run applications on Java 8? Is it a problem to move to at least Java 11?
This is not possbile, some essential libraries do not publish Java 8 anymore. This is also becoming a security problem if we can not upgrade libraries anymore....
Matthias, it's not only with security updates. We needs a new versions of libraries (like Guice) for support a new version of Java (for example 17). And if we want that Play might be work with a new Java versions we must drop support old versions 🤷♂️ We can't sit on two chairs at the same time 🤷♂️ But of course, Play 2.8 and Anorm 2.6/2.7 can run on Java 8 as now.
@ihostage @mkurz Thanks for the feedbacks.
are you against with drop support Java 8 for Play or for Anorm?
I would say both. But much more against for the standalone library like Anorm, Play-JSON and Play-WS, where on one side a compatibility is lost and on this otherwise currently the compatibility is already there with quite no cost.
Do you run applications on Java 8? Is it a problem to move to at least Java 11?
I'm not the only one. I cannot always (unfortunately) chose the JVM version.
We can not support Java 8 forever
As long as enterprise are still deploying Java 8 (and against there is quite no cost to maintain the compatiblity).
If some really one some artifact specifically built for late JVM, then rather add a cross build with a specific artifact name.
With all the community drama the past years, and the drastic impact on Play projects, dropping compatibility really doesn't seem going in the right way for me.
It's not always so easy. If we want to support newer Java versions, we probably just have to drop older ones. For example have a look at https://github.com/playframework/play-doc/pull/155: It is upgrading parboiled to support Java 17. Now, the problem is, only the latest release supports Java 16+, but at the same time dropped support for Java 8, please see: https://github.com/sirthias/parboiled/pull/195 So what should we do now? Such things are happen more and more... A lot of people asking when will Play finally support Java 17, but basically no one was against dropping Java 8. We announced that along time ago: https://twitter.com/playframework/status/1513823030904082440 (no negative reactions). Also on https://github.com/playframework/playframework/issues/11078 just positive reactions. Also, we are "just" setting the baseline to Java 11 now. Spring 6 will be much more aggressive and will require Java 17: https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6 And given Spring is the king in the Java world, I think it should be acceptable to finally drop Java 8 in Play. Actually you are the first one that is really against that change.
Plus: You can still keep using Play 2.8.x, we will support it for a while (probably like 6-12 month when Play 2.9 is released. That should give people even more time to upgrade. Java 8 was released 8 years ago now, and probably it will be 9 when we stop support Java 8 in 2.8.x. Java 8 does not even has public updates anymore (do you pay for security fixes)?
It's not always so easy. If we want to support newer Java versions, we probably just have to drop older ones.
We didn't have such issue previously.
For example have a look at playframework/play-doc#155: It is upgrading parboiled to support Java 17.
That's why I would prefer to break this dependency, or as it's only tooling run only doc job in such JVM.
Also on playframework/playframework#11078 just positive reactions.
That's not comparable. Playframework is a framework, so already comes with more constraints and such update could not be such a big step there. But in project rather using standalone lib such as anorm or play-json (or play-ws), it's also because more flexibility is required.
Also, we are "just" setting the baseline to Java 11 now. Spring 6 will be much more aggressive and will require Java 17: https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6 And given Spring is the king in the Java world, I think it should be acceptable to finally drop Java 8 in Play. Actually you are the first one that is really against that change.
If the goal is to do another Spring, I'm sorry but then ...
@cchantep Cédric, how do you propose to drop support Java 8 for Play (we already know that we can't don't do that, because we must support Java 17), but still support Java 8 for Anorm? 🤔 If you have a clear plan how to do this, please share it 🙏
Either drop play-doc integration, or run it in a separate CI job.
Not sure what's the status about this but definitely agree that we should move on. Many major libraries and frameworks stopped supporting Java 8 (Mockito recently on top of my head). It's also our responsibility as maintainers to incentivize others to move on.
It's also our responsibility as maintainers to incentivize others to move on.
No it's not. Anorm is a standalone library. Not a framework. It should be as less intrusive as it can, considering the cost. And there the cost of maintaining compatibility considering the advantage is not in favor of dropping the support.