Guava and JDK 6, 7, 8.....

[Kevin Bourrillion]

Hello esteemed Guava users,

With JDK 7 released it's high time we re-opened the discussion about moving Guava onto JDK 6.

Of course we all know there must exist some release of Guava that will be the final release to support JDK 5. Now that JDK 7 is out, I am proposing that that release should be either release 10 (this month) or 11 (fall).

Once released, we will honor requests to backport specific bug fixes, and we'll make patch releases.  But, we've never had patch releases before, so there are some kinks to work out.  Most of the world uses "semantic versioning" or something like it, and we have been saying that to any system which expects semantic versioning it should interpret "Guava release N" as meaning "Guava version 1.N.0".  So, the current newest release would be 1.09.0 and this month's release 1.10.0.

But this situation is weird, and we may want to consider officially switching over to using those numbers to avoid future confusion. Problem is it would definitely cause plenty of present confusion since 1.10.0 sounds a whole lot less than "9".  But on the bright side, this may more clearly make room for the potential patch releases I was just mentioning, which can be 1.10.01, 1.10.02, etc., while we've never had a "Guava release 09... point 1" before.

Question:  how many of you are stuck on JDK 5 and expect to be so for a while?  If you're concerned about being capped at version 1.10.x of Guava indefinitely due to your JDK 5 dependence, let's talk: perhaps we can get enough volunteer interest in maintaining a (near-)full backport project.  If we are going to go down that road, though, there are some things we'll need to figure out.  How would backport releases be suitably differentiated from regular Guava releases?  Does it call for a different project name?  Or could it just continue to use patch release numbers under 1.10 -- or what?

~~~

Next there is the issue of JDK 7!  The big problem with JDK 7 is not that Guava developers are itching to use String switch.  The issues I'm aware of are:

- If you're using Guava on JDK 7, you'll be very sad that we can't put @SafeVarargs on any of our methods

- I am not sure, but it is possible we have some libraries that should implement AutoCloseable and if we can't do that it will likewise make you sad

- Numerous methods should really be marked deprecated for JDK 7 users, but not for users of JDK 6.  Examples: Objects.equal, Ints.compare, Longs.hashCode, and all the no-arg creation-helper methods like Maps.newHashMap().

- Most of all, JDK 7's dramatically overhauled filesystem API calls for a near-complete, incompatible rethinking of our common.io package!  We can do this in a new package called common.nio, but we can't even put that into a Guava that still supports JDK 6.  Should it thus become Guava's second "splinter project" (the first of which will be guava-testlib)?

How might we deal with this?  (Possible solution a bit later.)

~~~

And while we're here, we might as well talk a bit about JDK 8.  I believe that the addition of lambdas and virtual extension methods, plus the planned addition of many new interfaces (e.g. Predicate) and many new methods on existing interfaces (e.g. Iterable.filter?) will require a major change to how we look at Guava's place in the world.  It will basically render the Guava that we know today at least 50% obsolete!  It will require a new, smaller, greatly changed and re-focused Guava which could not possibly be directly compatible with the old.  I don't know whether it would make more sense to choose a new project name for that new codebase, or simply bump up to "Guava 2.0.0" and live with the fact that this means violating my oft-repeated promises about backward compatibility in perpetuity.

And if we're willing to plan on that "Guava 2.0.0" notion, then we might perhaps as well use Guava 2.0.0 for the JDK 7-based version and Guava 3.0.0 for JDK 8, no?

~~~

That should be enough to get conversation flowing.  Thanks in advance for helping us sort through these issues!

--
Kevin Bourrillion @ Google

Java Core Libraries Team
http://guava-libraries.googlecode.com

[Blair Zajac]

On Aug 2, 2011, at 1:31 PM, Kevin Bourrillion wrote:

> Hello esteemed Guava users,
>
> With JDK 7 released it's high time we re-opened the discussion about moving Guava onto JDK 6.
>
> Of course we all know there must exist some release of Guava that will be the final release to support JDK 5. Now that JDK 7 is out, I am proposing that that release should be either release 10 (this month) or 11 (fall).
>
> Once released, we will honor requests to backport specific bug fixes, and we'll make patch releases. But, we've never had patch releases before, so there are some kinks to work out. Most of the world uses "semantic versioning" or something like it, and we have been saying that to any system which expects semantic versioning it should interpret "Guava release N" as meaning "Guava version 1.N.0". So, the current newest release would be 1.09.0 and this month's release 1.10.0.

Given that symbols are deprecated and removed in potentially each Guava release, wouldn't the N go to N.x.y. Unless no symbols are removed, then you could bump the minor version (middle digit).

Blair

[Robert Konigsberg]

On Tue, Aug 2, 2011 at 4:31 PM, Kevin Bourrillion <kev...@google.com> wrote:

... and we have been saying that to any system which expects semantic versioning it should interpret "Guava release N" as meaning "Guava version 1.N.0".  So, the current newest release would be 1.09.0 and this month's release 1.10.0.

We've had this discussion privately, but that will certainly disrupt the guava-osgi versioning. Not awesome, but minor surgery could handle it, leaving a small scar. (e.g. give the bundle a new name, looking less elegant.)
--
Robert Konigsberg
konig...@gmail.com

[Kevin Bourrillion]

I guess I got my wires crossed.  So, release 11 is to be considered 11.0.0 then.  Okay.

This leaves me wondering how to deal with the hypothetical "massively incompatible" future change (i.e. when JDK 8 arrives), as opposed to all our major version bumps so far which only make incompatible changes to @Beta code.  I wonder if we'd do best to just pick a new name. <sigh>

[Christian Edward Gruber]

+1 to.

Guava 1.x => Java <6

Guava 2.x => Java 7

Guava 3.x => Java 8

It's orderly, and well understood in the software community what these will mean.

Christian.

[Robert Konigsberg]

1.x => Java <= 6?

Or did you mean (n.x => Java (4+n))?

