Patricia Shanahan wrote:
Sim IJskes - QCG wrote:
On 11-02-11 13:34, Benson Margulies wrote:
Holding a formal vote as a way of discovering (e.g. spelunking,
humorously) whether a consensus exists is fine. My point, such as it
was, is that once you have a supply of -1 votes, you're really done.
It doesn't matter exactly how much time has passed, or whether you put
RESULTS in a subject line, or any of those things. You've learned that
there is no consensus for the proposal.
I guess you misunderstood my concern to do it right, fair and equal
for me pushing through a point. I agree it was rather mechanical, but
hey, it served a purpose. I'm happy with the results. Indeed very
happy. I've strong feeling whe have really accomplished something.
And somehow i think it is impolite to ignore a vote once it is cast,
and that was probably the main driver for the tally of vetos. And
really i could not think of another way to determine the consensus.
Maybe I attached my question to the wrong article. It is clear that
there is considerable opposition to dropping Java 5 support at this
time. The real question is whether we had allowed long enough for
anyone who objected to dropping 1.4 to say so. I think we have.
Patricia
For Java 1.4 (aka CDC) (after I finish the internet work), I may
consider maintaining a previous release branch and back porting some bug
fixes or features, but this isn't relevant River's current development,
note that River's breaking compatibility with Java 1.4, so it won't be
compatible in a network environment, the breakage will occur on the Java
1.4 side, it won't affect you so please don't worry about it or look at
it like it's somehow in competition when I get around to it.
Note that I too develop using Java 5 language features, so I'm not
placing any constraints on where River's headed, I accept recent
developments, people have their goals and dropping 1.4 compatibility
seems the easiest way to achieve them.
I would encourage people to open their minds to the investigation of
modular development, Java 7 and 8 are around the corner and the same
thing will have to happen for Java 5 at some point. It doesn't matter
what build tools are used, I don't particularly care whether it's Maven,
Ant + Ivy or Gradle, what matters is that implementation is separated
from specification, so we can have multiple implementations for some
components to enable using new features without breaking compatibility
with earlier platforms / releases.
The huge benefit Jini has is, it removes static dependencies to
implementations, instead you have a static dependency on a service
interface and you find compatible implementations at runtime, using a
dynamic dependency.
A static dependency is one that exists at compile time, one that doesn't
change, that's how most software is currently developed, note that Maven
manages static dependencies. Don't blame the tool, it just fulfills a need.
A dynamic dependency is one that exists and can be changed at runtime.
Dynamic dependency's enable change and failure handling.
Static dependency's cannot change at runtime, if they do, they break.
Maven provides a means to obtain the correct static dependency to avoid
breakage.
We cannot eliminate static dependency's, but Jini gives us a way to
abstract them using dynamic dependency injection at runtime.
Our current build isn't exploiting the benefits Jini can provide by
abstracting static dependencies. Some might see using Maven (as a build
tool) as joining the dark side, but static dependency's still exist even
with dynamic dependency abstractions like Service API, they just now
depend on the Service API rather than the implementation.
All ClassDep does is discover the static dependency's by inspecting
bytecode, it's not rocket science, we needn't tie our build process to
it. Ironically, I now regret adding the ability to determine Generic
dependency's, all I've done is prolong the attachment to ClassDep as a
build tool, if I hadn't, people would have had to find another way to
manage static dependencies when they started adding Java 5 language
features to the build. I have shot myself in the foot on this occasion
LOL. ClassDep used to depend upon the jre implementation tools.jar, Tim
Blackman donated work he had done using ASM to determine dependencies,
this was part of his research into ClassLoader tree's. Tim was solving
the ClassLoader issues that Preferred ClassLoading was intended to
address, but didn't quite succeed in doing.
Note that Class.forName(String) is a dynamic dependency, ClassDep
doesn't attempt to find dynamic dependencies.
By breaking up the build into components, it allows other alternate
implementations to be developed to take advantage of new features.
These alternate implementations can be swapped out at runtime within
deployed environments. This allows people to develop a new component in
skunk, eg you might like to develop a fault tolerant replicating
transaction manager. ;) We can either chose to make this a forklift
upgrade for users or as simple as adding a new service.
New development will be much faster, you'd create a subproject build
that depends on the platform and some other libs, it utilises all the
existing transaction manager tests (by using a jar file library) and
you'd concentrate on this component. When it's complete, you don't have
to Merge it back into the main trunk, it's independent and doesn't need
to be Merged. Currently we're trying to develop things in skunk, which
we want to merge back into trunk and have this big glob of code, we're
not taking advantage of Jini's abstractions.
Users developing their own software don't need to check that their
changes break Jini platform tests, why is this the case for our in house
service implementations? This is what the Jini discovery and Join tests
(currently unmaintained) are for.
Who's going to take us seriously if even we don't take advantage of what
we have?
Lets do the best job we can. I know it takes time, but lets work towards
it, investigate what we have, understand it as best we can, then improve
it if we can, try and try again. If we cling to what we have based on
fear of the unknown or just using a tool or library because everyone
else is, then we'll stagnate.
Cheers,
Peter.
