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: sketches
Date Thu, 11 Feb 2010 03:59:02 GMT
The converse is, that we just have a copy of the complete API for the 
Java CDC foundation profile, collected using static analysis and compare 
against it.   That copy might just be the serialised form of the 
dependency analysis results.

As per your suggestion, Static analysis is the way to go, might also 
need to copy a subset of the qa tests for testing the core river 
platform on Java CDC.



Peter Firmstone wrote:
> 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?
>> 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.
> Hi Chris,
> I've been considering the above, we have a tool called ClassDep, 
> (ClassDepend - the implementation) that uses the ASM bytecode library 
> to perform dependency analysis.  One of the options -edges picks up 
> dependencies between packages.  Now we currently don't have a way of 
> showing all the methods etc, however every static dependency link is 
> analyzed, I have thought about recording all the API signatures from 
> the dependencies.  We can perform an analysis using clrr to find the 
> unsupported methods in Java Foundation Profile, in comparison to Java 
> 1.6 (I thought about J2SE 1.4.2, but I think 6 is more appropriate).  
> The results of this analysis can be stored in the trunk on svn.
> Once we have a baseline on what classes or methods cannot be used, 
> we'll want to provide an ant build task that finds any illegal API 
> with ClassDepend, only the River core component that supports the Java 
> Foundation Profile, will be checked, we can still utilise generics and 
> some other Java 5 Language features in this core component.
> We can then make our ClassDepend tool available for checking Service 
> Interfaces and Smart Proxy compatibility with Foundation Profile.  
> This would only apply to the client side.
> People wishing to create a service for Foundation Profile would need 
> to use the Java ME SDK
> People that don't want to support Foundation Profile, need not concern 
> themselves.
> As I said this would only apply to the very core of Apache River, the 
> absolute minimum requirement to produce and consume a service, that 
> would of course include some parts of JERI.  We'll need ways of 
> managing compatibility information at runtime, by annotating the 
> bytecode version and package metadata into our MarshalledObjInstance.  
> So services aren't matched by platforms that cannot support them.
> More investigation is required, will keep you posted.
> Cheers,
> Peter.
>> 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.

View raw message