> I agree that would be nice, but is it a problem? Even if we could specify the JDK version to link against for the docs, we should perhaps link to Java 11 (or even Java 21): while we support Java 8, I think we should encourage users to use newer versions.
I don't know, I remember we tried messing around with this a year ago and we ended up reverting it for one reason or another (I would have to go back and find out now). For me it seems natural that the docs should target the same JDK that is the lowest common denominator but I can see how that is a weak argument. A stronger counter argument is that it's easier for developers to understand, mixing and matching different JDK's for different tasks is actually somewhat confusing whereas now it's simply "build with JDK 8 for everything" (aside from Pekko core) which is consistent and simple, even if it's outdated (although this can be solved with release flags especially with recent fixes that have come in via Scala 2.11/2.12 but still waiting for 3.3.2) On Sat, Feb 10, 2024 at 10:04 PM Arnout Engelen <enge...@apache.org> wrote: > On Sat, Feb 10, 2024 at 11:50 AM Matthew de Detrich > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > 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. > > > > I agree that would be nice, but is it a problem? Even if we could specify > the JDK version to link against for the docs, we should perhaps link to > Java 11 (or even Java 21): while we support Java 8, I think we should > encourage users to use newer versions. > > > Kind regards, > > Arnout > > > > > > 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 > > > > > -- > 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
