On Sat, Feb 10, 2024 at 10:51 AM Matthew de Detrich <matthew.dedetr...@aiven.io.invalid> wrote:
> > 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. > > Sure if someone wants to go ahead then they are more than welcome to try, > just need to be careful that both the paradox docs and binary artifacts are > exactly the same before and after. OK! The API docs would link to the Java version you're building with I suppose, but I don't see that as a problem: we can't predict what JDK users will be using anyway. >From my end we still need to republish paradox 0.9.x on maven just due to > the 1.0.x branches so I will continue to get that done. > OK > I would also posit that a nicer solution to this would also be getting > sbt-multi-release-jar[1] to work because currently we have a more > recurring issue where we want to use features in newer JDK's (such as > loom/virtual thread for JDK 21) but we can't while supporting JDK 8 without > a lot of hackery (if it's even possible). > Unfortunately I am hitting some fundamental issues[2] on trying to get it > to work > I agree that might be interesting but require a lot more r&d to find out if it's viable. Kind regards, Arnout > > 1: https://github.com/sbt/sbt-multi-release-jar and > https://github.com/sbt/sbt/discussions/7174#discussioncomment-5288982 > 2: https://github.com/sbt/sbt-multi-release-jar/issues/24 > > On Sat, Feb 10, 2024 at 8:45 PM Arnout Engelen <enge...@apache.org> wrote: > > > 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 > > > > > -- > > 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
