Re: The curse of constant fields

On Mon, 15 Dec 2008 01:27:29 +0000, Tom Anderson wrote:

On Sun, 14 Dec 2008, Martin Gregorie wrote:

On Sun, 14 Dec 2008 10:03:49 -0800, Mike Schilling wrote:

Arne Vajhøj wrote:
Classpath for source code is not a well defined concept.

Perhaps not. But the vast majority of code is laid out as a tree
rooted somewhere, just like class files - wouldn't that be adequate?
Or do i misunderstand?

I don't think "the vast majority of" is good enough for a tool.

Is it a problem, though? Put the full paths of all referenced source
files in the dependency database. If anything's different on the next
run, you need to recompile.

I think there's an even easier way which could easily be built into
ant.

Instead of merely compiling every class which is older than the
corresponding source file, set a target timestamp to match the most
recent class file and then recompile all classes whose sources have
been amended more recently than the target. That will sometimes do more
than the minimum amount of work, but I don't think it will ever fail to
recompile everything that needs to be recompiled.

Put these three classes in their own files:

public class Foo {
public int m() {
return 1 ;
}
}

public class Bar
public int n() {
return new Foo().m() ;
}
}

Compile them both.

Now edit Foo to read:

public class Foo {
public String m() {
return "one" ;
}
}

At this point, your algorithm would only recompile Foo, even though Bar
is now wrong, and needs to be recompiled to detect that fact.

OK, so a dependency tree is needed after all.

Has a Java dependency scanner ever been made? Presumably it would be
somewhat more complex than makemake.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
.

Relevant Pages

  • Re: The curse of constant fields
    ... just like class files - wouldn't that be adequate? ... run, you need to recompile. ... public class Foo { ...
    (comp.lang.java.programmer)
  • Re: The curse of constant fields
    ... just like class files - wouldn't that be adequate? ... Instead of merely compiling every class which is older than the corresponding source file, set a target timestamp to match the most recent class file and then recompile all classes whose sources have been amended more recently than the target. ... public class Foo { ...
    (comp.lang.java.programmer)
  • Re: ByRef/Ref passing in Web Services
    ... I swear I wrote an example last night which didn't, ... > public int xoxo; ... > public class WebService: System.Web.Services.WebService ...
    (microsoft.public.dotnet.framework)
  • Re: Class Dispose
    ... public class Foo: IDisposable ... public void Dispose() ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Incremental Java Compile
    ... public class BB ... int field. ... I'd thought that this meant BB.x's value would be correctly computed at runtime - but of course this is not true, because AA.x's value is a compile-time constant, so it can be inlined *in BB*. ... it means you have to recompile huge numbers of unrelated sources after a change which only has limited effects. ...
    (comp.lang.java.programmer)