-
There's a plant of topics in which we might need help. To name a few, we might need some help in [porting the remaining JSR-166 types](https://github.com/scala-native/scala-native/issues/3165) to Scala Native shipped with future experimental multithreading support, but also large parts of the Java standard library need some improvements or reimplementations. Last but not least, we need people dedicated to the optimization of our current toolchain to make it use fewer resources and allow for faster builds.
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
-
When it comes to actual implementation details, then it's not guaranteed, especially since we cannot just copy the actual copyrighted implementation of JDK, unless some parts are using some more friendly license, like the whole JSR-166 or outdated Apache Harmony. So again it's mostly covered with the unit tests that we come up with and by following the documentation.
-
Scala Native has much more control on how the Scala AST is compiled, and can easier workaround platform limitations, eg. lazy vals in Scala 3 required reflection config for Native Image (see this and that), while in Scala Native we could mitigate problems with unsupported usage inside in other ways within the compiler plugin.
