I understand where your coming from, it's a very valid point. But I
think we've diverged from the Release versioning thread, I'd be
interested in continuing this conversation in another thread, thinking
about difficult problems assists understanding. I don't think there's a
right or wrong approach here, just different solutions to hard problems,
with different compromises.
Windows is tied to its existing install base. In a distributed "The
Network is the computer" environment, it might be possible to mitigate
this somewhat by using codebase services and codebase evolution,
application authors would have the opportunity to release updated
bytecode and have it propagate to all clients and services, pending jvm
restarts, at least for downloaded code. Ideally as much code as
possible would be downloaded.
The goal would be not to tie River to any particular jvm implementation,
but rather a minimum java version requirement moving forward.
Tim Blackman found in his investigations with Class loader trees, that
different compilers produce different bytecode optimizations for the
same source code, hence the importance of identifying API signatures of
bytecode. API signature Metadata is also referred to as Class Mirrors,
in Reflective framework terminology.
I think that allowing classes to load where the API signatures have been
identified as compatible, even though bugs may exist is the correct
behavior, by utilising version Metadata for Packages in jar files, later
versions can be identified to ensure package evolution. Some package
evolutions may not be backward compatible, hence the importance of API
signatures.
Still it's a very difficult problem to solve, the first step is
understanding.
Much appreciated Cheers & Thanks,
Peter.
Niclas Hedhman wrote:
Yes, in principle I agree, but when you are a platform, there might be a
large number of dependent apps that break if deployed on a newer version.
Peter's example of MS Windows is an excellent example, and "simple
statements" like the one you give is no longer black or white.
Unfortunately, I think River falls into this "hard" category, where many
independent versions of both platform and app may exist at the same time in
all possible combinations.
-- Niclas
On Oct 3, 2009 4:40 PM, "Jukka Zitting" <[email protected]> wrote:
Hi,
Niclas Hedhman <[email protected]> kirjoitti 3.10.2009 kello 7.38:
And then you end up with the problem of defining "when is a bug fix,
incompatible change" :...
The definition of a bug is behaviour that differs from the documented or
otherwise expected behaviour.
>From that perspective any code that is broken by a bug fix is already
incorrect, and I wouldn't worry too much about such breakage.
BR,
Jukka Zitting
