Implement workaround for initialization order errors in JVM lambdas #448
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes a regression reported on Discord.
Previously,
IOLambda
was not sensitive to whether initializing thehandler
involvedval
s. This is because the definition ofhandler
was used lazily on the first invocation of the lambda, not during its construction.However, after the changes in #446, we now use the definition of
handler
eagerly during construction. Aval
in a superclass (i.e.IOLambda
) is always initialized beforeval
s in the subclass (i.e. user-definedFooLambda
). This means that allval
s in the subclass are uninitialized (i.e.null
) when we initializeval handle
inIOLambda
.The proper remedy for this situation is that users should always use
def
instead ofval
in theirIOLambda
s. However, because this is a highly surprising regression wrt the previous behavior, we now make a best-effort to detect this situation, log an actionable warning, and fallback to the old semantic where we initialize during the first invocation of the lambda.I've published this PR as
0.3-97de28d-SNAPSHOT
.