--
guava-...@googlegroups.com
Project site: http://guava-libraries.googlecode.com
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: http://code.google.com/p/guava-libraries/issues/entry
To get help: http://stackoverflow.com/questions/ask (use the tag "guava")

--
Robert Konigsberg
konig...@gmail.com

[Christian Edward Gruber]

Smart ass.  I wasn't being mathematical.  But funny.

And yeah, Kevin - it would have to be Guava 11.x, 12.x I think.  That'll take care of the "1.12 is less awesome than 11" problem. 

Christian.

[Robert Konigsberg]

<publicapology/>

--
Robert Konigsberg
konig...@gmail.com

[Raymond Rishty]

Kevin, thanks for the communication. 

For several of my projects, it looks like we're stuck on JDK 5 for the foreseeable future. On the other hand, I have a couple on 6 and one for which 7 looks hopeful, so I am definitely sympathetic to both sides. I'd be happy to manage the Java 5 backport effort. I'm probably in the minority of users that relies heavily on Guava on Java 5, and I value it enough to keep it progressing for us luddites. 

As far as project name under which to release the backport--I don't know the politics and policies around non-Google developers as authors on code with Google's name on it. I think it would be nice and convenient if it were all in one place, but that's probably not my call.

On Tue, Aug 2, 2011 at 4:31 PM, Kevin Bourrillion <kev...@google.com> wrote:

[Luke Lu]

> it would have to be Guava 11.x, 12.x I think. That'll take care of the "1.12 is less awesome than 11" problem.

+1. i.e.:

<= 10.x for Java 5
11.x Java 6
12.x Java 7
13.x Java 8
...

[Kevin Bourrillion]

It was pointed out to me that our existing releases really have to be interpreted as N.0.0 as it is, not 1.N.0 like I mistakenly said.  So, there's no reasonable way to encode the fact of the JDK release dependency into the major version number; one would just have to consult a table to see that 1-10(11) were JDK 5, 11(12)-16(?) were JDK 6, etc.

That is, even if 11.x is Java 6 like you say, we can't reserve 12.x for the eventual JDK 7 version because we'll need it for the very next release after 11.  (Because every version makes backward-incompatible changes to the @Beta APIs.)

[Benjamin Manes]

Does it need to be in the version number directly? In Maven one might add a classifier to specify the JDK version, which allows keeping that detail outside of the dependency's version id.

[Daniel Yokomizo]

Using this kind of versioning scheme, if you decide later to maintain
both the JDK 6 and JDK 7 projects active, you may end up using Guava
13 for JDK 6, Guava 14 and 15 for JDK 7, Guava 16 for JDK 6, etc., as
the release cycles may eventually be different.

IME it's better to make the target jdk part of the artifact name, e.g.
guava-jdk5 r11, so every branch may "reuse" the release numbers and we
keep the current versioning system. It also keeps the versioning
scheme used by guava-osgi. As each target jdk is a different beast I
think it's reasonable to make them incompatible in the artifact name,
but synchronized in the release number (e.g. r12 has the same bug
fixes for both guava-jdk5 and guava-jdk6 but different classes in some
cases, due to jdk specific changes).

In a previous company I had to maintain two releases of internal
libraries for jdk 1.4 and jdk 5, for a couple of years. I branched the
jdk 5 development tree from the 1.4 tree and the policy was to fix
bugs in the 1.4 tree and then merge the commit into the jdk 5 branch,
but release new functionality only in the jdk 5 branch, but backport
it on request. It was on a much smaller scale than Guava, but it seems
to be a workable solution.

Best regards,
Daniel Yokomizo.

[Kevin Bourrillion]

On Tue, Aug 2, 2011 at 3:42 PM, Daniel Yokomizo <daniel....@gmail.com> wrote:

Using this kind of versioning scheme, if you decide later to maintain
both the JDK 6 and JDK 7 projects active, you may end up using Guava
13 for JDK 6, Guava 14 and 15 for JDK 7, Guava 16 for JDK 6, etc., as
the release cycles may eventually be different.

No, once we cross the line for JDK 7 in e.g. Guava 14, that next Guava-on-JDK6 release would have to be 13.1, and there will be no easily observable correspondence.

A different artifact name sounds much simpler and better, but does it cause problems by making it less obvious that guava-jdk5 and guava-jdk6 are two independent things that should never appear on the same classpath at the same time?  I don't know.

[Ray Conner]

This is really more of an FYI for everyone out there. The first
release of JDK 7 has some bugs which you might see.
http://www.lucidimagination.com/blog/2011/07/28/dont-use-java-7-for-anything/

Whether this impacts Guava, I couldn't say. I would assume that Oracle
is working hard to fix these problems, so I expect this will become a
non-issue soon enough.

- Ray A. Conner

On Aug 2, 4:31 pm, Kevin Bourrillion <kev...@google.com> wrote:
> Hello esteemed Guava users,
>
> With JDK 7 released it's high time we re-opened the discussion about moving

> Guava onto JDK *6.*

[snip]

[David Schlosnagle]

On Tue, Aug 2, 2011 at 7:00 PM, Kevin Bourrillion <kev...@google.com> wrote:
> A different artifact name sounds much simpler and better, but does it cause
> problems by making it less obvious that guava-jdk5 and guava-jdk6 are two
> independent things that should never appear on the same classpath at the
> same time?  I don't know.

I like the idea of putting the minimum JDK as part of the artifact ID,
and there are a few other libraries that use this precedence.
BouncyCastle uses the minimum JDK as part of the artifact ID, for
example bcprov-jdk15 for JDK 5+ and bcprov-jdk16 for JDK 6+ [1] [2]
[3]. Another example is ojdbc6.jar is Oracle's JDBC driver for JDK 6,
while ojdbc5.jar for JDK 5 [4].

Assuming that release 10 is the first to support multiple JDK
releases, here are a few sample Maven dependency configs:

Release 10 for JDK 5:
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava-jdk5</artifactId>
<version>r10</version>
</dependency>

