river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: [TALLY] [VOTE] drop JDK 5 compatibility
Date Sat, 12 Feb 2011 00:57:53 GMT
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.

Mime
View raw message