dependency-detection in java

[Daniel Pitts]

"let me determine" ? I'm not sure if I parse this phrase correctly.
Does it mean, it determines it for me, or asks me to determine it myself?


The IDE's I've used so far offer these features (with respect to this context)
- create an ant-script and use ant for building, offering a "build" and
a "build all" button. This is where this Thread's problem is
*not* solved. "Reverse-dependencies" as they seem to be called
are not considered.
- for a certain identifier give me a list of locations where it is used.
This is the right direction, but doesn't go far enough.
I haven't yet seen an IDE, that would use this information
automatically for rebuilding.

Did I miss any other feature that you had in mind?

Nope.
The real point is, if you're using a public static constant, you don't
know WHO is going to use it. It might even be in another codebase
altogether. This is just another one of the reasons that "Globals are
bad things" .

Well, I hope you find the answer you want, since you don't want any of
the answers you got. Good luck to you.

 

[Steven Simpson]

- final statics are inlined in client classes without any reference to
where they came from and so changes to the class that defines them
will not cause client classes to be recompiled.

- javac doesn't handle this at all and so fails to correctly recompile
code unless you start by deleting all .class files.

So the inlining causes the class file to seem to not depend on the class
containing the static final - which is true for actually being able to
get the code running, but false as far as javac's dependency handling is
concerned? And false when separate codebases are involved? Sounds like
inlining is the wrong thing for javac to do, in spite of any performance
gain.

If inlining by javac were disabled, could JITting do it effectively
instead? I hear it's so groovy and funky these days...

 

[Daniel Pitts]

So the inlining causes the class file to seem to not depend on the class
containing the static final - which is true for actually being able to
get the code running, but false as far as javac's dependency handling is
concerned? And false when separate codebases are involved? Sounds like
inlining is the wrong thing for javac to do, in spite of any performance
gain.

I agree. If anything, it should be inlined at class-load time, rather
than at class-compile time.

If inlining by javac were disabled, could JITting do it effectively
instead? I hear it's so groovy and funky these days...

I don't know, but you have to wonder at any case that is specific to
Strings and primitives. The more I think about it, the more I realize
that javac can't inline regular object references, because those
object instances aren't represented until runtime (unlike interned
strings and primitive values).

To the OP: If you could rework any case that requires a constant (only
switch's do), then you really should use a getter instead.

 

[Stefan Ram]

What is the usual "trick" to make sure that all
"B"-type classes are recompiled, when an "A"-type
class has changed?

One trick in this regard is written down in my own
German-language Java course [1], but I was not aware of it
when I posted to this thread recently. Now, I ran into it,
and I believe this was not yet posted in this thread -
but I also have not tested it again:

So, to prevent the following two constants :

public static final String text = "example";
public static final int e = 7;

from being inlined into other class files,
use any runtime-only operation in their
declaration, like, for example:

public static final String text = "example".toString();
public static final int e = new Integer( 7 ).intValue();

[1] I found this in the following lesson of my German language
Java course in the section »Laufzeit-Initialisierungen erzwingen«:

http://www.purl.org/stefan_ram/pub/java_exemplarerzeugung_de

 

[Andreas Leitgeb]

Nope.

Damn, I sure would have hoped I did ;-)

The real point is, if you're using a public static constant, ...

No, the real point is, that static final fields are just one part
of a class' public interface.

Following reverse dependencies is necessary (well, apart from
full rebuilds, of course) to find all bad consequences of such
a change in the context of the project.
E.g. adding "throws MyException" to some method is just the same
beast. It may be necessary, and then I want the compiler to help
me as efficiently as possible to find other classes that need
to be adapted as well.

It might even be in another codebase altogether.

But then, I hopefully have some testsuite-classes inside my codebase
that take care of the external interfaces.
While changed constant values do not trigger errors, the values
shouldn't be depended upon, anyway, beyond that it's the same in
every relevant class of the codebase. The latter is guaranteed
by either a full rebuild or a correct reverse-dependency-following
build.

Well, I hope you find the answer you want, since you don't want
any of the answers you got. Good luck to you.

Yes, I know, I'm pickish thanks.

 

[Andreas Leitgeb]

So the inlining causes the class file to seem to not depend on the class
containing the static final - which is true for actually being able to
get the code running, but false as far as javac's dependency handling is
concerned? And false when separate codebases are involved? Sounds like
inlining is the wrong thing for javac to do, in spite of any performance
gain.

No, I wouldn't go so far as to say that it was wrong.
The effect could also be solved by adding some attribute (inside the .class
format) that just mentions the foreign "path.class.CONST_ATTR" as having
been inlined (eventually, the value could be included as well, by reference
to the constant pool.)
That would make it feasible to auto-generate all dependency information.
(All other dependencies already show up, afterall, in the .class-file)
And if the value was included as well, extra tools could auto-check that
all constants are indeed consistent over all class-files.

 

[Andreas Leitgeb]

I don't know, but you have to wonder at any case that is specific to
Strings and primitives. The more I think about it, the more I realize
that javac can't inline regular object references, because those
object instances aren't represented until runtime (unlike interned
strings and primitive values).

Indeed: Strings, longs, floats and doubles are inlined to using class'
constant pool. ints are directly inlined at each usage
(e.g. as in "bipush 42"), all other objects (except Strings)
are accessed through getstatic.

To the OP: If you could rework any case that requires a constant ...

I've answered that elsewhere, already.

 

[Andreas Leitgeb]

So, to prevent the following two constants :
public static final String text = "example";
public static final int e = 7;
use any runtime-only operation in their
declaration, like, for example:
public static final String text = "example".toString();
public static final int e = new Integer( 7 ).intValue();
http://www.purl.org/stefan_ram/pub/java_exemplarerzeugung_de

This was indeed new to me, and I'll surely run into a situation
someday where I'll use it, but for the case at hand it won't work,
because the final static fields are autogenerated from idl-files.

 

[Andreas Leitgeb]

Indeed: Strings, longs, floats and doubles are inlined to using class'
constant pool. ints are directly inlined at each usage
(e.g. as in "bipush 42"), all other objects (except Strings)
are accessed through getstatic.

Damn, have to correct myself: Only ints in the range of shorts are
inlined. ints <-32768 or >32767 are constant-pool'ed.
Otoh., long, float and double constants, for which bytecodes exist
(like dconst_1) are inlined directly into code, like those short
integers.