harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib] Preprocessor - CHECKPOINT
Date Wed, 01 Nov 2006 16:06:38 GMT
Etienne Gagnon wrote:
> 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)

+1  and/or 'intrinsic' VM-level tracing of the Java code.

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

Why would you move the files rather than exclude them?

I was assuming that the processor would generate a whole new source tree
for each process() target, so that you could work on the original
checked-out file in it's 'canonicalized form' for Big Java work, or
process("jme") into a new location and work in the non-canonical form
your Little Java spectacles on.  That would prevent you accidentally
checking in the Little Java code, since you would need to
reverse-process the code back to replace the checked-out file (with a
test to ensure you are not overwriting changes made to Big Java, or for
extra credit, merging changes in the working copies).  The svn check-in
would then always be in the Big Java canonicalized form.

This idea would loose the ability to check-in directly from the IDE
though for people working with the non-canonicalized source form.

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

Agreed. Since we are requiring the source to be processed for any
deliverable target, we might as well keep the mark-up in-line.

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

Agreed.  It would be interesting to determine the most effective
location for those markers (measured by reverse mapping accuracy vs.
number of markers).

I can imagine a simple scheme by choosing the start of major Java
elements (class/method definitions), or a fancier scheme based on the
'distance' that lines in the two sources get out of sync'; e.g. if the
lines in the processed source are all within +/-5 lines of the original
then no markers are required, but if the processed source is > 5 lines
out then lay down a re-sync' point that ties them back together (e.g.
processed output line 30 is "/* Canonical Line 42 */") and watch for
further drifting from there.

> What do you think?
> I am really offering to develop this custom tool.  Just help me identify
> various Harmony needs I might have missed!

Wonderful!  Send in a basic tool and I'd be delighted to help shape it.

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

Agreed.  I'm interested to hear other people's ideas / requirements too.



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

View raw message