commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel F. Savarese" <...@savarese.org>
Subject Re: [net] binary compatibility be damned
Date Tue, 19 Apr 2011 18:04:34 GMT

In message <BANLkTi=MrpcJqxHykLXfrkOnyHzEyewt8Q@mail.gmail.com>, sebb writes:
>We want to protect against jar hell.

OK, I see there are a bunch more emails in this thread.  I didn't mean to
reignite the jar hell debate.  At least I now understand where you're
coming from.  I thought maybe there was some other motivation.  The
following are just explanatory comments so you see where I'm coming from.
They are not intended to restart a debate.  I accept the outcome of the
discussion I opted not to participate in the last time it was discussed,
even though I disagree with the outcome if it it implies we must strive
for major releases to be binary compatible with previous major releases.

I don't view the issue as being our responsibility.  It's an application
development and packaging issue, not a library developer issue.  Maintaining
binary compatibility doesn't solve the jar hell issue and provides a false
sense of security.  I want my software to fail fast if it's going to fail
and be alerted immediately if a version of a run-time dependency falls outside
of my deployment configuration specification.  If a binary
compatible but behavior-changing API change is made from one major release
to another major release, perhaps to fix a bug, binary compatibility ensures
only that dependent software will run, not that it will run as expected.
Back when jakarta-oro was still relevant, a common problem was for users
to ask why such and such a feature didn't work properly and it would turn
out that WebSphere or some other application server used an older version
of the library for its own purpose that overrode the user's version via
class loader delegation.  Eventually, vendors got wise and either renamed
packages used internally or used class loaders more carefully.

As a library developer, it's not my job to protect users from lack of care
in the configuration management of application system components by application
developers.  It's the responsibility of application developers to adopt a
configuration management strategy that addresses the possibility of
multiple instances of different versions of the same library being present
in the system.  However, I can give the application developer the flexibility
to make a suitable choice.  When I write C++ libraries, I include version
information in the namespaces by default (client source doesn't reference
them directly, using namespace aliases instead) and provide a configuration
time --disable-namespace-versioning option.  By default, multiple instances
of different versions of the library can coexist in the same program, but
at the expense of not being able to drop in a new version of a shared library
without recompiling code.  Recompilation is generally not an unexpected
inconvenience because the use of templates and inline functions often forces
you to do it anyway.  Developers can choose to use --disable-namespace-versioning
if version conflict isn't a problem for them.  A different approach is required
for dynamic shared objects, but I don't view vanilla Java class libraries as
being analogous to dynamic shared objects.  From that point of view, there are
many more ways to deal with the issue in Java.  Six or seven years ago I covered
the pros and cons of several of them in a Java Pro column.

As I understand it, at Apache, we're in the business of releasing source code;
binary releases are a convenience.  With access to source code, application
developers have the maximum flexibility to deal with jar hell issues on
their own.  There are too many different situations to anticipate, such as
what version of byte code a developer requires (e.g., can't use JDK 1.4
byte code with JDK 1.3).  It's up to them to work it out, although we can
give them the tools to facilitate the implementation of a configuration
management strategy.  Even though it is a deficiency in the Java language,
API's, and JVM that it is not easier to deal with the issue, it remains
possible.

daniel


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message