> 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.
This was actually brought up before when we asked to drop support for JDK 1.8 and what we learnt is that people seriously under-estimate how many companies/users are stuck on JDK 1.8, these even include companies where current frequent Pekko contributors work at. Unfortunately it's not really the developers who have any control here, otherwise we would probably be using JDK 17/21 already but it is what it is. > 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. In the grand scheme of things supporting JDK 1.8 hasn't been that much of an issue, there are for more pressing things that are creating a much bigger maintenance burden. The recent issue we are dealing with regarding moving away from Lightbend/Typesafe repo to maven is not even directly related to JDK 1.8, it's just that we have this transition period where we need to redeploy artifacts on maven central which I have been helping out with directly. The easiest solution to this specific problem is to redeploy the paradox 0.9.x series onto maven[1]. I don't want to stop others from helping out building the project with JDK 11+ but we have tried doing this in the past and realized the it is very brittle, we ended up breaking the doc generation (or the build) in weird and subtle ways. The other point is that 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. 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. > 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. 1: https://github.com/lightbend/paradox/issues/601 2: https://github.com/sbt/sbt-multi-release-jar/blob/main/.java-version 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
