{"id":4818,"date":"2014-03-30T15:35:37","date_gmt":"2014-03-30T15:35:37","guid":{"rendered":"https:\/\/unknownerror.org\/index.php\/2014\/03\/30\/why-my-program-doesnt-show-compile-time-error-when-final-class-variable-is-not-initialized-collection-of-common-programming-errors\/"},"modified":"2022-08-30T15:42:27","modified_gmt":"2022-08-30T15:42:27","slug":"why-my-program-doesnt-show-compile-time-error-when-final-class-variable-is-not-initialized-collection-of-common-programming-errors","status":"publish","type":"post","link":"https:\/\/unknownerror.org\/index.php\/2014\/03\/30\/why-my-program-doesnt-show-compile-time-error-when-final-class-variable-is-not-initialized-collection-of-common-programming-errors\/","title":{"rendered":"Why my program doesn't show compile time error when final class variable is not initialized?-Collection of common programming errors"},"content":{"rendered":"

Interestingly enough, the code will compile whether or not the field is marked static<\/code> – and in IntelliJ, it will complain (but compile) with the static field, and not say a word with the non-static field.<\/p>\n

You’re right in that JLS \u00a78.1.3.2 has certain rules regarding [static] final fields. However, there’s a few other rules around final fields that play a large role here, coming from the Java Language Specification \u00a74.12.4 – which specify the compilation semantics of a final<\/code> field.<\/p>\n

But before we can get into that ball of wax, we need to determine what happens when we see throws<\/code> – which is given to us by \u00a714.18, emphasis mine:<\/p>\n

\n

A throw statement causes an exception (\u00a711) to be thrown. The result is an immediate transfer of control (\u00a711.3) that may exit multiple statements and multiple constructor, instance initializer, static initializer and field initializer evaluations, and method invocations<\/strong> until a try statement (\u00a714.20) is found that catches the thrown value. If no such try statement is found, then execution of the thread (\u00a717) that executed the throw is terminated (\u00a711.3) after invocation of the uncaughtException method for the thread group to which the thread belongs.<\/p>\n<\/blockquote>\n

In layman’s terms – during run-time, if we encounter a throws<\/code> statement, it can interrupt the execution of the constructor (formally “completes abruptly”), causing the object to not be constructed, or constructed in an incomplete state (which could be a security hole, depending on the platform and partial completeness of the constructor).<\/p>\n

What the JVM expects, given by \u00a74.5, is that a field with ACC_FINAL<\/code> set never has its value set after construction of the object<\/strong>:<\/p>\n

\n

Declared final; never directly assigned to after object construction (JLS \u00a717.5).<\/p>\n<\/blockquote>\n

So, we’re in a bit of a pickle – we expect behavior of this during run-time<\/em>, but not during compile-time<\/em>. And why does IntelliJ raise a mild fuss when I have static<\/code> in that field, but not when I don’t?<\/p>\n

First, back to throws<\/code> – there’s only a compile-time error with that statement if one of these three pieces aren’t satisfied:<\/p>\n

    \n
  • The expression being thrown is unchecked or null,<\/li>\n
  • You try<\/code> to catch<\/code> the exception, and you’re catch<\/code>ing it with the right type, or<\/li>\n
  • The expression being thrown is something that can actually thrown, per \u00a78.4.6 and \u00a78.8.5.<\/li>\n<\/ul>\n

    So compiling a constructor with a throws<\/code> is legitimate. It just so happens that, at run-time, it will always complete abruptly.<\/p>\n

    \n

    If a throw statement is contained in a constructor declaration, but its value is not caught by some try statement that contains it, then the class instance creation expression that invoked the constructor will complete abruptly because of the throw (\u00a715.9.4).<\/p>\n<\/blockquote>\n

    Now, onto that blank final<\/code> field. There’s a curious piece to them – their assignment only matters after<\/em> the end of the constructor, emphasis theirs.<\/p>\n

    \n

    A blank final instance variable must be definitely assigned (\u00a716.9) at the end of every constructor (\u00a78.8) of the class in which it is declared; otherwise a compile-time error occurs.<\/strong><\/p>\n<\/blockquote>\n

    What if we never<\/em> reach the end of the constructor?<\/p>\n

    First program: Normal instantiation of a static final<\/code> field, decompiled:<\/p>\n

    \/\/ class version 51.0 (51)\n\/\/ access flags 0x21\npublic class com\/stackoverflow\/sandbox\/DecompileThis {\n\n    \/\/ compiled from: DecompileThis.java\n\n    \/\/ access flags 0x1A\n    private final static I i = 10\n\n    \/\/ access flags 0x1\n    public ()V\n            L0\n    LINENUMBER 7 L0\n    ALOAD 0\n    INVOKESPECIAL java\/lang\/Object. ()V\n            L1\n    LINENUMBER 9 L1\n            RETURN \/\/  0) {\n        return true;\n    } else {\n        throw new IllegalStateException(\"Non-natural number!?\");\n    }\n}\n<\/code><\/pre>\n","protected":false},"excerpt":{"rendered":"
    Interestingly enough, the code will compile whether or not the field is marked static – and in IntelliJ, it will complain (but compile) with the static field, and not say a word with the non-static field. You’re right in that JLS \u00a78.1.3.2 has certain rules regarding [static] final fields. However, there’s a few other rules […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4,1],"tags":[],"class_list":["post-4818","post","type-post","status-publish","format-standard","hentry","category-semantic","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/4818","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/comments?post=4818"}],"version-history":[{"count":1,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/4818\/revisions"}],"predecessor-version":[{"id":8782,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/4818\/revisions\/8782"}],"wp:attachment":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/media?parent=4818"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/categories?post=4818"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/tags?post=4818"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}