Release 10 for JDK 6:
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava-jdk6</artifactId>
<version>r10</version>
</dependency>

Release 10 for JDK 7:
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava-jdk7</artifactId>
<version>r10</version>
</dependency>

[1]: http://www.bouncycastle.org/latest_releases.html
[2]: http://repo2.maven.org/maven2/org/bouncycastle/bcprov-jdk15/1.46/bcprov-jdk15-1.46.pom
[3]: http://repo2.maven.org/maven2/org/bouncycastle/bcprov-jdk16/1.46/bcprov-jdk16-1.46.pom
[4]: http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-112010-090769.html

- Dave

[Daniel Yokomizo]

On Tue, Aug 2, 2011 at 8:00 PM, Kevin Bourrillion <kev...@google.com> wrote:
> On Tue, Aug 2, 2011 at 3:42 PM, Daniel Yokomizo <daniel....@gmail.com>
> wrote:
>>
>> Using this kind of versioning scheme, if you decide later to maintain
>> both the JDK 6 and JDK 7 projects active, you may end up using Guava
>> 13 for JDK 6, Guava 14 and 15 for JDK 7, Guava 16 for JDK 6, etc., as

>> the release cycles may eventually be different...

>
> No, once we cross the line for JDK 7 in e.g. Guava 14, that next
> Guava-on-JDK6 release would have to be 13.1, and there will be no easily
> observable correspondence.

This will break the scheme used by guava-osgi (if the point releases
include @Beta changes or deprecated removals). If the only releases
are for bugfixes and compatible backward changes then it would be ok
to keep only the point release numbering.

> A different artifact name sounds much simpler and better, but does it cause
> problems by making it less obvious that guava-jdk5 and guava-jdk6 are two
> independent things that should never appear on the same classpath at the
> same time?  I don't know.

I don't see how this is different from having guava-r09 and guava-r10
in the classpath. Without tooling to handle dependencies (e.g. maven,
osgi) you usually have to be careful and pray for things to work out
anyway. With osgi's semantic versioning we can use the qualifier in
the export/import package declarations (e.g. Import-Package:
com.google.common.base; version=“9.0.0.jdk5”). With maven/ivy I think
we need to add some additional tooling to avoid this problem which
makes me less satisfied with this solution.

[Robert Konigsberg]

On Tue, Aug 2, 2011 at 9:42 PM, Daniel Yokomizo <daniel....@gmail.com> wrote:

On Tue, Aug 2, 2011 at 8:00 PM, Kevin Bourrillion <kev...@google.com> wrote:
> On Tue, Aug 2, 2011 at 3:42 PM, Daniel Yokomizo <daniel....@gmail.com>
> wrote:
>>
>> Using this kind of versioning scheme, if you decide later to maintain
>> both the JDK 6 and JDK 7 projects active, you may end up using Guava
>> 13 for JDK 6, Guava 14 and 15 for JDK 7, Guava 16 for JDK 6, etc., as
>> the release cycles may eventually be different...
>
> No, once we cross the line for JDK 7 in e.g. Guava 14, that next
> Guava-on-JDK6 release would have to be 13.1, and there will be no easily
> observable correspondence.

This will break the scheme used by guava-osgi (if the point releases
include @Beta changes or deprecated removals). If the only releases
are for bugfixes and compatible backward changes then it would be ok
to keep only the point release numbering.

I think guava-osgi is going to have to adjust, unfortunately, by publishing different bundle names. Even, possibly, a different bundle name per JDK version, like org.junit.junit4 (or whatever it's named.)

--
Robert Konigsberg
konig...@gmail.com

[Daniel Yokomizo]

For osgi we need to support both import bundle and import package. Changing the bundle name just fixes the first.

> --
> Robert Konigsberg
> konig...@gmail.com

[Robert Konigsberg]

Why?

[Daniel Yokomizo]

On Aug 2, 2011 11:12 PM, "Robert Konigsberg" <konig...@gmail.com> wrote:
>
> Why?

In osgi we can have import-package (preferred) and import-bundle (discouraged) as a way to describe the dependencies of a bundle. Using import-package allows to a finer model of dependency management, but it would require guava-osgi to use the version  string to disambiguate because the package names in both bundles (e.g. guava-jdk5 and guava-jdk6) are the same.

Peter Kriens and  Neil Bartlett explain why import-package is preferred:
http://www.theserverside.com/feature/OSGi-Because-Sharing-Shouldnt-Be-Painful
http://njbartlett.name/2010/03/07/osgi-and-how-it-got-that-way.html

With only import bundle support  we prevent future, finer grained, guava osgi bundles (orthogonal to code versioning) which is not terribly important but not irrelevant either.

[Robert Konigsberg]

The first document doesn't say anything about the comparison between the two, and the second one is TL;DR, though I have immense respect for Neil Bartlett. This doesn't mean I disagree, but I'm not yet convinced.

--
Robert Konigsberg
konig...@gmail.com

[Nathan Bryant]

Hi,

My two cents: Right now at the office, I'm 100% JDK6 based, no JDK5 dependency whatsoever.

For what it's worth, I'm almost certainly planning on giving JDK7 a miss and "waiting for 8." If we don't just move to Kotlin, that is. There's not a lot that's compelling in JDK7 other than ForkJoin.

--
guava-...@googlegroups.com
Project site: http://guava-libraries.googlecode.com
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: http://code.google.com/p/guava-libraries/issues/entry

To get help: http://stackoverflow.com/questions/ask (use the tag "guava")

[Mikaël]

Hello,

I don't think it is necessary to rename bundles in guava-osgi. As long
as the main guava project decides to stick with the following
versionning scheme

rX for Java 5 where X = 10 or X = 11 (math operator ;))
rY for Java 6 where Y > X
rZ for Java 7 where Z > Y and so on...

Once the minimum JDK version requirement is upgraded for a given
version, upper version of Guava can not require a lower JDK version.
So, every backport or hotfix for lower JDKs must be integrated into
the last version requiring it, and consequently creates a A dot B
version. It may lead to the following imaginary release history
(assuming r11 is the JDK6 version):

