You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Elardus Viljoen <el...@ucs.co.za> on 2000/11/27 15:52:54 UTC

RMIC dependency

Hi.

I have some class files that needs to be rmic'd - but only when changed
(been recompiled).  The javac task only compiles changed sources.  Is
there possibly a solution that produces similar results when using the
rmic task?

Thanks.
Elardus Viljoen
elv@ucs.co.za



Re: RMIC dependency

Posted by Stefan Bodewig <bo...@apache.org>.
Nicholas Christopher <nw...@flashcom.net> wrote:

> Stefan Bodewig wrote:
>> 
>> Nicholas Christopher <nw...@flashcom.net> wrote:
>> 
>> > What I found was that javac/jikes was touching the .class files
>> > every time.  For example:
>> >
>> > $ ls *.java
>> > Foo.java
>> > $ javac *.java
>> > $ # wait 10 minuites - do nothing to Foo.java
>> > $ javac *.java
>> >
>> > Foo.class will have the newer timestamp.
>> 
>> Sure, javac has compiled it again, so what would you expect? While
>> Ant's <javac> task will only recompile files that have changed,
>> command line javac does not perform a similar check AFAIK.
>> 
>> Stefan
> 
> The way I'm used to seeing things done is to first javac everything
> that might need it and then to rmic things.

And if you do so in Ant, Ant is supposed to only compile (<javac>) the
files that have changed (which works if your environment has been set
up correctly) and <rmic> will only compile those classes that have
changed. The latter case should work in Ant 1.2 unless you say
stubversion=1.2, the CVS version is supposed to work for this as well.

> If javac restamps everything it's not clear how rmic can know when
> things are unchanged.

When using Ant's <javac>, the source files that have not changed will
not be passed to javac/jikes at all.

Stefan

Re: RMIC dependency

Posted by Nicholas Christopher <nw...@flashcom.net>.
Stefan Bodewig wrote:
> 
> Nicholas Christopher <nw...@flashcom.net> wrote:
> 
> > What I found was that javac/jikes was touching the .class files
> > every time.  For example:
> >
> > $ ls *.java
> > Foo.java
> > $ javac *.java
> > $ # wait 10 minuites - do nothing to Foo.java
> > $ javac *.java
> >
> > Foo.class will have the newer timestamp.
> 
> Sure, javac has compiled it again, so what would you expect? While
> Ant's <javac> task will only recompile files that have changed,
> command line javac does not perform a similar check AFAIK.
> 
> Stefan

The way I'm used to seeing things done is to first javac everything that might
need it and then to rmic things. If javac restamps everything it's not clear how
rmic can know when things are unchanged.  I'd assumed that things had to be
handled properly upstream and to facilitate that javac/jikes would not rebuild
what didn't need it. Naive I guess.

Re: RMIC dependency

Posted by Stefan Bodewig <bo...@apache.org>.
Nicholas Christopher <nw...@flashcom.net> wrote:

> What I found was that javac/jikes was touching the .class files
> every time.  For example:
> 
> $ ls *.java
> Foo.java
> $ javac *.java
> $ # wait 10 minuites - do nothing to Foo.java
> $ javac *.java
> 
> Foo.class will have the newer timestamp.

Sure, javac has compiled it again, so what would you expect? While
Ant's <javac> task will only recompile files that have changed,
command line javac does not perform a similar check AFAIK.

Stefan

Re: RMIC dependency

Posted by Nicholas Christopher <nw...@flashcom.net>.
Stefan Bodewig wrote:
> 
> Nicholas Christopher <nw...@flashcom.net> wrote:
> 
> > I've had the same problem. What I found was that javac/jikes was
> > touching the .class files every time.  For example:
> 
> Should have reported here that Elardus had found a bug that was
> triggered when you set stubversion to 1.2. This version of rmic won't
> create _Skel files but Ant would still try to find them - and as they
> couldn't be found, Ant concluded it needed to recompile the class.
> 
> Has been fixed in CVS a few days ago.
> 
> Stefan

That didn't seem to help with me. Though stubversion="1.2" is far quicker than
stubversion="compat" but that is likely unrelated.

Re: RMIC dependency

Posted by Stefan Bodewig <bo...@apache.org>.
Nicholas Christopher <nw...@flashcom.net> wrote:

> I've had the same problem. What I found was that javac/jikes was
> touching the .class files every time.  For example:

Should have reported here that Elardus had found a bug that was
triggered when you set stubversion to 1.2. This version of rmic won't
create _Skel files but Ant would still try to find them - and as they
couldn't be found, Ant concluded it needed to recompile the class.

Has been fixed in CVS a few days ago.

Stefan

Re: RMIC dependency

