Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of t.p.ellison@gmail.com
 designates 66.249.92.172 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=KQkloRVSL4wx3DAfDmwzLvGHd0pCOobSvpJcou2v0HfO3xux6G8hfrnIYHGYf/V2Ln+sqda5P8A3rWYbrqxiOR1AGIKuTwNyJrTC7I4H7K5i9k7zWt6JkYgPinA6z6oBAgbDqqGqfVxuh4PuWCnKsLPTRDM1iP5Vr6oo8gh4YrA=
Message-ID: <454628D3.2050005@gmail.com>
Date: Mon, 30 Oct 2006 16:31:15 +0000
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] Preprocessor
References: <3b3f27c60610282200w2445a56ena39736e4a6c4fed5@mail.gmail.com>
 <906dd82e0610290109h52808a4fo79eb800c7a7bbb1@mail.gmail.com>
 <4544A6F7.3070807@pobox.com> <200610300132.36876.chris.gray@kiffer.be>
 <4545498D.6040905@pobox.com> <45454B7F.2020601@sablevm.org>
In-Reply-To: <45454B7F.2020601@sablevm.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Etienne Gagnon wrote:
>> Chris Gray wrote:
>>> 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?
> 
> You could always do "clean" source-to-source processing using
> SableCC...:-)  Java is a nice language to parse, so you could do some
> clean parsing, instead of the dumb "unstructured text" replacement of
> preprocessors.
> 
> Actually, if all you need if "ifdef'ing out" undesirable references, it
> could be done by "hiding" modification directives in structured
> comments,  so that these comment remain "javac" invisible.  This way you
> could make it such that:
> 1- Plain source compilation -> j2se .
> 2- Structured processed source compilation -> j2me .

I agree, ensuring that the original source remains compilable can be a
great benefit.

Besides in-lining #ifdef's you can also maintain look-aside files with a
description of the smaller configurations.  That helps to avoid code
clutter though of course you may prefer to be marking-up the code
in-line if it is not simply removing whole types/methods.

The other thing to remember is that methods that appear in the smaller
configurations must only be implemented in terms of methods that appear
in the smaller configurations.  For example, you may have to rewrite
regular IO to not be implemented in terms of NIO so that it remains
viable in configurations that don't have NIO.  In Harmony we have a
common 'platform IO layer' used for both modules.

Where you do go through a source-to-source transform stage it helps of
you can collaborate with the second-stage compiler to pass through
original line number info (a la JSR45) otherwise debugging gets a bit
tiresome.

Regards,
Tim

> If you need it, there are 2 or 3 Java 1.5 grammars available for SableCC
> (different parsing approaches, not different syntax!).  As I said, Java
> is a pleasure to parse when compared to C & C++.
> 
> It's just an idea, of course...  [I know that people can start religious
> wars about pre-processing; that's why I am suggesting a clean approach,
> so that j2se people don't have to pre-process].
> 
> Etienne
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)