r10 requires JDK5
r11 requires JDK6
r12 requires JDK6
r10.1 requires JDK5 and integrating hotfix
r13 requires JDK7
r12.1 requires JDK6 backporting r13 features
r10.2 requires JDK5 backporting r13 features
[...]

It seems clear enough to me, but it will require a dedicated wikipage
with a nice table to inform users ;)

I don't see good reason into renaming bundles in guava-osgi as long as
osgi bundles must declare their compatible execution environment (i.e.
JDK version). If I take back my imaginary release history, the bundle
named com.google.guava in version 10.0.0 requires the execution
environment "J2SE-1.5" while the same bundle in version 11.0.0
requires "JavaSE-1.6". If someone requires version 11.0.0 with a lower
execution environment than "JavaSE-1.6", OSGi runtimes will failed to
resolve it and most of the OSGi dev tools will tell you at development
time... Great! That's what we want to!

And there is no problem with people using import-package. OSGi will
not resolve a package if its containing bundle has non-satisfied
execution environment requirements.

AFAIK, Maven is not as accurate regarding the depencies of
artifacts... but i'm sure Maven experts know some tweaks to be as
elegant as OSGi ;)

Regards,
Mikael

On Aug 3, 5:24 am, Robert Konigsberg <konigsb...@gmail.com> wrote:
> The first document doesn't say anything about the comparison between the
> two, and the second one is TL;DR, though I have immense respect for Neil
> Bartlett. This doesn't mean I disagree, but I'm not yet convinced.
>
> On Tue, Aug 2, 2011 at 11:14 PM, Daniel Yokomizo

> <daniel.yokom...@gmail.com>wrote:

>
>
>
>
>
>
>
>
>
>
>
> > On Aug 2, 2011 11:12 PM, "Robert Konigsberg" <konigsb...@gmail.com> wrote:
>
> > > Why?
>
> > In osgi we can have import-package (preferred) and import-bundle
> > (discouraged) as a way to describe the dependencies of a bundle. Using
> > import-package allows to a finer model of dependency management, but it
> > would require guava-osgi to use the version  string to disambiguate because
> > the package names in both bundles (e.g. guava-jdk5 and guava-jdk6) are the
> > same.
>
> > Peter Kriens and  Neil Bartlett explain why import-package is preferred:
>

> >http://www.theserverside.com/feature/OSGi-Because-Sharing-Shouldnt-Be...

> >http://njbartlett.name/2010/03/07/osgi-and-how-it-got-that-way.html
>
> > With only import bundle support  we prevent future, finer grained, guava
> > osgi bundles (orthogonal to code versioning) which is not terribly important
> > but not irrelevant either.
>

> > > On Aug 2, 2011 10:09 PM, "Daniel Yokomizo" <daniel.yokom...@gmail.com>
> > wrote:
> > > > On Aug 2, 2011 10:52 PM, "Robert Konigsberg" <konigsb...@gmail.com>

> > wrote:
>
> > > >> On Tue, Aug 2, 2011 at 9:42 PM, Daniel Yokomizo <

> > daniel.yokom...@gmail.com>

> > > > wrote:
>
> > > >>> On Tue, Aug 2, 2011 at 8:00 PM, Kevin Bourrillion <kev...@google.com
>
> > > > wrote:
> > > >>> > On Tue, Aug 2, 2011 at 3:42 PM, Daniel Yokomizo <

> > > > daniel.yokom...@gmail.com>

> > > >> konigsb...@gmail.com
>
> --
> Robert Konigsberg
> konigsb...@gmail.com

[Charles Fry]

Yes, thanks for the BouncyCastle example. I like that very much, and fully second the proposal to use guava-jdk5 and guava-jdk6.

Charles

--

[Gary Pampara]

I'd have to agree with that. It's the "classifier" idea that maven has
as well and makes some things rather simple (for a select number of
cases).

[Christian Edward Gruber]

I agree. You could use classifiers - Test NG did that for a time. But frankly, I think simply using a upper-order version number for large-scale compatibility (tied to the jdk) second-order version number for rolling-forward in each line, and patch versions for compatible changes that are fixes. That's fine.

Unless the team feels that some of the changes within a major version will be incompatible (notwithstanding extreme and necessary fixes), in which case, it's worth thinking of a different way.

Christian.

[Kevin Bourrillion]

On Wed, Aug 3, 2011 at 7:14 AM, Christian Edward Gruber <cgr...@google.com> wrote:

I agree.  You could use classifiers - Test NG did that for a time.  But frankly, I think simply using a upper-order version number for large-scale compatibility (tied to the jdk) second-order version number for rolling-forward in each line, and patch versions for compatible changes that are fixes.  That's fine.

Unless the team feels that some of the changes within a major version will be incompatible (notwithstanding extreme and necessary fixes), in which case, it's worth thinking of a different way.

Nearly every one of releases 2 through 10 have had some incompatible changes to the @Beta-marked apis.

[Kevin Bourrillion]

On Wed, Aug 3, 2011 at 1:16 AM, Mikaël <mikael....@gmail.com> wrote:

Hello,

I don't think it is necessary to rename bundles in guava-osgi. As long
as the main guava project decides to stick with the following
versionning scheme

rX for Java 5 where X = 10 or X = 11 (math operator ;))
rY for Java 6 where Y > X
rZ for Java 7 where Z > Y and so on...

Once the minimum JDK version requirement is upgraded for a given
version, upper version of Guava can not require a lower JDK version.
So, every backport or hotfix for lower JDKs must be integrated into
the last version requiring it, and consequently creates a A dot B
version. It may lead to the following imaginary release history
(assuming r11 is the JDK6 version):

r10 requires JDK5
r11 requires JDK6
r12 requires JDK6
r10.1 requires JDK5 and integrating hotfix
r13 requires JDK7
r12.1 requires JDK6 backporting r13 features
r10.2 requires JDK5 backporting r13 features
[...]

