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
