The way I understand it, Java object model is 3 levels, each level describes the level beneath it, therefore there is one Meta class shared by all Classes (which are themselves objects?).
My question is - how are constructors implemented in Java? (or any other class methods) my logic says that constructors should appear in the Meta classes, but since there is only one Meta class, it doesn't make any sense that it keeps all possible constructors, or is my understanding of this is all wrong..
In Java there's a single metaclass: the instances of the class Class are used to represent the types of classes and interfaces. The constructors are defined at the class level, not at the metaclass level.
Your question targets nothing special about constructors: From the point of describing classes on a metalevel there is the same concept for constructors, "normal methods" and fields.
So think of it this way:
Each class in Java is described by a certain set of informations:
Name of the class
the superclass
the implemented interfaces
a list of constructors and their signatures
a list of (static and non-static) methods and their signatures
a list of (static and non-static) fields and their types
For your convenience this information is available to you during runtime - this is the "reflection API".
Since the same type of information is available for each class loaded by the JVM, this is bundled in a own class named java.lang.Class.
So one instance of the class Class describes the class java.lang.String, another instance of Class describes my.own.class.Foo.
java.lang.Class itself is of course also a class - therefore there also exists an instance of Class describing the class Class. And I think that's where things get recursive somehow.
Summary: There is only one metaclass: java.lang.Class. Multiple instances (meta-instance?) of the metaclass describe individual classes - including the metaclass itself. Constructor descriptions are part of the instances of the metaclass.
I read that "A metaclass is the class of a class. Like a class defines how an instance of the class behaves, a metaclass defines how a class behaves. A class is an instance of a metaclass."
I was wondering how different this is from interface in Java. interface too provides a blueprint for the classes to follow.
No.
About Python Metaclass:
Metaclass in Python is a class which is used to create classes. A class that you create in Python is simply an instance of its metaclass. type is the super most metaclass in Python.
In Python, a class is modeled as an object, which gives you a lot of flexibility in its usage, by attaching all the properties of objects to classes. For example, you can even create class definition dynamically, just the way you would create an instance of a class.
This is a good read.
About Interfaces in Java:
First of all, an interface is not a class. It is just another type (Both interfaces and classes are types in Java). It is true that classes and interfaces are closely related in Java (An interface is a blueprint of a class). But they are entirely different types. Interface in java is simply a mechanism to achieve abstraction.
Conclusion: In Python, you really don't have anything like java interface.
I have been programming in Java for quite some time, but when I tried to explain what an java.lang.Object class is to a friend, I could not come up with more than a simple one-liner:
All objects in Java extend java.lang.Object implicitly
I was not quite sure why it should do so.
So, I looked upon the source code on GrepCode, hoping that I can find some clues. Now I know what a java.lang.Object is and what it does, I want to know if there was any specific reason as to why it was designed this way.
My question still prevails: why should every object extend java.lang.Object?
I would say that the reason is to have a common API for all objects in java to supports basic functionality like
synchronization - wait, notify, notifyAll
garbage collection - finalize
collection support - hashCode, equals
object cloning - clone
And every object
has a class it belongs to - getClass
can represent itself as a string, because we are
humans and can read strings - toString
I think the most important use of Object is not to provide common methods like toString() but to provide a common type that would hold all reference types.
C++ don't have an Object equivalent and people are still happy. But since Java don't have pointers and C++-like templates, Object is required to make implementations of Collections, etc. possible.
See also on discussions on reference and primitive types.
This is how the language is designed. Every object will inherit from the base class Object. This means that it's guaranteed for every object there will be certain methods, like toString(), equals(), hashCode(), etc.
I would say Design. Common/Mandatory methods which every Object should support written there and extending that class as a language specification.
You find the reasons here in Official Docs.
If we are saying this is an Object ,They must have the common methods, Which defined/decided by API.
Imagine the below methods for every class on your Own.
protected Object clone() throws CloneNotSupportedException
Creates and returns a copy of this object.
public boolean equals(Object obj)
Indicates whether some other object is "equal to" this one.
protected void finalize() throws Throwable
Called by the garbage collector on an object when garbage
collection determines that there are no more references to the object
public final Class getClass()
Returns the runtime class of an object.
public int hashCode()
Returns a hash code value for the object.
public String toString()
Returns a string representation of the object.
The notify, notifyAll, and wait methods of Object all play a part in synchronizing the activities of independently running threads in a program:
public final void notify()
public final void notifyAll()
public final void wait()
public final void wait(long timeout)
public final void wait(long timeout, int nanos)
So to reduce the pain, created a common and standard API.
Every Class extends Object class implicitly so that they provide basic features which according to Java recommendation every class should have. Such as clone(), equals(), hashCode(), toString(), etc.
By implicitly, it means that if you are not extending any class then only compiler will implicitly extends Object class.But if class already extends other class then compiler will not extend Object class. For eg.
Class A{
}
Class B extends A{
}
Here compiler will implicitly add extends Object class in class A declaration.
Class A extends Object{
}
Class B extends A{
}
As class A extends Object class so it will provide basic functionality of Object class such as equals(), toString(),etc. And since Class B extends class A which implicitly extends Class Object, so class B also provides all those features.
Thus by following this approach every class objects(variables) complies to features which every Java Object should have, without going for Multiple Inheritance (a class extending more than one class) which Java doesn't allows. This approach follows Multi-Level Inheritance.
This is done so as most of the basic functions like toString() etc would be automatically inherited and to your next question this is NOT multiple inheritence it is multilevel inheritence...
In multiple inheritence single class is derived from 2 or more base class whereas in multilevel as you have said it has a base class which is itself derived from Object class
Quoting Head first Java 2nd edition:
Without a common superclass for everything in Java, there’d be no way
for the developers of Java to create classes with methods that could
take your custom types... types they never knew about when they wrote
the ArrayList class.
Which essentially explains the need of a generic predefined class type in Java, which can be used to implement the different features provided by the language.
See the docs:
The Object class, in the java.lang package, sits at the top of the
class hierarchy tree. Every class is a descendant, direct or indirect,
of the Object class. Every class you use or write inherits the
instance methods of Object. You need not use any of these methods,
but, if you choose to do so, you may need to override them with code
that is specific to your class.
The Object class simply defines the basic state that all objects must have - Like comparing it to other objects.
It's the parent class of everything. It simply provides kind of template to all the derived objects.
It's a java design decision. It puts to use the concept of inheritance and re-usabilty. This ensures that all classes have some basic methods like wait(), toString() etc.
Object class is the most super class of java programming, It has predefined methods according to types, you can use those methods. & you don't need to extends object class anymore & anywhere it's implicitly there
Every class in Java is a descendent (direct or indirect) of the Object class. The Object class defines the basic state and behavior that all objects must have, such as the ability to compare oneself to another object, to convert to a string, to wait on a condition variable, to notify other objects that a condition variable has changed, and to return the object's class.
I'm building a small Android application, but this is more of a Java question than an android question. Looking through the tutorials there are lines that look like:
startService(new Intent(this, MyService.class));
what exactly does the "MyService.class" field represent? Is that just a reference to the class for a template?
Thanks.
Andy's answer is definitely correct, but I want to expand on the point a little.
.class is a special syntax for obtaining an instance of a Class object. It can be used when only the type is available and no instance of the related object is around. It can be used with any concrete type name, including arrays and primitives. For instance, int.class is valid.
This way (and other ways) to get a Class object are documented in the old Sun reflection API docs.
The special .class syntax often appears in idiomatic usage as a "type token" in generic code. A class literal obtained with .class is called a type token when "passed among methods to communicate both compile-time and runtime type information" (Joshua Bloch's Effective Java 2e, p. 142).
Yes, MyService.class returns a Class object that represents the class MyService. The Intent uses it to identify which Service or Activity you're intending to start.
The MyService.class allows you to get the Class object describing the MyClass class, from the class name alone (as opposed to have an instance of the class to ask for object.getClass()).
In JVM, when a class is loaded, an object of the type Class represents the loaded class in memory. com.abc.MyClass.class is a literal expression that represents the Class object for the class com.abc.MyClass.
The same Class object can also be obtained by calling myClassReference.getClass() method if you have a reference to an object of the class.
The Class object can be used to find the information on the structure of the class, access fields, invoke methods and instantiate objects of the class using Java Reflection API.
I need to do some refactoring in Java, and I need to maintain some degree of binary compatibility. In this case I want to remove some legacy interfaces, that are not used anywhere anymore and which require a rather big (and also deprecated) external dependency.
I have class C that implements interface I, and I have code that calls a method (declared in the interface) on an instance of C. The calling code knows that it is using C, not just the interface.
class C implements I {
void theMethod(){} ; // is declared in the interface I
}
C object;
object.theMethod();
When I remove the interface from the class definition (but keep all the methods), will the calling code (which does not refer to the interface at all) still work (without a recompile)?
Yes, it will work - as long as it doesn't explicitly refer to interface I anywhere.
From JLS: Resolution of Symbolic References:
The binary representation of a class
or interface references other classes
and interfaces and their fields,
methods, and constructors
symbolically, using the binary names
(§13.1) of the other classes and
interfaces
Class ClientClass referring to field / method of class C contains no implicit references to interface I that class may implement.
It works as long as an object of class C is never referred to as I.
You can also refer to Evolving Java-based APIs part 2.
You might have a problem with the calling Code if it imports the Interface anywhere. If there is no import of the interface in any of the calling code, you can be reasonably confident that your refactoring will work as planned.