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: River Core Platform [was: Re: sketches]
Date Sun, 07 Feb 2010 23:51:10 GMT
That's good news Bob, heartwarming news actually.  I truly hope both of 
you are able to participate.

Thank you & Welcome to Apache River,

Peter.

Bob Craig wrote:
> Peter,
>  
> I just wanted to chime in privately to pass on two things.  1) I and Chris are both grateful
to see the leadership you are providing to River after a long period after Sun dropped active
involvement.  We are both heavily committed to Jini within our Corporate environment and appreciate
the fact that the "community" is coming alive with your leadership.
>  
> 2) Chris is a solid "open-source" citizen (he is active in several other open-source
projects) and sincerely wants to contribute back to River in whatever way he can (he has discussed
it with me personally).  The work we've done on the Jini codestream internally is something
that Chris wants to contribute back - I am working through the Corporate hoops that we need
to jump through here at Avid to get official sign-off to make that happen (and have our asses
covered).
>  
> Bob Craig
> Avid Technology
>  
>  
>
> ________________________________
>
> From: Peter Firmstone [mailto:jini@zeus.net.au]
> Sent: Sat 2/6/2010 5:19 PM
> To: river-dev@incubator.apache.org
> Subject: River Core Platform [was: Re: sketches]
>
>
>
> Christopher Dolan wrote:
>   
>> Honest question: considering that Sun end-of-lifed Java 1.5 back in
>> October 2009, what's the value in continuing to support the Java 1.4
>> platform in River?
>>  
>>     
> Honest Answer: Just a few billion blue ray players, set top boxes and
> multifunction network printers and any other device that run Java cdc.
>
> Let me make one thing very clear: No code will be rejected because it
> uses a later JAVA version.
>
> What we do need to define is what constitutes the core platform, so that
> when I want to run River on a cdc device, that provides or consumes a
> simple service, I can.  Which again highlights another problem,
> modularity, the Jini Specification is supposed to be able to have
> multiple implementations.
>
> I receive an endless stream of resistance about modularity, or
> versioning, every time I try to get the blessing of the River dev list
> to start working towards something, so here I sit doing the menial
> tasks, getting out the new release, posting discussions to river-dev,
> hesitant to make changes in case it turns out to be a wast of my
> valuable time.  I have children and have paid work to do also. This
> isn't directed at you Chris, I want to see you participate, I just
> happened to pick up your thread response, it's directed at the list in
> general.
>
> Modularity allows us to have multiple implementations, if we provide a
> Service that uses Java 5 language features and if it's proxy is a smart
> proxy then if that smart proxy also uses Java 5 or later then it isn't
> available to Java 1.4 J2SE or cdc.
>
> However if it is a simple reflective proxy with typical classes it's
> bytecode is generated dynamically at runtime.
>
> We need a way to annotate what Java Version a Service provides, well
> that's what you call modularity, it should be handled for you
> automatically by the River platform, it can be annotated in
> MarshalledObject.
>
>
>       Compatibility Checkers
>
> Some tools used by Apache projects:
>
>     * Java
>           o Clirr <http://clirr.sourceforge.net//> works on binaries
>           o JDiff <http://jdiff.sourceforge.net/> uses sources
>
>
> Once a core platform has been decided upon, then that is all we check
> for Java 1.4 compatibility and those that want the Java 1.4 platform
> support are obliged to maintain that compatibility, namely me, but it
> was me that pushed later Java language feature support in the first
> place and still support it, I want as large an adoption and user pool as
> possible.
>
> So if we put the effort into defining just what the minimum requirements
> are for producing or consuming a basic service, we have the core
> platform, this can then be a small download.
>
> Eg, the JERI Relay service that Sim is working on is not part of the
> core platform, why not take advantage of the Concurrency libraries? 
> Reggie Services shouldn't be restricted either, you wouldn't provide a
> Reggie service with java cdc, however it's proxy stub would need to be
> compiled with the -jsr1.4 option. (Actually Reggie still uses rmic, we
> need to convert to JERI)
>
> NO CODE WILL BE REJECTED BECAUSE IT USES LATER JAVA LANGUAGE FEATURES
>
> If you want to prove to yourself the -jsr14 compiler option works, edit
> build.xml, add the option, use JDK1.6 to compile the current codebase
> and specify source=5 instead of 1.4.
>
> I'm actually starting to wonder if we need two Releases of Apache River:
>
>    1. River for Trusted Intranet Networks
>    2. River for Untrusted Networks
>
> Both could use the same core platform, one would be secure by default
> and require more configuration, the other simple, with few concerns
> about security, or codebase evolution (Preffered Class loading
> mechanisms will suffice).
>
> BR Peter.
>   
>> I've found it to be tricky to avoid using new methods when striving for
>> backward runtime compatibility.  Extensive unit testing or static
>> analysis are the only ways to ensure you've found all the problems,
>> since the compiler won't help you.
>>
>> Googling for "-target jsr14" revealed this less-than-inspiring quote:
>>   "It is convenient, if unsupported, and the compiler generates mostly
>> compatible bytecode in a single pass."
>>   http://twit88.com/blog/2008/08/26/java-understanding-jsr14/
>>
>>
>> Chris
>>
>> -----Original Message-----
>> From: Peter Firmstone [mailto:jini@zeus.net.au]
>> Sent: Friday, February 05, 2010 5:16 PM
>> To: river-dev@incubator.apache.org
>> Subject: Re: sketches
>>
>> Yes, Java 5 language features next release.
>>
>> Although I'd like to find just what our core jini platform should be and
>>
>> compile it with -jsr14 to produce Java 1.4 bytecode from Java 5 source.
>>
>> In that core platform, we couldn't use any new methods or libraries not
>> in Java 1.4, however we could use generics.
>>
>> So for instance the Java cdc platform can consume and provide simple
>> services.
>>
>> Cheers,
>>
>> Peter.
>>
>>  
>>     
>
>
>
>
>   


Mime
View raw message