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 Wed, 10 Feb 2010 05:27:19 GMT
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.
>
>   


Mime
View raw message