trigger static init

Discussion in 'Java' started by Roedy Green, Apr 9, 2012.

  1. Roedy Green

    Roedy Green Guest

    What is the canonical way to explicitly trigger a static class to load
    and run thestatic init without actually invoking a real method?

    you can't necessarily use newInstance since the class may not have
    constructors.

    Do you have to invent some dummy static method?
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    When you were a child, if you did your own experiment
    to see if it was better to put to cocoa into your cup first
    or the hot milk first, then you likely have the programmer gene..
     
    Roedy Green, Apr 9, 2012
    #1
    1. Advertising

  2. Roedy Green <> writes:

    > What is the canonical way to explicitly trigger a static class to load
    > and run thestatic init without actually invoking a real method?


    I suggest Class.forName(String classname), if you just want to avoid
    invoking a method of the class to be loaded and don't mind invoking
    one of the Class class.

    If you insist on not invoking any method of *any* class and thus don't
    want to use Class.forName, you can refer to some public static attribute
    of the class.

    --
    Jukka Lahtinen
     
    Jukka Lahtinen, Apr 9, 2012
    #2
    1. Advertising

  3. Roedy Green <> wrote:
    > What is the canonical way to explicitly trigger a static class to load
    > and run thestatic init without actually invoking a real method?


    > you can't necessarily use newInstance since the class may not
    > have constructors.


    As far as I know, a class automatically has a no argument constructor,
    even if you don't write one.

    class myclass {
    static int x;
    }

    compiles just fine, as does creating an object from it.

    > Do you have to invent some dummy static method?


    Not that I know of.

    -- glen
     
    glen herrmannsfeldt, Apr 9, 2012
    #3
  4. Roedy Green

    Roedy Green Guest

    On Mon, 9 Apr 2012 09:18:04 +0000 (UTC), glen herrmannsfeldt
    <> wrote, quoted or indirectly quoted someone who
    said :

    >As far as I know, a class automatically has a no argument constructor,
    >even if you don't write one.


    You can't always do that. The sole explicit constructor may be private
    to explicitly stop you from instantiating objects.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    When you were a child, if you did your own experiment
    to see if it was better to put to cocoa into your cup first
    or the hot milk first, then you likely have the programmer gene..
     
    Roedy Green, Apr 9, 2012
    #4
  5. Roedy Green

    Roedy Green Guest

    On Mon, 09 Apr 2012 10:32:21 +0300, Jukka Lahtinen
    <> wrote, quoted or indirectly quoted
    someone who said :

    >, you can refer to some public static attribute
    >of the class.


    But it had better not be a static final known at compile time, or it
    will be optimised to a literal and referencing it won't load the
    class.

    I decided to handle it by putting in dummy public static void fireup()
    methods that as a side effect load the class and run static init. If I
    fail to call them, class loading is just procrastinated until first
    use.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    When you were a child, if you did your own experiment
    to see if it was better to put to cocoa into your cup first
    or the hot milk first, then you likely have the programmer gene..
     
    Roedy Green, Apr 9, 2012
    #5
  6. Roedy Green

    markspace Guest

    On 4/9/2012 6:09 AM, Roedy Green wrote:

    > I decided to handle it by putting in dummy public static void fireup()
    > methods that as a side effect load the class and run static init. If I
    > fail to call them, class loading is just procrastinated until first
    > use.



    This sort of idea sounds to me like the worst sort of hackish design
    possible. Don't use statics for this use case. Use Factories, or
    Strategies, or even just a Properties object if you only need to load a
    few constants at runtime.
     
    markspace, Apr 9, 2012
    #6
  7. Roedy Green

    Lew Guest

    glen herrmannsfeldt wrote:
    > Roedy Green wrote:
    > > What is the canonical way to explicitly trigger a static class to load
    > > and run thestatic init without actually invoking a real method?

    >
    > > you can't necessarily use newInstance since the class may not
    > > have constructors.

    >
    > As far as I know, a class automatically has a no argument constructor,
    > even if you don't write one.
    >
    > class myclass {
    > static int x;
    > }


    He meant no *accessible* constructors.

    If the constructor is not accessible, its existence is moot.

    And Java coding conventions call for type names to have an initial upper-case letter and be in camel case: 'MyClass'.

    > compiles just fine, as does creating an object from it.
    >
    > > Do you have to invent some dummy static method?

    >
    > Not that I know of.


    The rules for class initialization are quite explicitly listed in the JLS, which document is eminently useful no matter how much one may affect to loathe it.
    <http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.4.2>

    --
    Lew
     
    Lew, Apr 9, 2012
    #7
  8. Roedy Green

    Lew Guest

    Roedy Green wrote:
    > Jukka Lahtinen wrote, quoted or indirectly quoted someone who said :
    >>, you can refer to some public static attribute
    >>of the class.

    >
    > But it had better not be a static final known at compile time, or it
    > will be optimised to a literal and referencing it won't load the
    > class.
    >
    > I decided to handle it by putting in dummy public static void fireup()
    > methods that as a side effect load the class and run static init. If I
    > fail to call them, class loading is just procrastinated until first
    > use.


    Two questions:

    Why is it important to control when the class loads, instead of using the default?
    What was wrong with 'Class#forName()', which is intended for the purpose and is not a hack?

    --
    Lew
     
    Lew, Apr 9, 2012
    #8
  9. Roedy Green

    Lew Guest

    Jukka Lahtinen wrote:
    > Roedy Green writes:
    >> What is the canonical way to explicitly trigger a static class to load
    >> and run thestatic init without actually invoking a real method?

    >
    > I suggest Class.forName(String classname), if you just want to avoid
    > invoking a method of the class to be loaded and don't mind invoking
    > one of the Class class.
    >
    > If you insist on not invoking any method of *any* class and thus don't
    > want to use Class.forName, you can refer to some public static attribute
    > of the class.


    Bear in mind that the 'class' literal does not apply here. Referencing the 'class' literal does not incur class initialization.

    --
    Lew
     
    Lew, Apr 9, 2012
    #9
  10. Roedy Green

    Daniel Pitts Guest

    On 4/8/12 11:28 PM, Roedy Green wrote:
    > What is the canonical way to explicitly trigger a static class to load
    > and run thestatic init without actually invoking a real method?
    >
    > you can't necessarily use newInstance since the class may not have
    > constructors.
    >
    > Do you have to invent some dummy static method?

    If you have to worry about this problem, then you've got the wrong design.

    Classes always have a constructor, but they may not have a Default
    constructor, or the constructor may be private.

    In any case, if you know about the class specifically before hand, then
    you probably have the wrong design, and should convert it to a
    non-static class. Probably you want dependency injection if you need
    only one. Perhaps as a singleton if you *really* need that, but only as
    a last resort.
     
    Daniel Pitts, Apr 10, 2012
    #10
  11. Lew <> wrote:
    > Referencing the 'class' literal does not incur class initialization.


    from JLS 12.4.1:
    A class [...] T is initialized immediately before first [...]
    T is a class and an instance of T is created.
    T is a class and a static method declared by T is invoked.
    A static field declared by T is assigned.
    A static field declared by T is used [ ... and not constant ... ]
    T is a top-level class, and an assert statement (§14.10) lexically
    nested within T is executed.

    Does using a class-literal <T.class> in "synchronized(T.class) {...}" count
    in for implicitly using the monitor-field of the Class<T>-instance, or is
    it strictly undefined (or defined somewhere else)?

    Btw., I don't understand the point about assert. If the assert is
    lexically nested in T and gets executed, then I'd have naively thought,
    that one of the first two points would necessarily have happened,
    anyway, before the assert could be reached. What am I missing here?
     
    Andreas Leitgeb, Apr 11, 2012
    #11
  12. On 4/11/2012 7:52 AM, Andreas Leitgeb wrote:
    > Lew<> wrote:
    >> Referencing the 'class' literal does not incur class initialization.

    >
    > from JLS 12.4.1:
    > A class [...] T is initialized immediately before first [...]
    > T is a class and an instance of T is created.
    > T is a class and a static method declared by T is invoked.
    > A static field declared by T is assigned.
    > A static field declared by T is used [ ... and not constant ... ]
    > T is a top-level class, and an assert statement (§14.10) lexically
    > nested within T is executed.
    >
    > Does using a class-literal<T.class> in "synchronized(T.class) {...}" count
    > in for implicitly using the monitor-field of the Class<T>-instance, or is
    > it strictly undefined (or defined somewhere else)?


    So, the use of "T.class" creates an object of Class<T>, which is not
    sufficient to cause T to be initialized. Some more inspection of the JLS
    (and some experiments) leads me to the conclusion that a
    synchronized(T.class) block can race with the initialization of T.

    Experiments confirm that synchronized(T.class) does not cause
    initialization of T.
    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
     
    Joshua Cranmer, Apr 11, 2012
    #12
  13. Joshua Cranmer <> wrote:
    > On 4/11/2012 7:52 AM, Andreas Leitgeb wrote:
    >> Lew<> wrote:
    >>> Referencing the 'class' literal does not incur class initialization.

    >> Does using a class-literal<T.class> in "synchronized(T.class) {...}" count
    >> in for implicitly using the monitor-field of the Class<T>-instance, or is
    >> it strictly undefined (or defined somewhere else)?

    > So, the use of "T.class" creates an object of Class<T>, which is not
    > sufficient to cause T to be initialized.


    Thanks for hitting my nail of misconception right on its head :)

    > Some more inspection of the JLS
    > (and some experiments) leads me to the conclusion that a
    > synchronized(T.class) block can race with the initialization of T.
    > Experiments confirm that synchronized(T.class) does not cause
    > initialization of T.


    Once I got creation of the Class<T> instance and initialization
    of the class properly separated, then that is no longer a surprise :)

    Thanks.
     
    Andreas Leitgeb, Apr 11, 2012
    #13
  14. Roedy Green

    Lew Guest

    On 04/11/2012 07:39 AM, Joshua Cranmer wrote:
    > On 4/11/2012 7:52 AM, Andreas Leitgeb wrote:
    >> Lew<> wrote:
    >>> Referencing the 'class' literal does not incur class initialization.

    >>
    >> from JLS 12.4.1:
    >> A class [...] T is initialized immediately before first [...]
    >> T is a class and an instance of T is created.
    >> T is a class and a static method declared by T is invoked.
    >> A static field declared by T is assigned.
    >> A static field declared by T is used [ ... and not constant ... ]
    >> T is a top-level class, and an assert statement (§14.10) lexically
    >> nested within T is executed.
    >>
    >> Does using a class-literal<T.class> in "synchronized(T.class) {...}" count
    >> in for implicitly using the monitor-field of the Class<T>-instance, or is
    >> it strictly undefined (or defined somewhere else)?

    >
    > So, the use of "T.class" creates an object of Class<T>, which is not
    > sufficient to cause T to be initialized. Some more inspection of the JLS (and
    > some experiments) leads me to the conclusion that a synchronized(T.class)
    > block can race with the initialization of T.
    >
    > Experiments confirm that synchronized(T.class) does not cause initialization
    > of T.


    It used to, in contravention of the JLS.

    "A class or interface will not be initialized under any other circumstance."
    <http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.4.1>

    It's important to note that the Java Language Specification explicitly forbids
    class initialization from use of the 'class' literal. Prior to Java 5 there
    was a bug that it did, which Sun fixed with version 5. This caused certain
    libraries (notably Apache Commons) to break where they relied on the buggy
    behavior, when run under Java 5+ under certain corner scenarios.

    --
    Lew
    Honi soit qui mal y pense.
    http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
     
    Lew, Apr 11, 2012
    #14
  15. Patricia Shanahan <> wrote:
    > On 4/11/2012 5:52 AM, Andreas Leitgeb wrote:
    >> T is a top-level class, and an assert statement (§14.10) lexically
    >> nested within T is executed.
    >> Btw., I don't understand the point about assert. If the assert is
    >> lexically nested in T and gets executed, then I'd have naively thought,
    >> that one of the first two points would necessarily have happened,
    >> anyway, before the assert could be reached. What am I missing here?

    > Suppose S is a static class defined in T. I interpreted that as meaning
    > that executing an assert in S would trigger initialization of T.
    > Or suppose S is non-static, but the assert is in its static code.


    I don't yet get it.

    === Main.java ===
    public class Main {
    public static void main(String[] args) {
    Object foo = new Outer.Inner();
    }
    }
    class Outer {
    static {
    System.out.println("Outer init");
    }
    public static class Inner {
    static {
    System.out.println("Inner init1");
    assert 1==1 : "oups!";
    System.out.println("Inner init2");
    }
    }
    }
    === call ===
    $ java -ea Other ;# ditto without the -ea
    Inner init1
    Inner init2
    $ java -version
    java version "1.6.0_26"
    Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
    Java HotSpot(TM) Server VM (build 20.1-b02, mixed mode)
    $
    === end of SSCCE ===

    So, it *is* possible to run code "lexically included in Outer"
    without Outer having been initialized first (which I had wrongly
    believed to be impossible), but assert itself doesn't seem to
    have the specified effect. I also read §14.10, but that just
    affirms, that (in order to determine the Assertion-flag for the
    toplevel class "Outer") "Outer" would be initialized, too.
    It doesn't seem to happen, though.
     
    Andreas Leitgeb, Apr 11, 2012
    #15
  16. On 11/04/12 15:04, Patricia Shanahan wrote:
    > Suppose S is a static class defined in T. I interpreted that as meaning
    > that executing an assert in S would trigger initialization of T.
    >
    > Or suppose S is non-static, but the assert is in its static code.


    Can non-static S contain static code?


    --
    ss at comp dot lancs dot ac dot uk
     
    Steven Simpson, Apr 12, 2012
    #16
  17. Patricia Shanahan <> wrote:
    > On 4/11/2012 8:30 AM, Andreas Leitgeb wrote:
    >> Patricia Shanahan<> wrote:
    >>> On 4/11/2012 5:52 AM, Andreas Leitgeb wrote:
    >>>> T is a top-level class, and an assert statement (§14.10) lexically
    >>>> nested within T is executed.

    >> [an example that shows this point wrong]

    > [another more elaborate example that shows this point wrong]


    So, there seems to be a "bug", but no one seems to give a f^Hdime. ;-)
     
    Andreas Leitgeb, Apr 22, 2012
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tony Cheng
    Replies:
    1
    Views:
    8,285
    Juan T. Llibre
    Feb 24, 2006
  2. Replies:
    1
    Views:
    683
    Jules
    Aug 18, 2005
  3. Jess
    Replies:
    4
    Views:
    462
  4. Replies:
    2
    Views:
    276
    Antoninus Twink
    Apr 17, 2008
  5. news.aon.at
    Replies:
    11
    Views:
    666
    Ian Collins
    Jan 29, 2011
Loading...

Share This Page