Re: [classlib] Preprocessor

[Tim Ellison <t....@gmail.com>]

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)

Re: [classlib] Preprocessor

[Tim Ellison <t....@gmail.com>]

Geir Magnusson Jr. wrote:
> Tim Ellison wrote:
>> 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.
> 
> Right, except I could imagine having an IDE plugin that deals with this
> for you - you edit and debug using the processed code, which is what the
> line numbers will correspond to...

:-) of course, when I say "you" I mean the tooling not the developer.

Regards,
Tim

-- 

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

Re: [classlib] Preprocessor

["Geir Magnusson Jr." <ge...@pobox.com>]

Tim Ellison wrote:
> 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.

Yes.

> 
> 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.

Right, except I could imagine having an IDE plugin that deals with this 
for you - you edit and debug using the processed code, which is what the 
line numbers will correspond to...

> 
> 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
>>
>