Well, first, by newInstance() method, I am assuming that you are talking about the reflection library? meaning the methods from the Class and Constructor classes? ... In terms of the instance that is created, there is really no difference between using the new operator and the reflection library.
In terms of requirements, the new operator requires that your application knows what it is instantiating at compile time. With the reflection library, this can be determined at run time.
In terms of just using a no-args constructor, the code looks just as simple ... however, reflection can get really complicated with other constructors. Remember that reflection was designed for runtime, so, you will need to obtain the Class instances, create a Constructor instance, obtain the constructor parameter(s) Class types, and of course, the constructor parameters. Additionally, without knowing the class type at compile time, you can't even create the reference variable of that type -- it must be of a super type (or even Object).
raja singh kumar wrote:1. Does anyone have a built-in example of a class which uses newInstance method?
ServiceLoader can be used to load plugins at runtime. Because the class name of the plugin is not known at compile time, ServiceLoader needs to use the newInstance() method to create instances of the plugin. Check out line 380.
2. What is difference between creating an object using new operator and newInstance method?
The new operator requires the type to be known at compile time. It allows the compiler to do some type checking, and the bytecode produced is much more efficient. newInstance() requires you to first load a type dynamically, which might make your application slower at runtime. The upside is that you can use classes that were not known at compile time.
raja singh kumar wrote:Well, do I not know which is the class I need at compile time? Even at compile time I know the code I am writing. So that way I know which class needs to be used at compile time itself rather than run time. Does the person coding the program not know at compile time which class he is trying to use through the code at runtime ?
You seemed shocked by this... ... perhaps, this is because the majority of people who write code know what they are going to write / use as they are coding it. It just seems abnormal to not know what classes you are going to access doesn't it? In fact, I would say that many developers will never encounter a case where they will need the reflection API.
However, there are cases, although really small, where the reflection API is necessary. How do you think the JVM and/or the IDE, finds, loads, and execute your code? Certainly, your classes weren't written when those applications were written? How do you think the JDBC driver manager finds a driver? Or any framework/server that runs any component (based on a configuration file)? etc.
You can create your own classes with newInstance methods. You can get their names as Strings:-
Are you saying the difference between the two is it is easier to create and use objects using newInstance()? Well I read about newInstance() from the official documentation. It mentions that exceptions are handled differently when using newInstance(). Ok, that is one difference. Also, I am also thinking about the question: When should I go for new and when should I go for newInstance().
How do you think the JVM and/or the IDE, finds, loads, and execute your code? Certainly, your classes weren't written when those applications were written?
Well, yeah. That is a basic question which I have never thought about. Why don't you help me? Actually I can use any valid name for the class I am creating. I am sure that JVM must be using something as a placeholder or variable for the class I create. But are you suggesting that newInstance() is useful when we want to load a class as a variable which can be decided on some basis?
So, in what cases do you instantiate a type that you don't know at compile time? I already mentioned plugins. A plugin is a piece of code that is added to a program after the program has been compiled and released. An example:
Let's say that we want to create a calculator application that uses reverse polish notation. It contains an interface that describes operations, and an abstract implementation:
We can create a concrete class that defines addition, and ship it with our application:
Now, imagine that we released the application, but the client wants to add their own operations to the already compiled program. We can support this using service providers:
We add a class that loads operation providers at runtime:
The end user can now create their own library of operations, and add it to the calculator by putting the library on the calculator's classpath when they start the calculator application. All that the library needs is a class that implements OperationProvider, and a configuration file that gives the name of the concrete type of the provider:
Even though the calculator application doesn't know about the existence of MyOperationProvider at compile time, it can still get a concrete instance of it because ServiceLoader internally uses newInstance(), and the name of the concrete type is provided by the configuration file in the META-INF/services directory of the plugin, which is loaded at runtime.
Stephan van Hulst wrote:You should go for new when you know the concrete type you want to instantiate at compile time. You go for newInstance() when you don't know the concrete type at compile time.
I would say that it is easier than that. If the OP is a beginner, then the OP can just assume to use the new operator, in every case. Period.
In those cases, where the new operator doesn't work well, then ... hopefully, the OP would be more experienced to recognize it. After all, this experience would be needed, as the reflection API isn't very simple to use...