It seems clear enough to me, but it will require a dedicated wikipage
with a nice table to inform users ;)

This is a clear enough depiction of what I might call "Option B" at this point, while I believe I lean toward the cleaner guava-jdk6, guava-jdk7 approach.

Incidentally, for non-@Beta code I believe we can stick with the strict backward-compatibility guarantees for guava-jdk6 and guava-jdk7; it's guava-jdk8 that that seems potentially hopeless for.  But that's a long way off.

[Christian Edward Gruber]

If we're going with classifiers, then it's

guava-r11-jdk5

guava-r11-jdk6

It'll force people to declare the classifier in their poms so there's no ambiguity. Unfortunately there's no way (that I know of) to make classifiers mutually exclusive - but that's a problem we'd have with any of these.

On a separate note... we need to start considering how to manage the source itself - i.e. forking the source repo. To maintain these in source is going to be fun. I have to re-think how we're going to build multiple kinds of source if we use classifiers. Hmm.

Sorry - should clarify - these are some of the implications on build:

* If we bake in the jdk version into the artifact, then they are different "projects"
(locus of build) with independent source trees.
- Can be built independently
- Can be deployed independently to maven central
- Benefit: Easiest on all counts
- Benefit: As the projects vary more, they may be quite different, so this may be a good signal
- Downside: No signals that each version is incompatible via any dependency aware build system.

* If we bake the jdk into the classifier, then they are the same "project"
(locus of build) and share a source tree.
- Could be built separately (with some work)
- Not sure how to deploy them separately.
- Benefit: Guava 12 is Guava 12, it just comes in flavours
- Benefit: The classifier tag sort of highlights the flavor part - could help with configuration error
- Downside: This is the hardest to coordinate buidls and releases since "classifiers" are
intended for dependent artifacts, not alternate streams

* If they're different versions (12.x, 13,x, etc for each JDK track)
- Can be build separately (forked in different branches, presumably)
- Can, for sure, deploy them to central repo independently.
- Benefit: Easy
- Downside: Major version doesn't track to features anymore, which can be confusing

It's also a question whether we want to fork branches for these, and how to structure the projects may depend on which option.

I'm starting to lean (despite my initial instinct) towards three separate "projects" with the artifact carrying the jdk name. Because I think Guava-jdk5 is not the same project anymore as Guava-jdk6, and Guava-jdk8, as Kevin pointed out, may be half the size and substantially different in shape.

cheers,
Christian.

[Kevin Bourrillion]

On Tue, Aug 2, 2011 at 6:42 PM, Daniel Yokomizo <daniel....@gmail.com> wrote:

> No, once we cross the line for JDK 7 in e.g. Guava 14, that next
> Guava-on-JDK6 release would have to be 13.1, and there will be no easily
> observable correspondence.

This will break the scheme used by guava-osgi (if the point releases
include @Beta changes or deprecated removals). If the only releases
are for bugfixes and compatible backward changes then it would be ok
to keep only the point release numbering.

You're right; this (what I just called "Option B") is not so good in this regard.

 

> A different artifact name sounds much simpler and better, but does it cause
> problems by making it less obvious that guava-jdk5 and guava-jdk6 are two
> independent things that should never appear on the same classpath at the
> same time?  I don't know.

I don't see how this is different from having guava-r09 and guava-r10
in the classpath. Without tooling to handle dependencies (e.g. maven,
osgi) you usually have to be careful and pray for things to work out
anyway. With osgi's semantic versioning we can use the qualifier in
the export/import package declarations (e.g. Import-Package:
com.google.common.base; version=“9.0.0.jdk5”). With maven/ivy I think
we need to add some additional tooling to avoid this problem which
makes me less satisfied with this solution.

It's not different, I just figured that as things stand it's easy to reason "library A requires Guava 7+, library B requires Guava 8+, and I have Guava 10 on the classpath, therefore I know I'm okay." You know, simpler.  And everyone knows you would never want two versions of the same thing in the classpath at once, but I wasn't sure if there was some kind of machinery that naturally enforces that restriction that we would circumvent by switching to guava-jdk6 etc.

For example, we still hear from people who are having terrible problems because library A uses Google Collections 1.0 and library B uses Guava 06 and they're both in the same classpath and unfortunately in that order.  And I think, "how would 'the system' have known to prevent that?"

[Kevin Bourrillion]

We intend to migrate from svn to git sometime after this release, at which point I completely assume we would want to set up guava-jdk5 as a branch.  I know there are many details to be figured out.

[Christian Edward Gruber]

Ooooh!  Missed that.  Liking the git.

But that still leaves the advantages/disadvantages listed below to be considered.

Christian.

[Ray Conner]

My vote is for distinct artifacts (guava-jdk5, guava-jdk6, etc.),
which naturally leads to independent projects and forking the source.
Moving to git should help you with porting patches between branches.

I'm not terribly familiar with osgi, so I can't comment on the
problems there. Otherwise, the only downside I see is that build
systems won't be aware of the conflicts. But I think that's better
than your third alternative, where maven would just assume that 13 is
later than 12. Another problem with the third alternative is that
there are government regulations that some I/A types read literally.
One of those is that you must always use the "latest" version, or wade
through a bureaucratic morass to get an exception.

Despite the problems inherent in maintaining simultaneous branches, I
think you'll be better off this way. Trying to keep all JDK variants
in one source tree sounds like a nightmare to me, especially when you
get to a JDK which obsoletes large parts of guava. Better to bite that
bullet now than reorganize again later.

On a side note, many developers already have to deal with this sort of
thing all the time (GCL and guava both present), and it can be
painful. At one point, I had three different implementations of the
javax.xml.bind package and two implementations of org.w3c.dom (with
different interface definitions, that was fun). A build feature to
allow one project to declare that it supercedes another would be nice,
but I don't think maven has that.

- Ray A. Conner

On Aug 3, 10:31 am, Christian Edward Gruber <cgru...@google.com>
wrote:

