Yes - I know AspectJ works on the bytecode and not as a pre-processor to the source code and I don't think any other AO languages do that either. Although I'm an advocate for AOP I think we would want to think seriously before introducing a dependency on a non-javac compiler to Harmony. However it would be good for logging, and it's worth noting that AspectJ 5 can also match based on annotations, which makes it possible to achieve quite fine-grained logging without cluttering up the source too much with "if ( logging.isDebugEnabled())" etc.
Thanks, Sian On 30/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Chris Gray wrote: > On Sunday 29 October 2006 14:04, Geir Magnusson Jr. wrote: >> [...] >> 3) Java ME - We've had some interest (Chris?) in looking at using the >> Harmony classlib for ME, which can also have some differences that might >> be most conveniently kept in place in the main codebase. > > Yes, I'm still here and still waiting for an answer to my last mail about > bringing Mika to the incubator ... I thought you were off trying to figure out IP provenance. > >> [...] >> First, anyone think this is a good idea and second, anyone have any >> experience with tools in this area? > > For JavaME I think it's the only way we'd be able to maintain a single source > tree. We need to be able to "#ifdef out" references to classes we don't have, > methods we don't implement, etc.. > > That much being said, I don't have a recommendation for a tool to use. Java > syntax is sufficiently C-like that cpp is probably do-able, but we'd probably > stumble over a whole series of gotcha's, and cpp isn't exactly [deity]'s gift > to preprocessing anyway. Maybe one of the aspect-oriented tools (with which I > am not at all familiar) could be a better bet? How? Doesn't that tend to work on the bytecode? I know that I'd be uncomfortable with anything where there wasn't a clear source tree produced. geir > > Cheers, > > Chris >
-- Sian January IBM Java Technology Centre, UK
