Re: dependency-detection in java - Take 2

Michael Jung <miju@xxxxxxxxxxxxx> wrote:
Andreas Leitgeb <avl@xxxxxxxx> writes:
Is dependency-analysis necessarily more (or almost as)
expensive than a full compile?
I'm pretty sure it's of the same order with regards to code base size in
general. What the factor between them is, will depend on your needs.
There is a way to circumvent that by keeping the reverse-dependencies in some
database, which you update as B's are checked in and which you query when A's
are checked in.

The current approach is a bit more reluctant. I'd just like to
determine "relevant" changes between each new .class file and it's
previous version (stored in some database or file)

My current focus would be finding out what changes in a class are
relevant, and which are not. Based on the existence of relevant
changes, a full-compile of the project would be triggered.

What is "relevant"? The definition would be: any change in
a class A, for which a class B exists in the project's codebase,
which compiled with old and new version of A.java in place would
result in different generated .class files. (not only B.class!)
This definition is not yet cast in stone, since even changes
in the classes generated from such B.java could also be
subject to qualification as effective or non-effective.

But how do we practically determine "relevant"ness?
I think we can only carefully *approach* it for now.

As a very first step, any change in the class' interface could be
considered relevant, which would save full-compiles when only
method-implementations or private members were changed.
(Note that private nested classes are classes on their own, so
adding one, or even removing one is irrelevant, and for changing
one, the same rules apply on that private class itself)

For the next step, adding a new non-static method (whose name wasn't
yet used in that class, not even with a different signature), or certain
types of private methods or data could be considered harmless.

Also, as long as no variadic methods exist yet, even overloaded method
names with a previously nonexisting arity should be harmless. (There is
no way for the compiler to pick these instead of te existing ones in
the course of recompiling any dependent class.)

Any other interface changes, that are provably irrelevant to
recompiling depending classes?

.

Relevant Pages

  • Re: virtual inheritance question
    ... > May someone explain why does this compile? ... > class Sealed: virtual HiddenSealBaseClass ... > class SomeClass: Sealed ... > HiddenSealBaseClassshould have become private after Sealed ...
    (comp.lang.cpp)
  • How is it that a private main method is still runnable in a console application?
    ... (It was trivial to compile the HelloWorldConsole.cs file with csc and run it ... directly as an Windows executable.) ... code with a Main method carrying default (private) visibility can be run ... Can anyone help me discover where my understanding of method visibility in ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Ada Plattform Independence
    ... is to make it private, which causes problems if people are doing ... representation clauses, sometimes for good reasons: ... Duration is 32 bits to one where Duration is 64 bits ... compile this code, it should use the same implementation of Duration? ...
    (comp.lang.ada)
  • Re: Unmanaged C functions and C++ classes wrapped in an assembly not as public but as managed privat
    ... > PRIVATE and NOT PUBLIC as their are created now. ... Compile with /d1PrivateNativeTypes for the value classes created mapping the ... > managed-unmanaged assemblies and looking aftwerwards with ILDASM at what ... > having specified to have the compiler produce NO debugging information. ...
    (microsoft.public.dotnet.framework)
  • Re: Unmanaged C functions and C++ classes wrapped in an assembly not as public but as managed privat
    ... > PRIVATE and NOT PUBLIC as their are created now. ... Compile with /d1PrivateNativeTypes for the value classes created mapping the ... > managed-unmanaged assemblies and looking aftwerwards with ILDASM at what ... > having specified to have the compiler produce NO debugging information. ...
    (microsoft.public.dotnet.framework.interop)