Posted by Nicholas Christopher <nw...@flashcom.net>.
Stefan Bodewig wrote:
> 
> Elardus Viljoen <el...@ucs.co.za> wrote:
> 
> > Stefan Bodewig wrote:
> >
> >> > Maybe it'a a problem that I'm using ant 1.1 and not 1.2?
> >>
> >> Could be. There have been some changes to Rmic after the 1.1
> >> release, maybe one of them fixed the behavior you have seen.
> >
> > Unfortunately, not the solution...  Is the easiest way to write my
> > own task that does a timestamp comparison?
> 
> No! Sorry, didn't want to shout.
> 
> The best - though maybe not easiest - you can do, is to find out why
> it doesn't work (if you look at the code you'll see it *does* perform
> timestamp comparisons).
> 
> I've never used rmic myself, if you could provide me with a simple
> test environment (a couple of source/class files and a build file)
> that shows this behavior, I'd be happy to help you nail down and fix
> the bug.
> 
> But I'll need your help here as I don't really know how to set up an
> environment like this.
> 
> Stefan


I've had the same problem. What I found was that javac/jikes was touching the
.class files every time.  For example:

$ ls *.java
Foo.java
$ javac *.java
$ # wait 10 minuites - do nothing to Foo.java
$ javac *.java

Foo.class will have the newer timestamp.  This is on Linux and javac and jikes
both do it.  So since the .class is always touched rmic always builds.  That's
my bet.
#wait ten minutes

Re: RMIC dependency

Posted by Stefan Bodewig <bo...@apache.org>.
Elardus Viljoen <el...@ucs.co.za> wrote:

> Stefan Bodewig wrote:
> 
>> > Maybe it'a a problem that I'm using ant 1.1 and not 1.2?
>>
>> Could be. There have been some changes to Rmic after the 1.1
>> release, maybe one of them fixed the behavior you have seen.
> 
> Unfortunately, not the solution...  Is the easiest way to write my
> own task that does a timestamp comparison?

No! Sorry, didn't want to shout. 

The best - though maybe not easiest - you can do, is to find out why
it doesn't work (if you look at the code you'll see it *does* perform
timestamp comparisons).

I've never used rmic myself, if you could provide me with a simple
test environment (a couple of source/class files and a build file)
that shows this behavior, I'd be happy to help you nail down and fix
the bug.

But I'll need your help here as I don't really know how to set up an
environment like this.

Stefan

Re: RMIC dependency

Posted by Elardus Viljoen <el...@ucs.co.za>.
Stefan Bodewig wrote:

> > Maybe it'a a problem that I'm using ant 1.1 and not 1.2?
>
> Could be. There have been some changes to Rmic after the 1.1 release,
> maybe one of them fixed the behavior you have seen.

Unfortunately, not the solution...  Is the easiest way to write my own
task that does a timestamp comparison?

Regards.
Elardus



Re: RMIC dependency

Posted by Stefan Bodewig <bo...@apache.org>.
Elardus Viljoen <el...@ucs.co.za> wrote:

> Maybe it'a a problem that I'm using ant 1.1 and not 1.2?

Could be. There have been some changes to Rmic after the 1.1 release,
maybe one of them fixed the behavior you have seen.

Stefan

Re: RMIC dependency

Posted by Elardus Viljoen <el...@ucs.co.za>.
Stefan Bodewig wrote:

> > I have some class files that needs to be rmic'd - but only when
> > changed (been recompiled).  The javac task only compiles changed
> > sources.  Is there possibly a solution that produces similar results
> > when using the rmic task?
>
> <rmic> is supposed to do exactly this (only rmic files that are newer
> than the corresponding _Stub or _Skel files). It expects base to point
> to the compiled class files, not the sources. Are you using it that
> way?

Yes.  For each of my classes that is rmic'd:

  <rmic base="${classes.build}"
    stubversion="1.2"
    classname="foo.bar.baz"
  />

where ${classes.build} is where my compiled classes live.

It's a segment inside my compile task.  But while the sources doesn't get
recompiled (timestamp not changed), the stubs has a newer timestamp after
each successive compile task run.  Maybe it'a a problem that I'm using
ant 1.1 and not 1.2?

Regards.
Elardus


Re: RMIC dependency

Posted by Stefan Bodewig <bo...@apache.org>.
Elardus Viljoen <el...@ucs.co.za> wrote:

> Hi.
> 
> I have some class files that needs to be rmic'd - but only when
> changed (been recompiled).  The javac task only compiles changed
> sources.  Is there possibly a solution that produces similar results
> when using the rmic task?

<rmic> is supposed to do exactly this (only rmic files that are newer
than the corresponding _Stub or _Skel files). It expects base to point
to the compiled class files, not the sources. Are you using it that
way?

Stefan