Arnout Engelen

> In principle I am also against putting IDE specific functionality into the main repo's. Pekko should be entirely IDE/editor agnostic and if we go down this road then we...

Summarizing this thread, the main remaining roadblock is the risk that we'd unintentionally accept an update of a runtime dependency that drops support for Java 8. Any ideas on how...

> the issue regarding building with JDK 1.8 has largely been solved I think it could still simplify our build quite a bit (e.g. #1194). Given how complicated our build...

> I think we can refactor some of the unit tests subprojects (eg `actor-tests`) so that it doesn't depend on the sbt module but depends on a jar in mavenLocal...

> When you run actor-tests for Java 21, why do you need to use actor code built with Java 21 ? You don't ;). Running the unittests from the same...

As time has moved on, I think it's no longer useful to put effort into requiring Java 11 just for building Pekko, and we should work towards requiring Java 11...

Moving this to 'draft' since this change would increase the chance that we inadvertently accept a change that would break developing Pekko on Java 8. Discussion around this is ongoing...

> Because sometimes the actor don't put value into MDC Doesn't that mean the test caught a bug?

> ThisActorSystemQuarantinedEvent is in package org.apache.pekko.remote.artery. There is also a similar Akka class but the Pekko SplitBrainResolver will not be listening for Akka ThisActorSystemQuarantinedEvent events - only Pekko ones. How...

> Found another case of non determinism, issue filed at [scala/scala3#18248](https://github.com/scala/scala3/issues/18248) We attempted to work around this issue with #708, except it appears this workaround is not yet effective. I...