static-initialization

public class Main { public static void main(String[] args) { System.out.println(B.x); } } class A { public static String x = "x"; } class B extends A { static { System.out.print("Inside B."); } } Question: Why output will be: x . But not: Inside B.x The reference to B.x issues the following bytecode: getstatic #3 <Field int B.x> According to Java Virtual Machine Spec The Java virtual machine instructions anewarray, checkcast, getfield, getstatic , instanceof, invokedynamic, invokeinterface, invokespecial, invokestatic, invokevirtual, ldc, ldc_w, multianewarray, new, putfield, and putstatic

This question made me question a practice I had been following for years. For thread-safe initialization of function-local static const objects I protect the actual construction of the object, but not the initialization of the function-local reference referring to it. Something like this: namespace { const some_type& create_const_thingy() { lock my_lock(some_mutex); static const some_type the_const_thingy; return the_const_thingy; } } void use_const_thingy() { static const some_type& the_const_thingy = create_const_thingy(); // use the_const_thingy } The idea is that locking takes time, and if

CAUTION: it is not a duplicate, please read topic сarefully https://stackoverflow.com/users/3448419/apangin quote: The real question is why the code sometimes works when it should not. The issue reproduces even without lambdas. This makes me think there might be a JVM bug. In the comments of https://stackoverflow.com/a/53709217/2674303 I tried to find out reasons why code behaves differently from one start to another and participants of that discussion made me piece of of advice to create a separated topic. Let's consider following source code: public class Test { static { System.out.println(

Let's say I have a type of lookup table which I can build for a given integer: class FooLookupTable { ... public: FooLookupTable(int radix) { ... } }; Then there's a class whose template parameter is that same integer, and whose constructor initializes a member instance of this lookup table: template <int radix> class Foo { ... private: FooLookupTable table; public: Foo () : FooLookupTable (radix) { ... } }; Throughout my code I instantiate these with various values of radix: int main() { ... Foo<1> myFoo; Foo<1> yourFoo; Foo<10> theirFoo; ... } This works and doesn't create any hairy

Once I was reading an awesome C++ FAQ (It is really good!!) and read the topic about how to prevent the static initialization order "fiasco". So the author advises to wrap the static variables into functions, thus to prevent the "fiasco" by maintaining the creation order of variables. But this seems to me a rude workaround. So my question is, is there any modern, more pattern oriented way to prevent this "fiasco" but to wrap the "static stuff" into functions??? The modern, more pattern-oriented way is not to use globals in the first place . There's no other way around it. It wouldn't be much

Given a static class with an initializer method: public static class Foo { // Class members... internal static init() { // Do some initialization... } } How can I ensure the initializer is run before Main() ? The best I can think of is to add this to Foo : private class Initializer { private static bool isDone = false; public Initializer() { if (!isDone) { init(); isDone = true; } } } private static readonly Initializer initializer = new Initializer(); Will this work or are there some unforeseen caveats? And is there any better way of doing this? Simply do the initialization inside a static

I'm trying to implement a tracing aspect using the pertypewithin instantiation model. In this way, I'll be able to use one logger per class per type. From some examples arround the we I can find this code to init the logger: public abstract aspect TraceAspect pertypewithin(com.something.*) { abstract pointcut traced(); after() : staticinitialization(*) { logger = Logger.getLogger(getWithinTypeName()); } before() : traced() { logger.log(...); } //.... } unfortunately, I'm not able to fully translate this to the @AspectJ syntax (it's a project requirement outside my control), especially the part