Upgrade to Java 6 about guava HOT 33 CLOSED

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.

from guava.

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?

from guava.

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

from guava.

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.

from guava.

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

from guava.

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.

from guava.

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

(No comment entered for this change.)

Owner: ---

from guava.

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

(No comment entered for this change.)

Labels: Milestone-Post1.0

from guava.

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?

from guava.

Original comment posted by [email protected] 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.

from guava.

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.

from guava.

Original comment posted by [email protected] on 2010-07-16 at 05:47 PM

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

from guava.

Original comment posted by [email protected] on 2010-07-30 at 03:53 AM

(No comment entered for this change.)

Labels: -Milestone-Post1.0

from guava.

Original comment posted by [email protected] on 2010-07-30 at 03:56 AM

(No comment entered for this change.)

Labels: -Priority-Medium

from guava.

Original comment posted by [email protected] on 2011-01-27 at 02:14 PM

(No comment entered for this change.)

Labels: -Type-Enhancement, Type-Task

from guava.

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

from guava.

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.

from guava.

Original comment posted by [email protected] on 2011-07-13 at 06:18 PM

(No comment entered for this change.)

Status: Triaged

from guava.

Original comment posted by [email protected] on 2011-07-16 at 08:37 PM

(No comment entered for this change.)

Status: Accepted

from guava.

Original comment posted by [email protected] on 2011-07-19 at 12:17 AM

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

from guava.

Original comment posted by [email protected] on 2011-07-19 at 12:18 AM

(No comment entered for this change.)

Blocking: #664

from guava.

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.

from guava.

Original comment posted by [email protected] on 2011-12-10 at 03:13 PM

(No comment entered for this change.)

Labels: Milestone-Release12

from guava.

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

from guava.

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

(No comment entered for this change.)

Blocking: #51

from guava.

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?

from guava.

Original comment posted by [email protected] on 2012-03-02 at 06:51 PM

(No comment entered for this change.)

Labels: Package-General

from guava.

Original comment posted by [email protected] on 2012-03-05 at 07:23 PM

(No comment entered for this change.)

Status: Fixed

from guava.

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

Woooooooooooooooooooo!

from guava.

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

from guava.

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

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

from guava.

Original comment posted by [email protected] 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
"""

from guava.

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

(No comment entered for this change.)

Blocking: -#51

from guava.