> 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.
Yeah this is what the main issue is, I would be more amicable to building the docs on JDK 11 if there was some way to designate the JDK version to link against for the docs. On Sat, Feb 10, 2024 at 9:17 PM Arnout Engelen <enge...@apache.org> wrote: > 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 > -- 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
