A static method can be accessed without creating an instance of the class.

If you try to use a

non-static method and variable defined in this class then the compiler will say that non-static
variable or method cannot be referenced from a static context. Static method can call only other
static methods and static variables defined in the class.

class StaticDemo {
static int a = 42;
static int b = 99;
static void callme() {
System.out.println("a = " + a);
}
}
class StaticByName {
public static void main(String args[]) {
StaticDemo.callme();
System.out.println("b = " + StaticDemo.b);
}
}
Here is the output of this program:
a = 42
b = 99

Java Final Keyword

 A java variable can be declared using the keyword final. Then the final
variable can be assigned only once.
 A variable that is declared as final and not initialized is called a blank
final variable. A blank final variable forces the constructors to initialise it.
 Java classes declared as final cannot be extended. Restricting
inheritance!
 Methods declared as final cannot be overridden. In methods private is
equal to final, but in variables it is not.
 final parameters – values of the parameters cannot be changed after
initialization. Do a small java exercise to find out the implications of final
parameters in method overriding.
 Java local classes can only reference local variables and parameters that
are declared as final.
 A visible advantage of declaring a java variable as static final is, the
compiled java class results in faster performance.
Why is this necessary?

The final field is a means of what is sometimes called safe publication.

Here, "publication" of an object means creating it in one thread and then
having that newly-created object be referred to by another thread at
some point in the future. When the JVM executes the constructor of your
object, it must store values into the various fields of the object, and store
a pointer to the object data. As in any other case of data writes, these
accesses can potentially occur out of order, and their application to main
memory can be delayed and other processors can be delayed unless you
take special steps to combat this. In particular, the pointer to the object
data could be stored to main memory and accessed before the fields
themselves have been committed (this can happen partly because of
compiler ordering: if you think about how you'd write things in a low-level
language such as C or assembler, it's quite natural to store a pointer to a
block of memory, and then advance the pointer as you're writing data to
that block). And this in turn could lead to another thread seeing the
object in an invalid or partially constructed state.

final prevents this from happening: if a field is final, it is part of the JVM
specification that it must effectively ensure that, once the object pointer
is available to other threads, so are the correct values of that object's
final fields.

Final object references

The fields on any object accessed via a final reference are also
guaranteed to be at least as up to date as when the constructor exits.
This means that:

Values of final fields, including objects inside collections referred to by

a final reference, can be safely readwithout synchronization.

Note that if you have a final reference to a collection, array, or some

other mutable object, you must still synchronize all accesses to that
object (or use a thread-safe collection such as a ConcurrentHashMap) if
that collection is ever accessed by a thread other than the constructing
thread.

Thus, immutable objects (ones where all fields are final and are either
primitives or references to immutable objects) can be concurrently
accessed without synchronization. It is also safe to read "effectively
immutable" objects (ones whose fields aren't actually final, but in practice
never change) via a final reference. However, from a program design
perspective, you'd be wise to try and enforce immutability in this case
(e.g. by wrapping a collection in aCollections.unmodifiableList()1 etc). That
way, you'll spot bugs introduced when one of your colleagues naughtily
attempts to modify a collection that you didn't intend to be modified!

Restrictions and limitations of using final

When you declare a field final, you must set the value once by the
time the constructor exits. This means that you can declare a final
field as follows:

public class MyClass {

private final int myField = 3;
public MyClass() {
...
}
}

or you can write the following:

public class MyClass {

private final int myField;
public MyClass() {
...
myField = 3;
...
}
}

It's important to emphasise that storing a reference to an object in

a final field only makes the reference immutable, not the actual
object. For examlple, if a list is declared as follows:

private final List myList = new ArrayList();

there's nothing to stop modifications to the list:

myList.add("Hello");

However, the following would not be possible:

myList = new ArrayList();

myList = someOtherList;
When should I use final?

One answer to this is "whenever you possibly can". Any field that you
never expect to be changed (be that a primitive value, or a reference to
an object, whether or not that particular object is itself immutable or
not), should generally be declared final. Another way of looking at things
is:

If your object is accessed by multiple threads, and you don't declare its
fields final, then you must providethread-safety by some other
means.

Other means could include declaring the field volatile,

using synchronized or an explicit Lock around all accesses to that field.

A typical case that people overlook is where an object is created by one

thread and then later consumed by another thread, e.g. an object via
a ThreadPoolExecutor. In this case, the object must still be made
properly thread-safe: it doesn't matter that the accesses by different
threads aren't concurrent. What matters is that the object is accessed by
different threads at any point in its lifetime.

Enum is a keyword which was introduced in Java 5. It is a particular type of class whose
instances are only those objects which are members of that enum. The super class of all enum
objects is java.lang.Enum, apart from this enum can not be extended.

There is another important feature that is every enum requires support from the class library.
When a program compiles and compiler encounters an enum type, it generates a class that
extends the java.lang.Enum, which is a library class.