Upgrade to Java 6

[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

• Blocking: #664

[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]

Would it be possible to create a Java-1.6-specific build target for those of us 
who
would like to build from source but don't want to install yet another JDK on our
machines in order to do so?

Original comment by bolinf...@gmail.com on 27 Apr 2010 at 3:54

[GoogleCodeExporter]

Actually, all you should have to do is give it your java 6 installation 
location as if it's the java 5.  Everything will 
work fine, you'll just lose the checking that any local edits you might have 
made won't break java 5 users.

Original comment by kevinb@google.com on 27 Apr 2010 at 2:09

[GoogleCodeExporter]

The POM needs to be updated to reflect the change.  Patch attached.

Original comment by jheric...@gmail.com on 16 Jul 2010 at 3:39

Attachments:

• patch.txt

[GoogleCodeExporter]

What change?  The change to requiring java 6 (described in this issue) is on 
hold indefinitely.

Original comment by kevinb@google.com on 16 Jul 2010 at 5:47

[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]

Original comment by kevinb@google.com on 27 Jan 2011 at 2:14

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

[GoogleCodeExporter]

Given that the change to java 6 has occurred (see issue 364), I'm unclear as to 
whether 1.5 will be supported or not. This issue indicates it will be, and 
issue 364 says it won't be. It seems this issue should be closed as won't fix, 
or issue 364 should be marked as a duplicate of this issue in order to make 
them consistent.

http://code.google.com/p/guava-libraries/issues/detail?id=364

More importantly, given that the code currently requires 1.6, the patch in 
comment #11 should be applied so that a Maven checkout and compile of the trunk 
is successful. A later branch (which only requires 1.5) could use the unpatched 
Maven configuration files that are currently in the trunk. But, without the 
patch, the Maven configuration is broken. See also issue 607 regarding the 
Maven configuration files.

http://code.google.com/p/guava-libraries/issues/detail?id=607

Original comment by sahendri...@gmail.com on 17 Apr 2011 at 5:45

[GoogleCodeExporter]

Issue 364 just says that Guava requires 1.6 to compile. It doesn't say anything 
about requiring 1.6 to run... it's still targeted at 1.5.

Original comment by cgdec...@gmail.com on 17 Apr 2011 at 3:01

[GoogleCodeExporter]

Original comment by kevinb@google.com on 13 Jul 2011 at 6:18

• Changed state: Triaged

[GoogleCodeExporter]

Original comment by kevinb@google.com on 16 Jul 2011 at 8:37

• Changed state: Accepted

[GoogleCodeExporter]

If we did this, would we have any volunteers to maintain the backport branch?

Original comment by kevinb@google.com on 19 Jul 2011 at 12:17

[GoogleCodeExporter]

Original comment by kevinb@google.com on 19 Jul 2011 at 12:18

[GoogleCodeExporter]

I have some projects that are woefully stuck on Java 5, so I selfishly would 
like that to remain the target. OTOH it sounds like Guava could be improved by 
moving to 6, so I'd be willing to be that guy.

Original comment by raymond....@gmail.com on 19 Jul 2011 at 11:14

[GoogleCodeExporter]

Original comment by fry@google.com on 10 Dec 2011 at 3:13

• Added labels: Milestone-Release12

[GoogleCodeExporter]

I am willing to take on the Sorted->Navigable part of the migration, that being 
"my thing."

Original comment by wasserman.louis on 21 Dec 2011 at 1:30

[GoogleCodeExporter]

Original comment by wasserman.louis on 31 Dec 2011 at 5:17

[GoogleCodeExporter]

Any idea how we'll deal with GWT compatibility in the future?

Original comment by wasserman.louis on 5 Jan 2012 at 6:37

[GoogleCodeExporter]

Original comment by kevinb@google.com on 2 Mar 2012 at 6:51

• Added labels: Package-General

[GoogleCodeExporter]

Original comment by fry@google.com on 5 Mar 2012 at 7:23

• Changed title: Upgrade to Java 6
• Changed state: Fixed

[GoogleCodeExporter]

Woooooooooooooooooooo!

Original comment by wasserman.louis on 5 Mar 2012 at 7:26

[GoogleCodeExporter]

Indeed, it would be great to have Navigable* in GWT too

Original comment by a.korzhe...@gmail.com on 5 Mar 2012 at 9:01

[GoogleCodeExporter]

That may be a GWT issue, not a Guava issue...?

Original comment by wasserman.louis on 5 Mar 2012 at 9:27

[GoogleCodeExporter]

RE: comment 30, here's a dump of a related internal bug ("Consider making 
NavigableSet methods available in GWT ImmutableSortedSet"):

"""
The GWT ImmutableSortedSet need not implement NavigableSet, but it could have 
some of the methods.

- It might be nice if it did implement NavigableSet.  We'd have to provide a 
GWT emulation of NavigableSet (which is easy, since it's an interface).  (In 
principle, this might be nice if we ever want to use other NavigableSet-based 
methods in GWT.)  We'd have to provide implementations of all the appropriate 
methods, but we already have some, and the others are doable... but 
descendingIterator() and descendingSet() are nontrivial.  And those two in 
particular, but all methods in general, would add to GWT code size, which we 
have to be careful of.

- It might be nice if it didn't implement NavigableSet but provided all the 
methods.  This saves us the trouble of a GWT NavigableSet emulation, but I'm 
not sure that's really worth anything.

- It might be nice if it didn't implement NavigableSet and implemented only 
some of the methods.  But this could be confusing to users:  Which ones are 
available?  This is what @GwtIncompatible is for, of course, but things are 
also hard for us: Because ImmutableSortedSet has a manual GWT emulation, we 
have to manually keep the @GwtIncompatible-annotated Java methods in sync with 
the missing GWT methods.  (We have to do this no matter what, but it is 
arguably most complicated when the set of methods to include isn't clearly 
defined.)

Or we could stop manually emulating the GWT classes altogether.

...

Very important thing that I forget: We can't easily *test* the new methods 
(i.e., test them with our collection-suite builders) unless they legitimately 
implement NavigableSet.  That alone makes me favor that approach -- if we do 
this at all, which it's not clear that we should.

...

Louis would also like to use this for SortedMultiset so that we don't propagate 
the SortedSet/NavigableSet distinction into the Multiset hierarchy: 
http://code.google.com/p/guava-libraries/issues/detail?id=942
"""

Original comment by cpov...@google.com on 28 Mar 2012 at 7:41

[GoogleCodeExporter]

Original comment by wasserman.louis on 17 Apr 2012 at 10:33

[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
• Now blocking: #664

[GoogleCodeExporter]

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

• Added labels: Restrict-AddIssueComment-Commit