[
https://issues.apache.org/jira/browse/LANG-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847820#action_12847820
]
Oliver Heger commented on LANG-609:
-----------------------------------
The {{get()}} method in the {{ConcurrentInitializer}} interface now throws a
{{ConcurrentException}}. This is a checked exception and forces client code to
always catch and handle the exception.
LANG-610 proposes a new {{ConcurrentRuntimeException}} class which is an
unchecked exception. It would be nice if the checked exception could
automatically be transformed into the unchecked exception. To achieve this we
could add convenience methods for the handling of initializers to
{{ConcurrentUtils}}, e.g.:
{code}
public static <T> T initialize(ConcurrentInitializer<T> initializer) throws
ConcurrentException;
public static <T> T initializeUnchecked(ConcurrentInitializer<T> initializer);
{code}
These methods could also be null-safe. The first variant would simply invoke
the passed in {{ConcurrentInitializer}}. The second one would catch a
{{ConcurrentException}} and transform it to a {{ConcurrentRuntimeException}}.
> Support lazy initialization using atomic variables
> --------------------------------------------------
>
> Key: LANG-609
> URL: https://issues.apache.org/jira/browse/LANG-609
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.concurrent.*
> Reporter: Oliver Heger
> Priority: Minor
> Fix For: 3.0
>
> Attachments: AtomicInitializer.patch
>
>
> In the new concurrent package there is already the {{LazyInitializer}} class
> implementing the double-check idiom for lazy initialization of instance
> fields. Another way to perform initialization lazily would be the usage of
> atomic variables. This solution would not need synchronization at all. If
> there is low contention (not many threads in parallel), it is more efficient
> than synchronized access. Its drawback is that the initialization may be done
> multiple times if multiple threads access the initializer almost at the same
> time (however, it can be guaranteed that always the same object created by
> the initializer is returned).
> This is a proposal to add an {{AtomicInitializer}} class as an alternative to
> {{LazyInitializer}} that operates on {{AtomicReference}} variables.
> In order to make the initializers smoothly exchangable, it would make sense
> for them to share a common interface. This interface could also be
> implemented by the {{BackgroundInitializer}} class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
