Binary Compatibility Broken Between 2.0.0 and 2.1.0

[michaelcameron]

The commit changing the the String methods on the Jedis class broke binary compatibility for classes compiled against Jedis 2.0.0. Any clients compiled against 2.0.0 and using the String functions will break, and any clients compiled against 2.1.0 but using 2.0.0 at runtime will similarly break, even if they only send a single String.

This seems like it could be addressed however by adding back the old String functions alongside the variadic functions. It is legal to have both foo(String bar) and foo(String... bar) functions on the same class. If this were added and released as 2.1.1 it would restore binary compatibility with classes compiled against 2.0.0 but running with 2.1.0 at runtime (and of course, classes compiled against 2.1.0 would continue to function).

I think this is critical to fixing and releasing soon because it's going to create an all or nothing update issue with the Jedis ecosystem. A given project will need to make sure all of it's supporting libraries are all compiled against 2.0.0 or 2.1.0 and it will not be possible to mix them (I had one of these as the author of the Grails Jesque Plugin Issue 12 . I can create a pull request, but I would like to get feedback on the ability to quickly turn it around and release a 2.1.1 version.

[ivowiblo]

Could you provide a code sample of what gets broken?

[michaelcameron]

Yes, any class compiled against a one of the old methods that changed to variadic will fail with a message such as:
java.lang.NoSuchMethodError: redis.clients.jedis.Jedis.sadd(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/Long;

One simple example of a client compiled against 2.0.0 but running against 2.1.0 with error:

import redis.clients.jedis.Jedis;

public class TestClient {
    public static void main(String[] args) {
        Jedis jedis = new Jedis("localhost");
        jedis.sadd("foo", "bar");
        System.out.println(jedis.spop("foo"));
    }
}

If that commit simply added methods alongside the existing String methods (perfectly legal in Java), then binary compatibility would be preserved.

[ivowiblo]

Ok, you mean when replacing the jar directly and not re compiling the application.

[michaelcameron]

Correct. Any class compiled against 2.0.0, but then using 2.1.0 at runtime will likely fail. Since this is also the case of a 2.1.0 client using 2.0.0 at runtime, this sets up an all or nothing upgrade proposition for any Jedis client libraries. The issue opened in the Grails Jesque plugin was just this. A user was using the latest Grails Redis plugin (1.3.1) and needed functionality there, but it broke the Jesque plugin because it was compiled against 2.0.0 and additionally uses the core java Jesque plugin, also compiled against 2.0.0. In this case I can compile the Grails Jesque plugin against 2.1.0 as the maintainer, but can only submit a pull request to the java Jesque library. Even if I can coordinate that I'm now forcing all users of Grails Jesque to upgrade all of their libraries to ones compiled against 2.1.0. So the general case in a mixed project of libraries relying on Jedis is that the upgrade from 2.0.0 to 2.1.1 needs to be all or nothing, there can be no mixed upgrade.

If we add back the old non-variadic String methods alongside the variadic methods, then both 2.0.0 and 2.1.0 clients can use the new release (2.1.1?). I can help with a pull request if needed.

[dtanner]

FWIW - I just hit this issue in using the latest standalone-tomcat-redis plugin (0.1) and the redis plugin (1.4.2 as of writing). The tomcat redis plugin depends on jedis 2.1, while the redis plugin depends on 2.2.
As a temporary workaround, I dropped my redis plugin version down to 1.3.3, which uses jedis 2.1.

[xetorthio]

don't really know if this is an issue of Jedis.

On Mon, Nov 18, 2013 at 1:56 PM, Dan Tanner notifications@github.comwrote:

FWIW - I just hit this issue in using the latest standalone-tomcat-redis
plugin (0.1) and the redis plugin (1.4.2 as of writing). The tomcat redis
plugin depends on jedis 2.1, while the redis plugin depends on 2.2.

As a temporary workaround, I dropped my redis plugin version down to
1.3.3, which uses jedis 2.1.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/303#issuecomment-28726498
.