Use Scala 3 threadUnsafe lazy vals#1818
Conversation
|
Seems that sources emitted for Scala 3 are still tested against Scala 2.13. This change seems to break this test. Out of curiosity, could you please share, what is the idea behind it? That latest Scala 2.13 should work with Scala 3 sources? |
|
It's been a while, but I found this statement in https://scalapb.github.io/docs/customizations/:
See also #1316 - some users were (are) compiling their project with this flag. |
|
I've been thinking about it for some time, and I had interesting observations: I couldn't find any reasons why someone wants to generate Scala 2 sources when compilation target is set to Scala 3. That's why the question pops up: should Scala 3 source generation to be forced when compiling for Scala 3? So the option This could then unblock optimizations like this, that will be enabled only for Scala 3. Also with time the If you see sense in making |
|
Closing it, benefits doesn't cost amount of changes that are needed |
Hi!
Scala 3 introduced faster mechanism of initialization for
lazy vals: link to docs.I want to propose adding it to some of the lazy val's in the generated outputs.
The reasoning is that there would be no harm if in the worst case scenario default values are initialized more than once and then GCed, but instead there will be a) no thread-locks during the initialization b) much less byte-code and faster compilation, since they are used a lot. Lazy vals for variables inside of the
*Protoclasses (decoding of the protobufs) left as is (no @ThreadUnsafe annotation added), since it may be more costly to initialize those values more than once.Here is the example of 2 classes, with annotation and without:
And here is the bytecode that is produced (decompiled to Java code):
What do you think about this change?