Niclas Hedhman wrote:
On Thu, Oct 1, 2009 at 9:20 AM, Peter Firmstone <[email protected]> wrote:
-Major Release, new Features, Packages & API, API Changes that Break Source
(compile time) compatibility but not binary (runtime) compatibility.
What are you going to call a release that breaks binary compatibility?
Less than desirable. A fork perhaps? Just kidding...
But it's not out of the question, it really depends upon the trade off,
ie; what we gain. It isn't something that is prohibited, just to be
carefully considered.
A Major Release doesn't need to break source code compatibility to be a
major release, however if such an occurrence eventuates, it's not
unreasonable to expect application developers to make some changes
before compiling and distribution. If it is possible not to break
binary compatibility while gaining a great new feature, then shouldn't
we keep that option available? This enables users of the platform to
upgrade while allowing existing application implementations to prevail.
The significance comes from River being a Platform much like Java is a
platform.
For instance the following Changes Break Source code compatibility but
not binary compatibility:
Adding new methods to existing Interfaces, you could simply extend the
old interface by creating a new interface, however being able to provide
the same service interface to both old and new bytecode is
advantageous. (Especially when old objects might gain new life from new
bytecode... bear with me...)
In a Class designed for inheritance, for instance, one might need to
increase the visibility of one of its methods, ie public from
protected. A subclass in an Application that overrides this method with
protected access and has other classes within itself that utilise the
overridden behaviour would no longer compile due to this change, however
binary compatibility hasn't been broken.
Changes to the throws clause of a method or constructor doesn't change
binary compatibility.
Additional overloading of existing methods or constructors in classes or
interfaces doesn't break binary compatibility.
The use case would be that we realise that in order to have the
excellent new feature X, that we must break compile time compatibility.
But since binary compatibility is more flexible than compile time, we
might be able to salvage binary compatibility and avoid inconveniencing
users who don't have the ability to rewrite and recompile their
application code. The lock-in characteristic of old software platform
binary applications is the biggest obstacle in platform migration.
Tools to mitigate it somewhat when possible are a blessing.
I must confess that I deliberately threw the comment about binary
compatibility into the mix since it is of relevance to the codebase
analysis service that I'm working on. Binary Compatibility flexibility
allows a more natural evolution of class files, based on identification
of forward binary compatible API, this is particularly relevant to long
lived objects. Clients can receive new compatible class files for their
old objects when they restart their jvm. River in its current form is
not suitable for the semantic web, due to current code base limitations
and ClassLoader issues. I want to make it so. Overly ambitious
perhaps, however I've always relished a good challenge, without this
aspect of my personality, I'd probably have little motivation to be
active on this list. Such motivations have drawbacks too though.
Cheers,
Peter.
Personally, I think this requirement is too ambitious. If source
compatibility is broken, you might as well allow for binary
compatibility to break as well. I doubt the constraint is valuable
enough, and instead try to keep both source and binary compatibility
as long as possible and aggregate changes into any major releases very
seldomly.
Cheers