> >>>http://repo2.maven.org/maven2/org/bouncycastle/bcprov-jdk15/1.46/bcpr...
> >>> [3]:
> >>>http://repo2.maven.org/maven2/org/bouncycastle/bcprov-jdk16/1.46/bcpr...
> >>> [4]:
> >>>http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-11...

>
> >>> - Dave
>
> >>> --
> >>> guava-...@googlegroups.com
> >>> Project site:http://guava-libraries.googlecode.com
> >>> This group:http://groups.google.com/group/guava-discuss
>
> >>> This list is for general discussion.
> >>> To report an issue:http://code.google.com/p/guava-libraries/issues/entry

> >>> To get help:http://stackoverflow.com/questions/ask(use the tag "guava")

>
> >> --
> >> guava-...@googlegroups.com
> >> Project site:http://guava-libraries.googlecode.com
> >> This group:http://groups.google.com/group/guava-discuss
>
> >> This list is for general discussion.
> >> To report an issue:http://code.google.com/p/guava-libraries/issues/entry

> >> To get help:http://stackoverflow.com/questions/ask(use the tag "guava")

[Seanizer]

I would strongly recommend against using classifiers. For one thing,
it would break standard tooling. All maven IDE plugins rely on
standardized classifiers for sources and javadocs:

Code Sources Javadocs Tests Test
Sources
-------------------------------------------------------------------------------
foo.jar foo-sources.jar foo-javadoc.jar foo-tests.jar foo-test-
sources.jar

Where the naming scheme is artifactId[-classifier].packaging

(I ignored versions to make things simpler)

Anyway, if the classifier would be used to identify the main artifact
the whole search would have to be changed:

Code Sources Javadocs Tests Test
Sources
---------------------------------------------------------------------------------------
foo-x.jar foo-x-sources.jar foo-x-javadoc.jar foo-x-tests.jar foo-x-
test-sources.jar

This would require changes to all maven IDE integrations (maven-
eclipse-plugin, m2e etc) and require additional configuration for all
maven plugins that generate such artifacts (maven-source-plugin, maven-
javadoc-plugin, maven-jar-plugin) etc.

I agree that the classifier idea makes sense in theory, but in the
real Maven ecosystem, this would destroy everything. I strongly
suggest using ArtifactIds instead to signal compatibility and versions
to identify features / bugfixes.

ArtifactId Versions [new Features]
----------------------------------------------------------------------------------
guava-jdk5 10.0.0 10.1.0 11.0.0 (perhaps latest
version here)
guava-jdk6 10.0.0 10.0.1 11.0.0 11.1.0
guava-jdk7 10.0.0 11.0.0 11.1.0

Sean

[Christian Edward Gruber]

Thanks Sean. This is closer to what I had intended. Especially once I decided it was best to just use the jdk version in the artifact

Christian.

[Kevin Bourrillion]

So we currently have just one artifactId which is "guava".  Questions:

1. Do we like the new name "guava-jdk6", "guava6", or what?

2. Should we continue to use the name "guava" as meaning "guava-jdk5"?  If we don't, and release 10 is the last "guava" we ever put out, I have the fear that even years from now people will still go looking for "guava" and will see 10.0.0 as being the newest we've got.  But if we do, we have another problem which is that users will see that guava has been recently updated and will use it even though they're on JDK 6 or 7.  If we keep "guava" around, should we also redundantly have "guava-jdk5" or not?  If we don't keep it around, should we go ahead with the guava-to-guava-jdk5 rename right now?

[Pat Farrell]

On Thu, Aug 25, 2011 at 12:01 PM, Kevin Bourrillion <kev...@google.com> wrote:

So we currently have just one artifactId which is "guava".  Questions:

1. Do we like the new name "guava-jdk6", "guava6", or what?

I much prefer the guava-jdk6, guava-jdk7, etc.

reserve guave6 for the version of guava that the alians from the planet 6 deliver to us

 

[Sam Berlin]

Thought:  keep 'guava' as a pointer to the absolute latest version on the latest JDK (as a dependency or somesuch).  Introduce guava-jdk5, guava-jdk6, etc.. as more specific types.

sam

[cowwoc]

    You can't do pointers in Maven. This approach would consume double the disk-space :)

Gili

[Sam Berlin]

I admittedly don't know Maven intricately, but can't it be managed by making the exact version a dependency of 'guava' (and changing the dependency as needed)?

sam

[Christian Edward Gruber]

You can.  <scope>import</scope>   is a special scope introduced in maven 2.0.9.  So we can make guava a <package>pom</package> type and depend on guava-jdk?? and then one can do

<dependency>

  <groupId>...</groupId>

  <artifactId>guava</artifactId>

  <version>??</version>

  <scope>import</scope>

</dependency>

What this woudl do in practice is replace itself with the dependencies in the guava pom itself.  So it's a pure-reference.

Christian.

[Christian Edward Gruber]

Yes - and as I mentioned in the other reply - the "import" scope makes it less crazy to use.

Christian.

[Christian Edward Gruber]

To answer your question, rather than the maven technical minutia, I like.

guava -> pointer to guava-${latest}

guava-jdk5

guava-jdk6

guava-jdk7

guava-jdk8

[Colin Decker]

1. Do we like the new name "guava-jdk6", "guava6", or what?

I was actually thinking of suggesting naming like "gauva6" because it plays on the similarity of "guava" and "java". It seems like it could be more confusing combined with version numbers though.

 

2. Should we continue to use the name "guava" as meaning "guava-jdk5"?  If we don't, and release 10 is the last "guava" we ever put out, I have the fear that even years from now people will still go looking for "guava" and will see 10.0.0 as being the newest we've got.  But if we do, we have another problem which is that users will see that guava has been recently updated and will use it even though they're on JDK 6 or 7.  If we keep "guava" around, should we also redundantly have "guava-jdk5" or not?  If we don't keep it around, should we go ahead with the guava-to-guava-jdk5 rename right now?

