Missing mutable holder class

[GoogleCodeExporter]

http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/base/O
ptional.html mentions mutable holder class Holder though it is missing at the 
moment. Can this be added in the future?

Original issue reported on code.google.com by ra...@kubacki.cz on 3 Oct 2011 at 8:01

[GoogleCodeExporter]

IIRC the mutable holder has been left out due to somewhat limited utility.

Also, the base class of both the mutable and immutable holder (the latter being 
`Optional`) has been dissolved due to issue #704.

After all, I guess it is not planned to provide a mutable holder in future 
releases.

Original comment by j...@nwsnet.de on 4 Oct 2011 at 12:54

[GoogleCodeExporter]

Re limited usability: Swing desktop application can find it useful when you 
want to run code in event dispatch thread and get some result (think about 
displaying a dialog to confirm an operation or do more complex action). While 
executor libraries have possibility to run Callable returning a typed value 
Swing only support execution of a Runnable and thus there is a code like:

final MyResult[] resultHolder = new MyResult[1];
SwingUtilities.invokeLater(new Runnable() {... resultHolder[0] = result; });
...
// do something with the result

Depends on your decision. If you do not plan it then it can be enough just to 
clean up the documentation.

Original comment by ra...@kubacki.cz on 4 Oct 2011 at 1:23

[GoogleCodeExporter]

That code is a good example of why Holder *shouldn't* be added, if anything. 
Rather than a Holder<MyResult> or a MyResult[], you should be using an 
AtomicReference<MyResult> to capture that result. Or better yet, submitting a 
FutureTask<MyResult> to invokeLater and calling get() on it to get the result 
(FutureTask implements Runnable and can wrap a Callable so you don't need to 
have an actual ExecutorService).

Holder seems like something that might be useful in some cases, but if people 
decide they should use that for code involving multiple threads where it isn't 
appropriate that would be a problem.

Original comment by cgdec...@gmail.com on 4 Oct 2011 at 3:08

[GoogleCodeExporter]

We introduced such a class (actually, with a bunch more functionality, none of 
which is widely used), and we found it was largely used in places where it was 
expedient but not a good long-term solutions.  For example:

public String getUser(long id, Holder<String> emailAddressHolder)

...instead of...

public User getUser(long id)

public final class User { ... String username; ... String emailAddress; ... }

Or:

public void lookupAsync(long key, Holder<Data> holder, Closure closure)

...instead of...

public void lookupAsync(long key, Callback<Data> callback)

All that said, there remain good uses for Holder, and I encourage private 
helper classes where appropriate:

private static final class Holder<T> {
  T value;
}

Original comment by cpov...@google.com on 4 Oct 2011 at 4:16

• Changed state: WontFix

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:15

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:09

• Added labels: Restrict-AddIssueComment-Commit