Incremental Java Compile
in [Java Programming]
|
From: Lew on 14 May 2010 23:05 Joshua Maurice wrote: > I was definitely under the > impression that specifically "static final" primitives can be expanded > inline. I thought there was a special language allowance for > specifically "static final". Apparently it's for "final", static or > not, (or Sun's javac is broken). Again, the JLS defines the term "constant variable" precisely, and that definition does not rest on staticness, nor stop on finality. Please read the link referenced upthread for the definition. -- Lew
From: Lew on 14 May 2010 23:10 Joshua Maurice wrote: > ... code i [sic] compile too (javac 1.6.0_16). You really should upgrade your Java version. Minor version numbers (it's up to _20 now) represent bug and security fixes, not the sort of thing you should skip. In particular, _20 was released to resolve a security hole that got a lot of publicity a couple of weeks ago. -- Lew
From: Arne Vajhøj on 15 May 2010 19:38 On 14-05-2010 23:00, Lew wrote: > Arne Vajhøj wrote: >>>>> static final is constant in Java. > Joshua Maurice<joshuamaur...(a)gmail.com> wrote: >>>> not know that "constant" means "static final" in Java. > Lew wrote: >>> Strictly speaking, it doesn't. It's a really, really, really good >>> idea to study the language spec if you actually want to learn Java. >>> The relevant section is: >>> <http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#10931> >>> > > Arne Vajhøj wrote: >> someaccess static final sometype somename = somevalue; >> >> is Java's implementation of what is generally known as >> a constant. > > The point is that the JLS defines what a constant is, and "static" is > not necessary for the definition, nor is "final" sufficient. > > Some say that it used to be "generally known" that the Earth is flat, > but that didn't make it so. > > In the Java world, the term "constant" (actually, "constant variable") > has a precise definition. It ought to be be "generally known" to be what > it actually is, and to promulgate a different conception is a disservice > to those seeking to achieve proficiency in Java programming. No. It is important for any Java programmer to understand general IT language as well. And the flat earth analogi is phony, because that was not correct while the general usage of constant is correct. Arne
From: Lew on 15 May 2010 21:03 Lew wrote: >> In the Java world, the term "constant" (actually, "constant variable") >> has a precise definition. It ought to be be "generally known" to be what >> it actually is, and to promulgate a different conception is a disservice >> to those seeking to achieve proficiency in Java programming. Arne Vajhøj wrote: > No. Yes. > It is important for any Java programmer to understand general IT > language as well. > > And the flat earth analogi is phony, because that was not correct > while the general usage of constant is correct. Java uses many terms in a language-specific way, and "constant variable" is one of them, also the one relevant to the OP. He was interested in whether a class reference is recoverable from another class, and for that the Java definition is what's relevant, not the "general usage". Also, also, you were saying that "static final" is equivalent to "constant". That is not "general usage". You can't just shift ground now simply to try to be right. That's the "Not a real Scotsman" fallacy. It simply is not true that a 'static final' variable is a constant variable in Java. You are doing would-be Java programmers a *huge* disservice by misdefining the term. You are being silly trying to change the terms of discourse to avoid the correct definition. -- Lew
From: Steven Simpson on 16 May 2010 07:47
On 14/05/10 21:11, Joshua Maurice wrote: > //AA.java > public class AA { public final int x = 1; } > //BB.java > public class BB extends AA {} > //CC.java > public class CC { public final int x = new BB().x; } > > When javac compiles CC.java, it loads BB.class, looks for a member > named x, finds no such member, then loads AA.class, and finds member > x. javac's verbose output contains this information. > > The class file CC.class does not refer to "AA" or "x". It calls BB's > constructor, and it hardcodes "1" through the JVM instruction > iconst_1. > > With just the information available in the class files, I don't think > it would be possible to detect when the change cascading down the > dependency graph can have no further effects. To know when the cascade > is done, I need the full compile dependencies, specifically "CC uses > AA". Okay, so, with classfile-extracted dependencies, if AA#x is changed, BB is recompiled, but might not change, so CC might not be recompiled to take on the new inlined value of x. But at least here you still know that CC depends on BB (as x isn't static) and BB extends AA, so CC must also depend on AA - that is available from the class files. Make x static, and you lose the "CC depends on BB" part, and indeed don't get as much as javac -verbose would tell you. -- ss at comp dot lancs dot ac dot uk |