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

Thu Nov 10 18:59:19 GMT 2011

Hi Steve,

> Well; this is something we decided wasn't needed. The Java API was
> simplified (to make the classes' interfaces less cluttered).
>
> This particular method is entirely equivalent to a loop in the
> connecting client program, and the array of addresses is not used
> except in that one place.  We didn't think it was particularly useful,
> and it would mean two extra public factory methods.  We intend to
> remove uses of the array entirely (even from the private method).

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.

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.

> Thanks for spotting it; we are striving for simplicity.
>
> Clearly, as the interface changed you might need to make some small
> modifications; for which we apologise; but we hope this isn't a serious one.
> Was it really a breaking change for you?

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.

> Yes, I see that -- this was zeal again.  We see no real harm in exposing the
> STATIC FINAL constants, though, so that will be done in future.
> It might save some duplication in the client code.
> Again, you can code them explicitly, if you need them, which has the
> distinct advantage of you being able to dictate what defaults *you* want.

It's a minor thing and yes I can also just define my own constants,
but with client/server apps its so nice if you get the defaults from
the server's client api, i.e for in integration unit test.

> Sorry you couldn't continue with 2.7.0; please let us know if there are
> insurmountable problems.  I hope I haven't missed anything obvious.

Other then the api changes I usually have no problems with any updates
and they work flawlessly. :-)

- Irmo