That is a tough one. People are still confused by google-collections changing to guava it seems. My feeling, though, is that if the artifact name is going to change it might as well change now.

Having the guava artifact point to the latest as suggested might be a good solution to the issue of the artifact people have been using stagnating, but I'd worry about people depending on it rather than a specific version. Someone using JDK6 might depend on the guava artifact safely for a while before the release of a JDK7 version causes the next version of the guava artifact to not work for them. That may not actually be an issue, though, as they can just change the artifact they're using.

I'm also unsure as to how version numbers would work for that "pointer" guava artifact, or for the JDK-version artifacts for that matter. If, say, r11 were the first to have a JDK6 version, would that be version 1 of the JDK6 version and version 11 of the JDK5 version or version 11 of both? What version number would the pointer artifact use?

Finally, Is the goal to have versions of Guava (not including JDK8) be backwards compatible with previous JDK versions such that an application using the JDK7 version can use a library that was built for the JDK5 version (provided it didn't use @Beta APIs and such of course)?

[Kevin Bourrillion]

On Thu, Aug 25, 2011 at 10:04 AM, Christian Edward Gruber <cgr...@google.com> wrote:

To answer your question, rather than the maven technical minutia, I like.

guava -> pointer to guava-${latest}

guava-jdk5

guava-jdk6

guava-jdk7

guava-jdk8

I have this feeling that if we do this, someone will look at "guava", try to use it, and grumble, "damn, it requires JDK 7" and move on.  It would seem best to have no such thing as "guava" at all, but that doesn't seem to be an option unless releases 3-9 can be retconned somehow, which doesn't seem like how it's supposed to work.

[Kevin Bourrillion]

On Thu, Aug 25, 2011 at 10:17 AM, Colin Decker <cgde...@gmail.com> wrote:

1. Do we like the new name "guava-jdk6", "guava6", or what?

I was actually thinking of suggesting naming like "gauva6" because it plays on the similarity of "guava" and "java". It seems like it could be more confusing combined with version numbers though.

Ahh, "guava6" can't really work.  "Are you using guava 11?"  "No, I'm using 6."  "Whoa, that's old."  "No, it's brand new!"

So I think:  guava-jdk6.  And I think we should have a guava-jdk5 as of release 10.

2. Should we continue to use the name "guava" as meaning "guava-jdk5"?  If we don't, and release 10 is the last "guava" we ever put out, I have the fear that even years from now people will still go looking for "guava" and will see 10.0.0 as being the newest we've got.  But if we do, we have another problem which is that users will see that guava has been recently updated and will use it even though they're on JDK 6 or 7.  If we keep "guava" around, should we also redundantly have "guava-jdk5" or not?  If we don't keep it around, should we go ahead with the guava-to-guava-jdk5 rename right now?

That is a tough one. People are still confused by google-collections changing to guava it seems.

Yep.  What can we do about that, do you think?

My feeling, though, is that if the artifact name is going to change it might as well change now.

Having the guava artifact point to the latest as suggested might be a good solution to the issue of the artifact people have been using stagnating, but I'd worry about people depending on it rather than a specific version. Someone using JDK6 might depend on the guava artifact safely for a while before the release of a JDK7 version causes the next version of the guava artifact to not work for them.

Yeah... another reason to want there to be no such thing as just "guava".

 

That may not actually be an issue, though, as they can just change the artifact they're using.

I'm also unsure as to how version numbers would work for that "pointer" guava artifact, or for the JDK-version artifacts for that matter. If, say, r11 were the first to have a JDK6 version, would that be version 1 of the JDK6 version and version 11 of the JDK5 version or version 11 of both? What version number would the pointer artifact use?

Yeah, let's forget the moving-target "pointer."

 

Finally, Is the goal to have versions of Guava (not including JDK8) be backwards compatible with previous JDK versions such that an application using the JDK7 version can use a library that was built for the JDK5 version (provided it didn't use @Beta APIs and such of course)?

Ahh, what a mess... I don't know, need to explore this question.

[Christian Edward Gruber]

We can do some kinds of retcon.  We can republish the older guava poms with relocation bits pointing to the new ones, and re-publish guava < r10 each into a new groupId:artifactId:version.  Maven will let legacy projects continue to use the old pom references and will "redriect" to pull the newer real ones, and will provide warnings of relocation/deprecation (you can leave a message as to why it's been relocated).

Happy to do that if it's what makes sense.

cheers,

Christian.

[Blair Zajac]

On Aug 25, 2011, at 9:01 AM, Kevin Bourrillion wrote:

> So we currently have just one artifactId which is "guava". Questions:
>
> 1. Do we like the new name "guava-jdk6", "guava6", or what?

I prefer guava-jdk6, it's clear it's meant for that version of the JDK. Guava6 looks like a guava version number.

Blair

[Christian Edward Gruber]

On Aug 25, 2011, at 1:28 PM, Kevin Bourrillion wrote:

2. Should we continue to use the name "guava" as meaning "guava-jdk5"?  If we don't, and release 10 is the last "guava" we ever put out, I have the fear that even years from now people will still go looking for "guava" and will see 10.0.0 as being the newest we've got.  But if we do, we have another problem which is that users will see that guava has been recently updated and will use it even though they're on JDK 6 or 7.  If we keep "guava" around, should we also redundantly have "guava-jdk5" or not?  If we don't keep it around, should we go ahead with the guava-to-guava-jdk5 rename right now?

That is a tough one. People are still confused by google-collections changing to guava it seems.

Yep.  What can we do about that, do you think?

We should do a relocation pom, per my other e-mail.

Christian.

[Luke Lu]

How about guava (the artifactId) is always for jdk5 and update the
description of the pom and more importantly the site to mention
versions for jdk6+.

People search maven repository for guava will see guava-jdk* entries as well.

[Christian Edward Gruber]

And we need to figure, in this process, what we want to do with version numbers. I do think we're killing ourselves by avoiding the standard M.N numbering. Even if we do three different artifacts, I think 10.1 and 11.3 are understandable version numbers. But whatever the end result is - we need to pick one. Did we have resolution on any of this?

Remember - we can map the old artifacts to the new ones with new ids, new version numbers - whatever, to maintain history. The question should primarily be - what's the right way to move forward?

Christian.

[Charles Fry]

Ahh, "guava6" can't really work.  "Are you using guava 11?"  "No, I'm using 6."  "Whoa, that's old."  "No, it's brand new!"

So I think:  guava-jdk6.  And I think we should have a guava-jdk5 as of release 10.

Yes, let's do that as part of this release. 

[Charles Fry]

And we need to figure, in this process, what we want to do with version numbers.  I do think we're killing ourselves by avoiding the standard M.N numbering.  Even if we do three different artifacts, I think 10.1 and 11.3 are understandable version numbers. But whatever the end result is - we need to pick one.  Did we have resolution on any of this?

Remember - we can map the old artifacts to the new ones with new ids, new version numbers - whatever, to maintain history. The question should primarily be - what's the right way to move forward?

I think now is a perfect time to move to M.N numbering. 

[ceha...@gmail.com]

I just so happened to search for what the deal will be for Java 8.  I think you are right, Java 8 will render much or Guava things like functional interfaces redundant.  I would hope that a Guava version is eventually released that complements the functional interfaces in JAva 8 rather than re-define them.  That specific part shouldn't be too difficult, at least, pretty much a find/replace AFAIK.

On Tuesday, August 2, 2011 1:31:55 PM UTC-7, Kevin Bourrillion wrote:

Hello esteemed Guava users,

With JDK 7 released it's high time we re-opened the discussion about moving Guava onto JDK 6.

Of course we all know there must exist some release of Guava that will be the final release to support JDK 5. Now that JDK 7 is out, I am proposing that that release should be either release 10 (this month) or 11 (fall).

Once released, we will honor requests to backport specific bug fixes, and we'll make patch releases.  But, we've never had patch releases before, so there are some kinks to work out.  Most of the world uses "semantic versioning" or something like it, and we have been saying that to any system which expects semantic versioning it should interpret "Guava release N" as meaning "Guava version 1.N.0".  So, the current newest release would be 1.09.0 and this month's release 1.10.0.

But this situation is weird, and we may want to consider officially switching over to using those numbers to avoid future confusion. Problem is it would definitely cause plenty of present confusion since 1.10.0 sounds a whole lot less than "9".  But on the bright side, this may more clearly make room for the potential patch releases I was just mentioning, which can be 1.10.01, 1.10.02, etc., while we've never had a "Guava release 09... point 1" before.

Question:  how many of you are stuck on JDK 5 and expect to be so for a while?  If you're concerned about being capped at version 1.10.x of Guava indefinitely due to your JDK 5 dependence, let's talk: perhaps we can get enough volunteer interest in maintaining a (near-)full backport project.  If we are going to go down that road, though, there are some things we'll need to figure out.  How would backport releases be suitably differentiated from regular Guava releases?  Does it call for a different project name?  Or could it just continue to use patch release numbers under 1.10 -- or what?

~~~

Next there is the issue of JDK 7!  The big problem with JDK 7 is not that Guava developers are itching to use String switch.  The issues I'm aware of are:

- If you're using Guava on JDK 7, you'll be very sad that we can't put @SafeVarargs on any of our methods

- I am not sure, but it is possible we have some libraries that should implement AutoCloseable and if we can't do that it will likewise make you sad

- Numerous methods should really be marked deprecated for JDK 7 users, but not for users of JDK 6.  Examples: Objects.equal, Ints.compare, Longs.hashCode, and all the no-arg creation-helper methods like Maps.newHashMap().

- Most of all, JDK 7's dramatically overhauled filesystem API calls for a near-complete, incompatible rethinking of our common.io package!  We can do this in a new package called common.nio, but we can't even put that into a Guava that still supports JDK 6.  Should it thus become Guava's second "splinter project" (the first of which will be guava-testlib)?

How might we deal with this?  (Possible solution a bit later.)

~~~

And while we're here, we might as well talk a bit about JDK 8.  I believe that the addition of lambdas and virtual extension methods, plus the planned addition of many new interfaces (e.g. Predicate) and many new methods on existing interfaces (e.g. Iterable.filter?) will require a major change to how we look at Guava's place in the world.  It will basically render the Guava that we know today at least 50% obsolete!  It will require a new, smaller, greatly changed and re-focused Guava which could not possibly be directly compatible with the old.  I don't know whether it would make more sense to choose a new project name for that new codebase, or simply bump up to "Guava 2.0.0" and live with the fact that this means violating my oft-repeated promises about backward compatibility in perpetuity.

And if we're willing to plan on that "Guava 2.0.0" notion, then we might perhaps as well use Guava 2.0.0 for the JDK 7-based version and Guava 3.0.0 for JDK 8, no?

~~~

That should be enough to get conversation flowing.  Thanks in advance for helping us sort through these issues!

[Joachim Durchholz]

Am 18.05.2014 22:46, schrieb ceha...@gmail.com:
>> Question: how many of you are stuck on JDK 5 and expect to be so for a
>> while?

Just for the data point: No JDK 5 required here. (I guess I'm lucky.)

>> How would backport releases be suitably differentiated
>> from regular Guava releases? Does it call for a different project name?

Not the project - I've alway been seeing Guava as a project that aims to
fix and complement those things that the JDK didn't do well.

From an application programmer's perspective, I'd expect different APIs
to live in differently-named jars.
So if there's an API change from JDK 6 to JDK 7, I'd expect them to have
different names - say, guava6.jar vs. guava7.jar.
I'd also expect the guava6 APIs to live on in the guava7 ones, though
with deprecation warnings.
I would not expect to be able to freely mix and match the deprecated
APIs with the stuff that was freshly created for JDK7.

Hope this wasn't too rambly.

Regards,
Jo