Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <027501bfa91f$da8eb890$2302010a@vitaly>
From: "Vitaly Stulsky" <vitaly_stulsky@yahoo.com>
To: <ant-dev@jakarta.apache.org>
References: <20000417192322.59785.qmail@hotmail.com>
Subject: Re: How to participate?
Date: Tue, 18 Apr 2000 13:16:40 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="koi8-r"
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Robin Green" <greenrd@hotmail.com>
To: <ant-dev@jakarta.apache.org>
Sent: Monday, April 17, 2000 11:23 PM
Subject: Re: How to participate?


> "Vitaly Stulsky" <vitaly_stulsky@yahoo.com> wrote:
>
> >I found the similar library on:
> >http://www.alphaworks.ibm.com/tech/jikesbt
> >May be it will be interesting for you.
>
> Alphaworks software is normally time-limited or evaluation only AFAIK.
>
> > > However, I am not sure but I think there are one or two ways that this
> >could
> > > theoretically slip up. If you use an optimising compiler on this,
which
> >is
> > > basically acting like an IFDEF in C:
> > >
> > > if (Constants.DEBUG) { logger.println ("working okay"); }
> > >
> > > and Constants.DEBUG happens to be false, the optimising compiler may
(I
> > > think even javac does this normally) just not compile the whole line,
> >and
> > > may not even put a reference in to the Constants class in the .class
> >file
> > > header. Even worse, anything inside that block may not be referenced.
> >But
> > > this is just speculation.
> >
> >From my point of view we cannot rely on any speculation.
>
> I'm not asking you to _rely_ on any speculation. I'm simply saying, _if_
> now, or even in the future, any Java compiler strips out references to
other
> class files in a class file, then dependency checking will not work
> correctly if it is only based on analysing dependencies in class files.

May be I selected the poor term : "rely".  All I wanted to say : we need to
write tool which will be independent from the compiler implementation.

> One compliler can
> >do
> >things like that, other doesn't. I have one thought about this problem:
If
> >compiled .class
> >file (1) doesn't use modified and recompiled other .class file(2) - .java
> >file which
> >corresponds to the .class file (1) hasn't to be recompiled. I think this
> >assumption
> >guarantee project integrity.
>
> No it doesn't, if you have an optimising compiler. Re-read my explanations
> above and below.

I understood your explanation, but I'm completely sure that we cannot write
perfect dependence tracking even if we will perform source parsing.
Let me describe my point of view on a little example:
For example our application load and cofigure it look accroding to a config
file.

Assume a simple config file:
------------------
#config.properties
Data1 = NetworkTrafic
Control1 = Pipeline
Data2 = ProcessMemory
Control2 = SimpleChart
-------------
Somewhere in the code we can write:
-----------
void InstantiateControls (Properties prop)
{
....
Class.forName("com.ourcompany.controls."+prop.getProperty("Control1")+"Contr
ol");
....
}
-------
How can we determine that we're using PipelineControl?
May be it is bad practice, better to use Factories, but the language allows
such cases.

>
> >
> > > In any case, why should Ant place restrictions on what optimisations
the
> > > compiler can do? Well, you could say "that should be the job of a
> >separate
> > > optimiser/obfuscator", but perhaps there are some optimisations best
> >done
> >in
> > > the compiler. I'm not an expert in this area.
> >
> >I agree with you. It isn't job of make tool to put  additional
restrictions
> >on
> >the compiler.
> >
> > > If you parse the .java files you are GUARANTEED to pick up all the
> > > dependencies, no matter what the compiler does. And since there is
> >already
> >a
> > > public domain Java parser out there that comes with ANTLR, why not use
> >it?
> >
> >Yes, but parsing is too slow (1),
>
> I disagree. I think the process will be disc-bound as I said above, so the
> speed of the filesystem interaction will be the key factor, not the speed
of
> the parsing.
>
> and parsing can find non-actual
> >dependencies(2).
>
> Both true. But if you admit there are "non-actual" (you mean non-relevant)
> dependencies, then you must admit that there can be _relevant_
dependencies
> which are stripped out in the .class file!
>
> Example: A.java contains
>
> if (Constants.DEBUG) logger.println ("done it");
>
> Now if this line is optimised away by the compiler, and then only the file
> Constants.java is changed, you will not necessarily be able to tell from
> looking at A.class that A.java depends on Constants, because there might
be
> no reference to Constants at all in A.class.

I think all you've said is intersting and valuable information. It is very
importnat
to determine a border between code optimization/obfuscation and cost of
the project maintain. The nature of Java language doesn't allow us to
collect all information about dependencies. I've already started to
implement
this task using inforamtion stored in .CLASS files. When it'll be ready
I'll publish all code and we can investigate all advantages and
disadvantages of
this approach. If we'll find this approach working - excellent, if not - I
will
rewrite everything using parsing and we'll look at that approach.
Now we can think about this work like about scientific experiment.
What about opening ANT Labs??? :)

> >I'm ready to make any job and sacrifice my spare time for this work.
> Glad to hear it! Ant is a really cool tool - we need some hot
code-meisters
> to improve it even more!

Okey, now to the work.


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com