Copy arbitrary collections

[GoogleCodeExporter]

Currently we can't really do this:
   Map<Customer> original = ...
   Map<Customer> copy = Maps.copyOf(original);

Because we don't know the runtime type of original. I propose the following:
  1. Introduce a Copyable<T> interface that allows Collections (and possibly other types) to 
provide shallow copies of themselves.
  2. Implement said interface for all collections in the API
  3. Create APIs that can copy an arbitrary Collections. For things that implement Copyable, this 
would use that. For the known set of collections in the JDK, this would copy 
these using the 
most appropriate mechanism. For everything else, this should fail with a 
RuntimeException.

Difficult stuff:
- deep vs. shallow copies. For collections, I believe shallow copies are best. 
I 'm not ready to 
expand the copyable interface to anything else.
- wrapped collections. How to copy a TreeMap that's been wrapped with 
unmodifiableMap?
- other views. What do we do when we copy the keySet of a TreeMap?

Original issue reported on code.google.com by limpbizkit on 1 Nov 2007 at 2:06

[GoogleCodeExporter]

What's the use case for that kind of copying? When writing application code, I'd
rather explicitly specify the class of the copy. To maintain the iteration 
ordering
of the original, you can use a class like a LinkedHashMap.

Original comment by jared.l....@gmail.com on 1 Nov 2007 at 5:14

[GoogleCodeExporter]

I'm thinking in particular of utility methods that return a copy of their input 
- this includes methods like 
intersection(), transform(), and filter() for various collections types.

Original comment by limpbizkit on 1 Nov 2007 at 4:51

[GoogleCodeExporter]

Quite simply, "a wish for a clone() that worked."

I agree that this would be good to support, for the same reasons that the 
(failed)
idea of clone() was created in the first place.

This would enable things like Sets.union() to do what people expect (I think).

btw, the other thing I'm aware of that you can't do generically to a collection 
is
get an unmodifiable view of it!

  public static <C extends Collection<?>> C unmodifiableView(C collection) { ... }

This seems closely related, in that to make it work, we'd have to have tedious
itemized support for all the JDK collections plus have some interface or 
something
that other collections would be required to implement if they want to 
participate.

Big Yuck for us, but possibly useful to users?

Original comment by kevin...@gmail.com on 2 Nov 2007 at 2:15

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

clone() on collections, like on the jdk collections, would be useful.

I just got the following exception from eclipselink-2.0 M7, this is the 
reference
implementation of JPA-2.0.

Target Invocation Exception: java.lang.CloneNotSupportedException:
com.google.common.collect.Lists$TwoPlusArrayList
        at
org.eclipse.persistence.internal.jpa.transaction.EntityTransactionImpl.commitInt
ernal(EntityTransactionImpl.java:102)
        at
org.eclipse.persistence.internal.jpa.transaction.EntityTransactionImpl.commit(En
tityTransactionImpl.java:63)
        at org.metawb.astro.db.PersonTest.linkPersonTag(PersonTest.java:191)

FYI, This came from Lists.asList
        em.getTransaction().begin();
        for(int i = 0; i < 3; i++) {
            ps.get(i).setTagtypeCollection(Lists.asList(
                    tts.get(0), tts.get(i+1), new Tagtype[0]));
        }
        em.getTransaction().commit();

but this works ok

            ps.get(i).setTagtypeCollection(Lists.newArrayList(
                    tts.get(0), tts.get(i+1)));

Original comment by e...@raelity.com on 15 Sep 2009 at 6:17

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 17 Sep 2009 at 6:02

• Added labels: Milestone-Post1.0

[GoogleCodeExporter]

Original comment by kevinb@google.com on 30 Jul 2010 at 3:53

• Removed labels: Milestone-Post1.0

[GoogleCodeExporter]

Original comment by kevinb@google.com on 30 Jul 2010 at 3:56

• Removed labels: Priority-Medium

[GoogleCodeExporter]

This is out of the scope of the guava project.

Original comment by fry@google.com on 26 Jan 2011 at 8:51

• 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:16

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

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

• Added labels: Restrict-AddIssueComment-Commit