I've just read http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns.html?page=5 and it says:
the compiler is free to assign a value to the singleton member variable before the singleton's constructor is called
I'm wondering if it is a typo. Do they actually really wanted to say: the implementation of the JVM is free to instead of the compiler is free to.
and my second question is that do we have this issue with C#/VB as well? (in which the ""compiler"" is free to assign a value to a variable even before the variable is fully initiated/even before the constructor function of the class of the variable is fully ran.
The answer the first part of the question is that you are correct, though this is more a case of sloppy terminology than a typo or a mistake. (Plainly, the compiler doesn't assign values to variables ... this only happens when the code generated by the compiler is executed.)
A more technically accurate restatement would be:
"... because the compiler is free to generate code that may cause a value to be written to memory for the singleton member variable before the singleton's constructor has been called, and the constructed object has been flushed to memory."
This kind of thing is most likely to happen at the native code compiler level, when the compiler (legally) reorders instructions, or simply as a result of memory pipelining. The Java memory model specifically allow this so that the compiler is able to generate code that runs faster on multi-core machines. (The flip-side is that your multi-threaded code has to synchronize in the required way, or else it is liable to be unreliable.)
(It is also theoretically possible for the bytecode compiler to reorder bytecodes, but the chances are that it won't. There is little value in the bytecode compiler doing fine-grained optimization. Indeed, it can be harmful since it potentially makes it harder for the JIT compiler's optimizer.)
I'll leave the C# and VB cases to someone who is familiar with the specifications of those languages.