Upgrade to Java 6

[gissuebot]

Original issue created by kevinb9n on 2007-11-01 at 08:12 PM

---

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.

[gissuebot]

Original comment posted by estebistec on 2008-04-11 at 04:44 PM

---

"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.

[gissuebot]

Original comment posted by cbiffle on 2008-08-20 at 03:45 AM

---

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?

[gissuebot]

Original comment posted by jared.l.levy on 2008-08-20 at 04:47 PM

---

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

---

Owner: jared.l.levy

[gissuebot]

Original comment posted by jared.l.levy on 2008-08-21 at 12:25 AM

---

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.

[gissuebot]

Original comment posted by kevinb9n on 2009-01-06 at 06:11 PM

---

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).

[gissuebot]

Original comment posted by estebistec on 2009-01-07 at 02:20 AM

---

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.

[gissuebot]

Original comment posted by jared.l.levy on 2009-04-08 at 01:07 AM

---

(No comment entered for this change.)

---

Owner: ---

[gissuebot]

Original comment posted by kevinb9n on 2009-09-17 at 06:02 PM

---

(No comment entered for this change.)

---

Labels: Milestone-Post1.0

[gissuebot]

Original comment posted by bolinfest on 2010-04-27 at 03:54 AM

---

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?

[gissuebot]

Original comment posted by kevinb@google.com on 2010-04-27 at 02:09 PM

---

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.

[gissuebot]

Original comment posted by jherico72 on 2010-07-16 at 03:39 PM

---

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

[gissuebot]

Original comment posted by kevinb@google.com on 2010-07-16 at 05:47 PM

---

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

[gissuebot]

Original comment posted by kevinb@google.com on 2010-07-30 at 03:53 AM

---

(No comment entered for this change.)

---

Labels: -Milestone-Post1.0

[gissuebot]

Original comment posted by kevinb@google.com on 2010-07-30 at 03:56 AM

---

(No comment entered for this change.)

---

Labels: -Priority-Medium

[gissuebot]

Original comment posted by kevinb@google.com on 2011-01-27 at 02:14 PM

---

(No comment entered for this change.)

---

Labels: -Type-Enhancement, Type-Task

[gissuebot]

Original comment posted by sahendrickson on 2011-04-17 at 05:45 AM

---

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.

#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.

#607

[gissuebot]

Original comment posted by cgdecker on 2011-04-17 at 03:01 PM

---

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.

[gissuebot]

Original comment posted by kevinb@google.com on 2011-07-13 at 06:18 PM

---

(No comment entered for this change.)

---

Status: Triaged

[gissuebot]

Original comment posted by kevinb@google.com on 2011-07-16 at 08:37 PM

---

(No comment entered for this change.)

---

Status: Accepted

[gissuebot]

Original comment posted by kevinb@google.com on 2011-07-19 at 12:17 AM

---

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

[gissuebot]

Original comment posted by kevinb@google.com on 2011-07-19 at 12:18 AM

---

(No comment entered for this change.)

---

Blocking: #664

[gissuebot]

Original comment posted by raymond.rishty on 2011-07-19 at 11:14 AM

---

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.

[gissuebot]

Original comment posted by fry@google.com on 2011-12-10 at 03:13 PM

---

(No comment entered for this change.)

---

Labels: Milestone-Release12

[gissuebot]

Original comment posted by wasserman.louis on 2011-12-21 at 01:30 PM

---

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

[gissuebot]

Original comment posted by wasserman.louis on 2011-12-31 at 05:17 PM

---

(No comment entered for this change.)

---

Blocking: #51

[gissuebot]

Original comment posted by wasserman.louis on 2012-01-05 at 06:37 PM

---

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

[gissuebot]

Original comment posted by kevinb@google.com on 2012-03-02 at 06:51 PM

---

(No comment entered for this change.)

---

Labels: Package-General

[gissuebot]

Original comment posted by fry@google.com on 2012-03-05 at 07:23 PM

---

(No comment entered for this change.)

---

Status: Fixed

[gissuebot]

Original comment posted by wasserman.louis on 2012-03-05 at 07:26 PM

---

Woooooooooooooooooooo!

[gissuebot]

Original comment posted by a.korzhevskiy on 2012-03-05 at 09:01 PM

---

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

[gissuebot]

Original comment posted by wasserman.louis on 2012-03-05 at 09:27 PM

---

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

[gissuebot]

Original comment posted by cpovirk@google.com on 2012-03-28 at 07:41 PM

---

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: #942
"""

[gissuebot]

Original comment posted by wasserman.louis on 2012-04-17 at 10:33 PM

---

(No comment entered for this change.)

---

Blocking: -#51