v0.9.94(Important version)

Resolve Bugs

#1051, #1053,#1066, #1078, #1084, #1086

New API

Jimmer uses a lambda-style API to create immutable objects (which may be created from scratch or copied and constructed based on existing objects—this is not important). Inside the lambda, users manipulate a mutable Draft object; outside the lambda, the ultimately created object is immutable. In principle (Not absolutely), what the user obtains is a clean immutable object (not a Draft).

However, for complex programs, multiple layers of lambda contexts may be nested. Different contextual logic might exist across various code modules, which can make such nesting relationships difficult to detect at times. In essence, this nesting relationship is similar to the transaction management in an IOC framework, where such contextual nesting information is maintained by ThreadLocal.

All draft objects are resolved into immutable objects when the outermost lambda concludes. This process is referred to as resolving the draft. The outermost creation behavior returns a clean immutable object (not a draft), while inner creation behaviors directly return drafts. This default strategy is designed to optimize efficiency for complex object operations.

However, there are times when users may not know whether their creation context is the outermost layer but still need to ensure that the created object is a clean immutable object (not a draft).

Starting from version 0.9.94, the new version of the immutable object creation function includes an additional boolean parameter, resolveImmediately (defaulting to false). Users can set this parameter to true to ensure the creation function always returns a clean immutable object (not a draft), regardless of whether the current operation is the outermost creation behavior.

• Java: BookDraft.$.produce(true, draft -> { ... })
• Kotlin: Book(true) { ... }