harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fedotov, Alexei A" <alexei.a.fedo...@intel.com>
Subject RE: [classlib] Preprocessor - CHECKPOINT
Date Wed, 01 Nov 2006 22:13:14 GMT
> I am really offering to develop this custom tool.  

+1
For me this is a key message. For sure that would be a nice tool. Does
it worth to dig use cases even more? Do we plan to develop j2me here at
Harmony?

Etienne,
I wonder if it worth to have SableCC itself exposed as a part of
Harmony. Say, you post a JSR for compiler generation API and add an
appropriate package to Harmony JRE.


With best regards,
Alexei Fedotov,
Intel Java & XML Engineering

>-----Original Message-----
>From: Etienne Gagnon [mailto:egagnon@sablevm.org]
>Sent: Wednesday, November 01, 2006 4:51 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [classlib] Preprocessor - CHECKPOINT
>
>Geir Magnusson Jr. wrote:
>> There's caching too, I think.  LogCache4J
>>
>> What I meant was that it didn't seem like we came to a conclusion on
it
>> - that if we had a general pre-processing solution, we could use that
>> too for logging, rather than have two.
>>
>> The actual use-cases will help figure this out.
>
>Here two typical some use cases, and some proposed solutions:
>
>Problem
>-------
>logging, and other situations where you really don't want to put the
>"additional" source code in the main source files
>
>Solution
>--------
>use aspects  (Plug: you might want to give a look at the optimizing abc
>compiler)
>
>
>Problem
>-------
>supporting a different API specifications/versions, such as j2me and
>j2se1.4, in addition to the "main" version (e.g. j2se1.5)
>
>
>Solution
>--------
>
>This is a trickier problem.  We can divide the problem at two main
levels:
>
>1- file/directory level
>2- source-code level
>
>At the file/directory level, each version (e.g. j2me, j2se1.4, ...)
>might include additional files (relative to the main version), and
might
>not include some files of the main version.  In other words, j2me might
>not contain database APIs.
>
>Managing file inclusion/exclusion can be done in various ways.
>
> a) ant based:  use distinct ant (sub-)files for each version.
>
>   The problem is that IDEs (e.g. Eclipse) will most likely show some
>   of the excluded files in its class/files browser.  This wouldn't be
>   very elegant.  It also implies "always" compiling through ant files.
>
>   Of course, one could develop Eclipse-specific configuration files to
>   mimic the inclusion/exclusion of ant files, but then, this opens the
>   door for discrepancies between ant vs eclipse inclusion/exclusion
>   lists.  I don't like it.
>
> b) custom-tool based: the custom processing tool I proposed could also
>   parse inclusion/exclusion lists, and use these lists to move files
>   around, in addition to processing the content of unmoved files.
>
>   For example, if class X of the main version is not part of j2me,
>   "process(j2me)" would move this file to a subdirectory ".streams/".
>
>   If a class Y is not in the "main" version (the one used for "svn
>   ci"), it resides in subdirectory ".streams" in the trunk.
>   "process(j2me)" moves this file into the normal directory.
>
>   As for IDEs, now you can configure them to automatically exclude
>   ".stream/" directories.
>
>   Inclusion/exclusion could be managed in two ways:
>   1- the processing tool could look for inclusion/exclusion list
files,
>      such as "j2me.inclusion, j2me.exclusion, main.inclusion,
>      main.exclusion, etc."
>
>      This would lead to the best performance (for process(X)), yet it
>      does require much manual update of inclusion/exclusion lists,
with
>      all the discrepancies that result from human mistakes while
>      updating these files.
>
>   2- (my preferred way), directives, at the beginning of the source
>      code would indicate whether a file is included in a version or
>      not.  Depending on target, the file would be moved to the
>      appropriate directory (normal, ".streams").
>
>
>    Of course, there's also the problem of non-source files, i.e.
>    resources.  IMO, resources could be managed using specific
>    directories (".main/", ".j2me", ".j2se1.4") and a ".shared/"
>    directory with symbolic links in the specific directories.
>
>
>As for source-level management, you would use my proposed processing
>tool to view the source files with the right spectacles [as Tim said so
>elegantly:-)].  For "development targets", it is important that:
>
> revert(process(X, target)) => X
>
>By "development target" I mean a target that is meant for Harmony
>developers in prevision of reverting "modified code" to a format
>suitable for "svn ci" (i.e. revert to "main" target).
>
>For comfortable IDE development, one could imagine that the IDE editor
>can reduce to "one-line visible" comments (or better, specially
>formatted ones) so that it gives you the impression that you are really
>wearing target-specific spectacles.  [I know Eclipse allows for such
>things already].
>
>To release code, one would apply:
>
> process(X, release-target) => Y
>
>Now, it is important to understand that Y, in this case, is NOT
suitable
>for doing any modification as
>
> revert(Y) => Kaboom!  (The tool will simply report that it can't do
it;
>                        it won't crash.)
>
>Yet, I think that it would be important that the processing tool leaves
>"markers" in Y, so that we could also have a tool to help finding the
>canonical source line of a reported bug:
>
> revertLine(Y, L') => L  (where L' is a line reported by end-developer,
>                          and L the related line in "svn").
>
>Markers would be short single lines comments, so the end-developer
>annoyance would be kept minimal.
>
>
>What do you think?
>
>
>I am really offering to develop this custom tool.  Just help me
identify
>various Harmony needs I might have missed!
>
>Of course, this tool is not the best solution to ALL problems, yet, so
>far, I think that it seems to best address the problem of supporting
>various API versions.
>
>
>Etienne
>
>--
>Etienne M. Gagnon, Ph.D.            http://www.info2.uqam.ca/~egagnon/
>SableVM:                                       http://www.sablevm.org/
>SableCC:                                       http://www.sablecc.org/

Mime
View raw message