On Sat, Feb 10, 2024 at 8:57 AM Matthew de Detrich <matthew.dedetr...@aiven.io.invalid> wrote:
> > I think we should consider requiring Java 11 for all development: the > cost/complexity of requiring all our build tools to keep supporting Java 8 > will only increase, and IMHO is unhealthy to the wider ecosystem. The > cost/complexity of building with Java 11 and targeting Java 8 is low when > using the well-understood compiler flags, except when also using > sun.misc.Unsafe, but we have already incurred that cost for that case > anyway. > > the Pekko 1.0.x series is deliberately designed to > have minimal intrusive changes merged into it and so for this reason its > ideal > to have the current build setup remain the same, which means both building > with JDK 8 (or JDK 11 + JDK 8 workaround for pekko core) and paradox 0.9.x. > That makes sense, I'm fine with requiring JDK 11 only for building Pekko 1.1.x onwards. > My personal preference is to remain having JDK 1.8 as the preferred one > for development as it is now and rather instead spend our efforts to > strongly push for dropping JDK 1.8 altogether for Pekko 2.0.x. This would > allow > us to remove a lot of these hacks which would go a great deal in > simplifying the build. > I'm all for dropping Java 8 support completely on Pekko 2.0.x, and indeed it would allow us to simplify the build. I think requiring Java 11 for building Pekko 1.1.x would still be good. By the time Pekko 2.0.x happens, we might want to build with even newer versions of Java, so most of the work we do now to build with Java 11 and target Java 8 will continue to be valuable then as well. > While it is true the use of Java 8 sadly still seems widespread ( > https://newrelic.com/resources/report/2023-state-of-the-java-ecosystem > mentions 33%), I'm sceptical the same holds for developer environments. > > While I do broadly agree this is accurate, it's still preferable for > developers > to use the lowest common denominator JDK that the project uses just for > the sakes of lowering surprises especially when it comes to releases, this > is what I do. There are plenty of solutions that allow you to hot swap > JDK's > on local machines and on this note I was actually considering adding > .java-version files like in sbt-multi-release-jar[2] which forces the > project > to be loaded with a specific JDK. This may be a bit heavy handed but > it does a good job of enforcing expectations. It's a trade-off between the risks of developing on more recent JDKs while targeting Java 8, and making maintenance more painful by requiring development tooling to keep supporting Java 8. I think we should take the risk. Kind regards, Arnout > On Fri, Feb 9, 2024 at 9:57 PM Arnout Engelen <enge...@apache.org> wrote: > > > On Wed, Jan 31, 2024 at 8:44 AM Matthew de Detrich > > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > > My main concern is that since we are still supporting JDK 8, building > the > > > docs with JDK 11 can bring about actual legitimate usability concerns > in > > > terms > > > of consistency because we still have to build the main source code with > > JDK > > > 8 > > > but with docs we have to build with JDK 11 and so if we do this change > we > > > have a situation where if someone starts sbt with JDK 8 (because they > are > > > developing normally with the source code) and then do docs/paradox they > > > will > > > get hit with runtime bytecode mismatch errors. > > > > > > Now this can be solved with the the source and target flags i.e. > > > > > > javacOptions ++= Seq("-source", "1.8", "-target", "1.8") > > > > > > Which instructs the JVM to target JDK 1.8 but there are limitations > here > > > i.e. > > > the fact that it doesn't work sun.misc.unsafe[1]. > > > > > > > Luckily, only the main pekko repo uses sun.misc.Unsafe (pekko-http > > indirectly through pekko.util.Unsafe). > > > > The main pekko repo *already* supports building with Java 11 (and > requires > > it for releases) and targeting Java 8. While it is true it uses fairly > > horrible hacks to achieve this while also using sun.misc.Unsafe, this is > > already in place, and other components should be fine with the 'regular' > > flags for targeting Java 8. > > > > > > > There is also the other issue which is well, the compiled docs would be > > > slightly > > > misleading in the sense that they would link against the JDK 11 docs > when > > > in reality > > > our projects support JDK 8 and these docs do actually differ (JDK8 docs > > > differ > > > to JDK11 docs). > > > > > > I don't think this is an issue: while it is true we support Java 8, I'd > say > > users are more than likely to be on more recent Java versions, in which > > case the links to more recent Java versions will be more accurate. > > > > > > > I mentioned this somewhere (can't remember where) but it would actually > > be > > > ideal > > > if another release of sbt-paradox from the older series i.e. 0.9.x so > it > > > can be > > > deployed to the newer repositories. > > > > > > > I think we should consider requiring Java 11 for all development: the > > cost/complexity of requiring all our build tools to keep supporting Java > 8 > > will only increase, and IMHO is unhealthy to the wider ecosystem. The > > cost/complexity of building with Java 11 and targeting Java 8 is low when > > using the well-understood compiler flags, except when also using > > sun.misc.Unsafe, but we have already incurred that cost for that case > > anyway. > > > > The main remaining risk I see would be that we'd unintentionally accept > an > > update of a runtime dependency that drops support for Java 8. > > > > While it is true the use of Java 8 sadly still seems widespread ( > > https://newrelic.com/resources/report/2023-state-of-the-java-ecosystem > > mentions 33%), I'm sceptical the same holds for developer environments. > > > > > > Kind regards, > > > > Arnout > > > > > > > > > > [1]: > > > > > > > > > https://github.com/apache/incubator-pekko/blob/bcec7c0fa0cd9f68c4858d168f0dfadcb3ba4602/project/JdkOptions.scala#L71-L82 > > > > > > > > > On Wed, Jan 31, 2024 at 2:48 AM PJ Fanning <fannin...@apache.org> > wrote: > > > > > > > We have a slightly untidy sbt plugin setup in our various Pekko > repos, > > > > where we force the use of old Paradox plugins so that we can use Java > > > > 8 for doc building. > > > > > > > > Now that we have the 1.0.x releases done, can we consider switching > to > > > > the latest Paradox plugins and live with the fact that that means we > > > > need to use Java 11 for doc builds? > > > > > > > > Matthias Kurz has been publishing some new versions of these plugins > > > > because the versions that we use are not in Maven Central meaning > that > > > > we are dependent on the scala-sbt repository. > > > > > > > > Any objections to us at least starting with the Pekko repos where we > > > > have 1.0.x branches? We can update the main branches in these repos > to > > > > use the latest Paradox plugins and update the build docs. > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > > > > > > > > > -- > > > > > > Matthew de Detrich > > > > > > *Aiven Deutschland GmbH* > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > Alexanderufer 3-7, 10117 Berlin > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > *m:* +491603708037 > > > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > > > > > > > > > -- > > Arnout Engelen > > ASF Security Response > > Committer on Apache Pekko > > Committer on NixOS > > Independent Open Source consultant > > > > > -- > > Matthew de Detrich > > *Aiven Deutschland GmbH* > > Immanuelkirchstraße 26, 10405 Berlin > > Alexanderufer 3-7, 10117 Berlin > > Amtsgericht Charlottenburg, HRB 209739 B > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > *m:* +491603708037 > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > -- Arnout Engelen ASF Security Response Committer on Apache Pekko Committer on NixOS Independent Open Source consultant
