[rabbitmq-discuss] Breaking API changes in JAva API 2.7.0

Fri Nov 11 11:23:43 GMT 2011

Hi Irmo,

> It was useful since you only need one ConnectionFactory and one call
> to connect to a cluster.
> Now I would have to change the internals (host/port) for every try to
> a node in a cluster (nasty imo, who likes these mutable objects anyway
> ;-) ), or I would need a ConnectionFactory per connection I can make
> but that seems a bit overkill too, since all of them would start
> Executors etc.
Well, no -- you would simply issue newConnection for each address in your
array -- an array you had to pass on the newConnection method before.
(The ExecutorService is not used if the connection is not made.)

I admit it's an extra loop, but no set*() calls are necessary.

> So I'd say I actually really liked the fact that I could create a
> single 'immutable' ConnectionFactory for my cluster and then just
> leave it and (re)use it.
Since the array was never stored in the Factory, you could never do that.
A newConnection() call simply used the 'default' host and port set on 
the factory. It still does.

In general it might be quite a good idea to put a set of cluster
addresses somewhere where clients could not have to worry
about them when getting a connection.  It might be nice to 
put that in the ConnectionFactory (enhancement request?)
but on the other hand, you would probably want to implement
a more sophisticated algorithm than "connect to the first one
that's up".   I guess you would know best what algorithm to use.
It's not likely we would consider putting that in the Factory object.

> It was breaking in the sense that the new client jar was not a direct
> drop-in replacement for the previous one.
> I would usually expect either an update where some api would get a
> @deprecated annotation and would be removed in a next version, or that
> there at least would be a notice of any breaking api changes in the
> release notes (no matter how small the change is).
> Especially if you maintain an api library it's really important to
> keep the api as stable as possible and otherwise be super clear in
> documentation about the changes and examples on how to migrate and
> have deprecated backwards compatible phases. Otherwise a new update of
> the library should (certainly since you have nice binary compatibility
> in java) always be a drop in replacement so user can benefit from
> improved implementation without any hassle.
You are dead right, of course, and we could have handled this better.
Normally I would expect binary compatibility
if it was only a micro release update, but this was a minor release update,
so one might have expected some differences. Still, thanks for your
admonition: we'll try to flag api changes better in future.

Incidentally, we are interested if you see any anomalies in the
Java Client info on the rabbitmq documentation pages. Since
there have been some subtle threading changes in this release
we appreciate feedback on these issues.

> Other then the api changes I usually have no problems with any updates

> and they work flawlessly. :-)
Thank you.

Steve Powell
steve at rabbitmq.com
[wrk: +44-2380-111-528] [mob: +44-7815-838-558]