According to the definitions of constructors they don't have any return types,but while creating object we often do A a = new A(); which is responsible for creating the object a.
A a=new A();
Can anyone help me understanding the issue,what is actually happening in the case of constructors while creation of Object.
Constructors don't have return types, correct. But the expression new A() does have a result: A reference to the newly-created object.
Here's what happens with new A():
An object is created
It's given the type A
The relevant A constructor is called with this referring to that new object
Once initialization is done, the expression completes
The result of the expression is the reference to the new object
This process is described in this tutorial on the Oracle Java site.
In many ways, it would be more accurate to call constructors initializers: The construction happens because of the new operator, not the constructor.
The fact that constructors don't actually do the construction is made particularly clear when an object is processed by multiple constructors, as is very common. Consider:
List<String> m = new LinkedList<String>();
One object is created (ignoring any fields the list may need to initialize), but five different constructors get called to initialize that one object, because LinkedList<E> subclasses java.util.AbstractSequentialList<E> which subclasses java.util.AbstractList<E> which subclasses java.util.AbstractCollection<E> which subclasses java.lang.Object, and each of those classes has to get its chance to initialize its part of the object that was created. So in order:
JVM creates the object
Object() is called to initialize Object stuff
AbstractCollection() is called to initialize its stuff
Then AbstractList()
Then AbstractSequentialList()
Then LinkedList()
And then finally the resulting (one) object's reference becomes the result of the new expression
One object, but five constructors required to initialize it. :-)
Constructors need not to return anything. They just constructs the current instance. That's all their job, part of object creation.
Creating objects:
A a = new A();
Declaration: The code set in bold are all variable declarations that associate a variable name with an object type.
Instantiation: The new keyword is a Java operator that creates the object.
Initialization: The new operator is followed by a call to a constructor, which initializes the new object.
Constructor declarations look like method declarations—except
that they use the name of the class and have no return type - from
the java constructor docs
To understand the constructor, it is similarly important to understand how it differs from a method.
Constructors have one purpose in life: to initialize the new object and it's fields. Nothing more. The new keyword handles the creation of memory space.
You shouldn't consider new A() to be a call to the constructor, because there are more things that happen, than just the constructor running. The major steps, when you run new A() are these.
A chunk of memory is set aside - just enough for storing an object of class A.
The constructor is run.
A reference to the chunk of memory that was set aside is returned.
So the constructor itself isn't actually returning anything - and it's an error to have return this; or anything similar inside the constructor.
Return statement inside a constructor doesn't logically makes sense because the purpose of the constructor is to perform initialization. The object has not been created yet, the actual construction of the object happens in JVM.
ObjectInputStream.readFields() is eligible only within private void readObject(ObjectInputStream) method.
public ObjectInputStream.GetField readFields() throws IOException, ClassNotFoundException {
SerialCallbackContext ctx = curContext;
if (ctx == null) {
throw new NotActiveException("not in call to readObject");
}
...
I'm in situation when I can't use default serialisation for reading object (i.e. ObjectInputStream.defaultReadObject()) and don't wish to implement readObject() method in all my classes. In ideal case I would like to have ownDefaultReadObject() method that will construct new object from serialized fields (e.g. by reflection).
Any ideas?
If someone would like to know more. Field names in some of my classes were renamed (e.g. by obfuscator) to a, b, c etc. Such classes were serialized with renamed fields using default Java serialization. I need to deserialise them to original classes (I know pairs of field names for each class; a=> fieldName, b=> age, c=>gender etc.).
To rename fields from an object stream, the method you need to override is ObjectInputStream.readClassDescriptor which returns an ObjectStreamClass.
Instances ObjectStreamClass fulfil one of two different roles through large different subsets of the interface. For the avoidance of doubt, this design choice should not be copied.
Describes the fields of a serialisable class running in the current JVM instance. Find these instance through ObjectStreamClass.lookup.
Describes the fields of a serialisable class as represented in a particular serialised stream. These instances are returned by the implementations of ObjectInputStream.readClassDescriptor.
In your override call super.readClassDescriptor. This will read in the data from the stream. Substitute the value from the stream with one having the new fields names, if it's a class you're interested in.
How to create you own ObjectStreamClass? Write dummy instance of the classes you are interested in to an ObjectOutputStream. You can do this as part of the built, just keeping the binary data. Read with another ObjectInputStream with readClassDescriptor overridden to stash the descriptors.
ObjectInputStream.defaultReadObject/readFields wouldn't make any sense outside of readObject (or similar) because they rely on the current deserialising object rather than an argument. There are other limitations to prevent other code calling defaultReadObject to rewrite fields that must remain constant, copied validated, security checked or similar.
I am reading about the specific guidelines that needs to be followed while creating Immutable Class in Effective Java.
I read that In Immutable class method should not allowed to be overridden otherwise overridden method may change the behaviour of method. Following are the design approaches available in java to solve this problem :-
We can mark class final but as per my understanding, it has a one disadvantage that it makes the class inextensible.
Secondly is to make individual methods final but I can not get other disadvantage besides that we need to individually mark each method as final in order to prevent overridding.
As per book,better approach is to make the constructor private or package-private and provide public static factory method for creating object.
My question is: Even if we include private or default constructor in the class, it cannot be extended anymore in same package (in other package in case of package-private constructor), it has a same problem which the first one had. How is it considered as the better approach than the previous ones?
An immutable object should not be extensible. Why?
Because extending it will allow either direct access to fields (if they are protected which would allow writing methods that change them), or adding state which may be mutable.
Imagine we wrote a class FlexiblyRoundableDouble that extends Double, which has an additional field roundingMode that lets us choose a "rounding mode". You could write a setter for this field, and now your object is mutable.
You can argue that if all the methods are set as final, you cannot change the original behavior of the object. The only methods that could access your roundingMode field are new methods that are not polymorphically available if you assign your object to a Double variable. But when a class's contract says that it's immutable, you make decisions based on that. For example, if you write a clone() method or copy constructor for a class that has Double fields, you know that you don't need to deep-copy the Double fields, as they do not change their state, and can therefore be safely shared between the two clones.
Also, you can write methods that return the internal object without fearing that the caller will then change that object. If the object was mutable, you'd have to make a "defensive copy" of it. But if it's immutable, it's safe to return a reference to the actual internal object.
However, what happens if someone assigned a FlexiblyRoundableDouble to one of your Double fields? That object would be mutable. The clone() would assume it isn't, it will be shared between two objects, perhaps even returned by a method. The caller would then be able to cast it back as a FlexiblyRoundableDouble, change the field... and it will affect other objects that use that same instance.
Therefore, immutable objects should be final.
All this has nothing to do with the constructor issue. Objects can be safely immutable with public constructors (as demonstrated by String, Double, Integer and other standard Java immutables). The static factory method is simply a way utilizing the fact that the object is immutable, and several other objects can hold references to it safely, to create fewer objects with the same value.
Providing a static factory method gives you room to implement the Flyweight Pattern.
They're stating that you should hide the possibility of creating a new object using a constructor, and should rather make a call to a method which checks if an object with similar state exists in the "object pool" (a map filled with objects waiting to be re-used). Not re-using immutable objects is a waste of memory; this is why String literals are encouraged, and new String() is shunned (unless needed).
class ImmutableType {
private static final Map<Definition, ImmutableType> POOL = new HashMap<>();
private final Definition definition;
private ImmutableType(Definition def) {
definition = def;
}
public static ImmutableType get(Definition def) {
if(POOL.contains(def))
return POOL.get(def);
else {
ImmutableType obj = new ImmutableType(def);
POOL.put(def, obj);
return obj;
}
}
}
Definition stores the state of the ImmutableType. If a type with the same definition already exists in the pool, then re-use it. Otherwise, create it, add it to the pool then return it as the value.
As for the statement about marking the class final, immutable types should not be extensible in the first place (to avoid possibly modifying behavior). Marking every method final is just crazy for immutable classes.
Why the object of wrapper classes like Boolean etc. direct takes value without initialization but property of object is not allowed?
Code:
class TestByte{
public static void main(String[] a) {
Byte b=125; System.out.println(b);
}
}
do you mean why can you use methods without throwing a NullPointerException from a wrapper class object just by using Byte b = 25 instead of explicitly initializing the Byte object as Byte b = new Byte(25)??
Well, if you DID meant that, its because ever since java 1.5 assigning values to Wrapper references can be done without explicitly instantiating the object. This is called Auto-Boxing, Which implicitly creates the wrapper objects instance and assigns it with the value.
Such that: Byte b = 25 its the same as Byte b = new Byte(25). There are a few differences with the boxing version that influence the result comparing Wrapper values by reference if you assign a value in the range of a byte.. but well that is a whole different thing xD..
Well Abhishek, the purpose of contructors to initialize objects is to do any preparation work to get that object live. Since wrapper classes and String hold only data, the only preparation to inialize them is to provide them necessary values. So, we actually don't need to call new for them.
Had a conversation with a coworker the other day about this.
There's the obvious using a constructor, but what are the other ways there?
There are four different ways to create objects in java:
A. Using new keyword
This is the most common way to create an object in java. Almost 99% of objects are created in this way.
MyObject object = new MyObject();
B. Using Class.forName()
If we know the name of the class & if it has a public default constructor we can create an object in this way.
MyObject object = (MyObject) Class.forName("subin.rnd.MyObject").newInstance();
C. Using clone()
The clone() can be used to create a copy of an existing object.
MyObject anotherObject = new MyObject();
MyObject object = (MyObject) anotherObject.clone();
D. Using object deserialization
Object deserialization is nothing but creating an object from its serialized form.
ObjectInputStream inStream = new ObjectInputStream(anInputStream );
MyObject object = (MyObject) inStream.readObject();
You can read them from here.
There are various ways:
Through Class.newInstance.
Through Constructor.newInstance.
Through deserialisation (uses the no-args constructor of the most derived non-serialisable base class).
Through Object.clone (does not call a constructor).
Through JNI (should call a constructor).
Through any other method that calls a new for you.
I guess you could describe class loading as creating new objects (such as interned Strings).
A literal array as part of the initialisation in a declaration (no constructor for arrays).
The array in a "varargs" (...) method call (no constructor for arrays).
Non-compile time constant string concatenation (happens to produce at least four objects, on a typical implementation).
Causing an exception to be created and thrown by the runtime. For instance throw null; or "".toCharArray()[0].
Oh, and boxing of primitives (unless cached), of course.
JDK8 should have lambdas (essentially concise anonymous inner classes), which are implicitly converted to objects.
For completeness (and Paŭlo Ebermann), there's some syntax with the new keyword as well.
Within the Java language, the only way to create an object is by calling its constructor, be it explicitly or implicitly. Using reflection results in a call to the constructor method, deserialization uses reflection to call the constructor, factory methods wrap the call to the constructor to abstract the actual construction and cloning is similarly a wrapped constructor call.
Yes, you can create objects using reflection. For example, String.class.newInstance() will give you a new empty String object.
There are five different ways to create an object in Java,
1. Using new keyword → constructor get called
Employee emp1 = new Employee();
2. Using newInstance() method of Class → constructor get called
Employee emp2 = (Employee) Class.forName("org.programming.mitra.exercises.Employee")
.newInstance();
It can also be written as
Employee emp2 = Employee.class.newInstance();
3. Using newInstance() method of Constructor → constructor get called
Constructor<Employee> constructor = Employee.class.getConstructor();
Employee emp3 = constructor.newInstance();
4. Using clone() method → no constructor call
Employee emp4 = (Employee) emp3.clone();
5. Using deserialization → no constructor call
ObjectInputStream in = new ObjectInputStream(new FileInputStream("data.obj"));
Employee emp5 = (Employee) in.readObject();
First three methods new keyword and both newInstance() include a constructor call but later two clone and deserialization methods create objects without calling the constructor.
All above methods have different bytecode associated with them, Read Different ways to create objects in Java with Example for examples and more detailed description e.g. bytecode conversion of all these methods.
However one can argue that creating an array or string object is also a way of creating the object but these things are more specific to some classes only and handled directly by JVM, while we can create an object of any class by using these 5 ways.
Cloning and deserialization.
Also you can use
Object myObj = Class.forName("your.cClass").newInstance();
This should be noticed if you are new to java, every object has inherited from Object
protected native Object clone() throws CloneNotSupportedException;
Also, you can de-serialize data into an object. This doesn't go through the class Constructor !
UPDATED : Thanks Tom for pointing that out in your comment ! And Michael also experimented.
It goes through the constructor of the most derived non-serializable superclass.
And when that class has no no-args constructor, a InvalidClassException is thrown upon de-serialization.
Please see Tom's answer for a complete treatment of all cases ;-)
is there any other way of creating an object without using "new" keyword in java
There is a type of object, which can't be constructed by normal instance creation mechanisms (calling constructors): Arrays. Arrays are created with
A[] array = new A[len];
or
A[] array = new A[] { value0, value1, value2 };
As Sean said in a comment, this is syntactically similar to a constructor call and internally it is not much more than allocation and zero-initializing (or initializing with explicit content, in the second case) a memory block, with some header to indicate the type and the length.
When passing arguments to a varargs-method, an array is there created (and filled) implicitly, too.
A fourth way would be
A[] array = (A[]) Array.newInstance(A.class, len);
Of course, cloning and deserializing works here, too.
There are many methods in the Standard API which create arrays, but they all in fact are using one (or more) of these ways.
Other ways if we are being exhaustive.
On the Oracle JVM is Unsafe.allocateInstance() which creates an instance without calling a constructor.
Using byte code manipulation you can add code to anewarray, multianewarray, newarray or new. These can be added using libraries such as ASM or BCEL. A version of bcel is shipped with Oracle's Java. Again this doesn't call a constructor, but you can call a constructor as a seperate call.
Reflection:
someClass.newInstance();
Reflection will also do the job for you.
SomeClass anObj = SomeClass.class.newInstance();
is another way to create a new instance of a class. In this case, you will also need to handle the exceptions that might get thrown.
using the new operator (thus invoking a constructor)
using reflection clazz.newInstance() (which again invokes the constructor). Or by clazz.getConstructor(..).newInstance(..) (again using a constructor, but you can thus choose which one)
To summarize the answer - one main way - by invoking the constructor of the object's class.
Update: Another answer listed two ways that do not involve using a constructor - deseralization and cloning.
There are FIVE different ways to create objects in Java:
1. Using `new` keyword:
This is the most common way to create an object in Java. Almost 99% of objects are created in this way.
MyObject object = new MyObject();//normal way
2. By Using Factory Method:
ClassName ObgRef=ClassName.FactoryMethod();
Example:
RunTime rt=Runtime.getRunTime();//Static Factory Method
3. By Using Cloning Concept:
By using clone(), the clone() can be used to create a copy of an existing object.
MyObjectName anotherObject = new MyObjectName();
MyObjectName object = anotherObjectName.clone();//cloning Object
4. Using `Class.forName()`:
If we know the name of the class & if it has a public default constructor we can create an object in this way.
MyObjectName object = (MyObjectNmae) Class.forName("PackageName.ClassName").newInstance();
Example:
String st=(String)Class.forName("java.lang.String").newInstance();
5. Using object deserialization:
Object deserialization is nothing but creating an object from its serialized form.
ObjectInputStreamName inStream = new ObjectInputStreamName(anInputStream );
MyObjectName object = (MyObjectNmae) inStream.readObject();
You can also clone existing object (if it implements Cloneable).
Foo fooClone = fooOriginal.clone ();
Method 1
Using new keyword. This is the most common way to create an object in java. Almost 99% of objects are created in this way.
Employee object = new Employee();
Method 2
Using Class.forName(). Class.forName() gives you the class object, which is useful for reflection. The methods that this object has are defined by Java, not by the programmer writing the class. They are the same for every class. Calling newInstance() on that gives you an instance of that class (i.e. callingClass.forName("ExampleClass").newInstance() it is equivalent to calling new ExampleClass()), on which you can call the methods that the class defines, access the visible fields etc.
Employee object2 = (Employee) Class.forName(NewEmployee).newInstance();
Class.forName() will always use the ClassLoader of the caller, whereas ClassLoader.loadClass() can specify a different ClassLoader. I believe that Class.forName initializes the loaded class as well, whereas the ClassLoader.loadClass() approach doesn’t do that right away (it’s not initialized until it’s used for the first time).
Another must read:
Java: Thread State Introduction with Example
Simple Java Enum Example
Method 3
Using clone(). The clone() can be used to create a copy of an existing object.
Employee secondObject = new Employee();
Employee object3 = (Employee) secondObject.clone();
Method 4
Using newInstance() method
Object object4 = Employee.class.getClassLoader().loadClass(NewEmployee).newInstance();
Method 5
Using Object Deserialization. Object Deserialization is nothing but creating an object from its serialized form.
// Create Object5
// create a new file with an ObjectOutputStream
FileOutputStream out = new FileOutputStream("");
ObjectOutputStream oout = new ObjectOutputStream(out);
// write something in the file
oout.writeObject(object3);
oout.flush();
// create an ObjectInputStream for the file we created before
ObjectInputStream ois = new ObjectInputStream(new FileInputStream("crunchify.txt"));
Employee object5 = (Employee) ois.readObject();
From an API user perspective, another alternative to constructors are static factory methods (like BigInteger.valueOf()), though for the API author (and technically "for real") the objects are still created using a constructor.
Depends exactly what you mean by create but some other ones are:
Clone method
Deserialization
Reflection (Class.newInstance())
Reflection (Constructor object)
there is also ClassLoader.loadClass(string) but this is not often used.
and if you want to be a total lawyer about it, arrays are technically objects because of an array's .length property. so initializing an array creates an object.
We can create an objects in 5 ways:
by new operator
by reflection (e.g. Class.forName() followed by Class.newInstance())
by factory method
by cloning
by reflection api
We can also create the object in this way:-
String s ="Hello";
Nobody has discuss it.