This creates an object reference log Its type will be Logger The Logger class has a static method called getLogger; actually, it has a number of methods called getLogger, each taking different arguments. One of them takes a Class object as the parameter. I think this is the point where you got confused.
In Java, you normally use variables that are of primitive types (int, long, boolean...), or 'real' objects like String, Date, List (or arrays, for that matter, such as int).
Each of those types, whether primitive or 'real' object, is represented by a type.
In real life, you may have people Agnes, Susana, John and Peter; they would be represented by objects in your code. The classes representing them could be 'Woman' and 'Man'. The class representing their name is String; the type representing their year of birth is int.
The class Class (ouch!) is the meta-information which tells you what type the object is.
You can try this:
So you can have variables/objects that represent the type of something. classOfNow will be a reference to a Class object, actually a reference to Date.class. Similarly, classOfName will be a reference to a Class object, String.class.
These objects can be used as method arguments, like in the call above.
This code says: get me a Logger object that is used to log messages coming from NameClass (it's just a convention).
You can even invoke methods on a Class object, such as newInstance(), which is equivalent to calling the default constructor, and will create a new object.
Or print the name of the class:
This is actually Logger.getLogger(Some.class) does: it reads the simple class name, and creates/fetches a Logger object that is configured with that name. In the log configuration, you can then set up filters and formatters based on the class name, for example you can include the class name in each debug message so you know where it originated from.
There are even classes to represent primitive types, for example int.class, and classes to represent arrays of some type, such as int.class or String.class.
So NameClass.class is an object that happens to represent a type, not a 'regular' value such as "John", but it's a proper object, you can pass it as arguments, return it as a result, invoke methods on it, assign it to variables.
Istvan Kovacs wrote:So NameClass.class is an object that happens to represent a type, not a 'regular' value such as "John", but it's a proper object, you can pass it as arguments, return it as a result, invoke methods on it, assign it to variables.
100% correct. It is almost* the same as the return of "new NameClass().getClas()" - an instance of class java.lang.Class. The .class notation is there so you don't need to create a new instance or use reflection (Class.forName) just to get a reference to a Class object.
This could have been done using a static method (e.g. NameClass.getClassObject()) but that caused three problems:
1) this method would need to be generated for each class. The compiler could have taken care of that as it does for enums in Java 5.0 and up (values, valueOf) but it would then be part of the Javadoc of each and every class.
2) the name could not be getClass() because that would clash with the instance method getClass() (hence my ridiculously chosen name).
3) the name could clash with user created methods.
4) static methods are not allowed for interfaces whereas .class is.
Therefore, .class was created. It is automatically generated for each class but it won't show up in the Javadocs. "class" is a keyword so no method or field could ever get the same name so problems 2 and 3 are immediately handled as well.
* Almost because getClass() is polymorphic whereas .class is chosen at compile time. java.util.Date.class is the Class instance for java.util.Date and will never be, for instance, java.sql.Time.class. On the other hand, if I have a reference "Date date" getClass() could return java.sql.Time.class.