Upgrade to Java 6, maintaining Java 5 backport branch

[GoogleCodeExporter]

We will upgrade to requiring Java 6, but will create a Java 5-compatible
branch and will include both forms in our release.

Based on the changes listed in

http://java.sun.com/javase/6/docs/technotes/guides/collections/changes6.html

we'll have some work to do...

API - 
* Adopt NavigableFoo in place of SortedFoo throughout the API
* Add ForwardingNavigableFoo, ForwardingDeque
* Add factory methods for the new implementations to Lists/Sets/Maps

Impl -
* Add @Override to methods newly eligible for it
* Adopt the new AbstractMap.Simple(Immutable)Entry classes in place of our
custom code wherever possible

probably other stuff I'm not thinking of.

Original issue reported on code.google.com by kevin...@gmail.com on 1 Nov 2007 at 8:12

[GoogleCodeExporter]

"will include both forms in our release"

Just a clarification question: will you be tagging releases from both branches? 
This
would be immensely helpful for those of us that are wrapping this project as a 
Maven
artifact. Tags help reproduce key snapshots of a project, and with those we 
could
produce the necessary versions of our own wrapping Maven artifacts. Thanks.

Original comment by estebis...@gmail.com on 11 Apr 2008 at 4:44

[GoogleCodeExporter]

The 20080818 snapshot JAR seems to contain Java 6 class files -- they fail on 
my Java 5 machines with 
UnsupportedClassVersionError.  Are we on 6, or 5?

Original comment by cbif...@gmail.com on 20 Aug 2008 at 3:45

[GoogleCodeExporter]

The 20080818 release was supposed to be Java 5, but my environment was 
incorrect when
I built it. I'll update the release.

Original comment by jared.l....@gmail.com on 20 Aug 2008 at 4:47

[GoogleCodeExporter]

I replaced the 20080818 release, which was built with Java 6, with a 20080820 
release
that works with Java 5. The source code is the same.

Original comment by jared.l....@gmail.com on 21 Aug 2008 at 12:25

[GoogleCodeExporter]

Sadly, this will probably not happen for a long time, due to the increased 
importance
of having a gwt-compatible version of the library.  (GWT hardly even implements 
java
5 let alone any of java 6).

Original comment by kevin...@gmail.com on 6 Jan 2009 at 6:11

[GoogleCodeExporter]

I think that's fine. It was probably more important (in the near time-range at 
least), that the backport-branch exist if the Java6 switch occurred. I'm 
betting 
there are many organizations who can't simply switch to 6 and passivity is 
important.

Original comment by estebis...@gmail.com on 7 Jan 2009 at 2:20

[GoogleCodeExporter]

Original comment by jared.l....@gmail.com on 8 Apr 2009 at 1:07

[GoogleCodeExporter]

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

• Added labels: Milestone-Post1.0

[GoogleCodeExporter]

This issue has been moved to the Guava project (keeping the same id number). 
Simply replace 'google-collections' with 'guava-libraries' in your address 
bar and it should take you there.

Original comment by kevinb@google.com on 5 Jan 2010 at 11:09

• Changed state: Moved