aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "question" Watch "question" New topic
Author

question

sunil antil
Greenhorn

Joined: Jul 23, 2009
Posts: 20
hi anyone, "A compiler provide a default constructor when no constructor is provided but if we provide any constructor compiler does not provide a constructor why compiler do this"?
Ankit Garg
Sheriff

Joined: Aug 03, 2008
Posts: 9293
    
  17

Hi Sunil, welcome to javaranch.

Please Use A Meaningful Subject Line for your posts.

Every class in Java needs a constructor. So if you don't provide a constructor to your class, the compiler creates one for you for your convinience...


SCJP 6 | SCWCD 5 | Javaranch SCJP FAQ | SCWCD Links
Mo Jay
Ranch Hand

Joined: Feb 16, 2009
Posts: 83
Compiler assumes that since you have provided a constructor for your class then that proves that you know what you are doing and what you really want your constructor to do for you, thus the compiler trust you and thinks that there is no reason for him to provide a default constructor.

Cheers!!
Jason Irwin
Ranch Hand

Joined: Jun 09, 2009
Posts: 327
ANSWER




SCJP6
Himanshu Kansal
Ranch Hand

Joined: Jul 05, 2009
Posts: 257
Also it is a good practice to always give the empty constructor whenever you give a parameterized constructor.

Regards


Experience and talent are independent of age
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14103
    
  16

Himanshu Kansal wrote:Also it is a good practice to always give the empty constructor whenever you give a parameterized constructor.

Really? Why would that be a good practice?


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
Scala Notes - My blog about Scala
Ankit Garg
Sheriff

Joined: Aug 03, 2008
Posts: 9293
    
  17

Himanshu Kansal wrote:Also it is a good practice to always give the empty constructor whenever you give a parameterized constructor.


This is a requirement only if you want your class to be compliant with java beans standards...
Andriy Pererva
Ranch Hand

Joined: Jul 19, 2009
Posts: 73
Also we should provide the default constructor for the reason of declaring it private, and so prohibit the object instantination when it neccessary...


SCJP 6.0(95%), SCWCD 5(94%), SCJD (working on B&S v.2.3.1)
Himanshu Kansal
Ranch Hand

Joined: Jul 05, 2009
Posts: 257
Jesper Young wrote:
Himanshu Kansal wrote:Also it is a good practice to always give the empty constructor whenever you give a parameterized constructor.

Really? Why would that be a good practice?


Because we do not want our application to fail for this reason that at runtime some odd call to the default constructor was made.

Regards

Jason Irwin
Ranch Hand

Joined: Jun 09, 2009
Posts: 327
Himanshu Kansal wrote:Because we do not want our application to fail for this reason that at runtime some odd call to the default constructor was made.

I'm trying to follow that. If I provide a parameterised constructions, there will be no default.
If there is no default constructor and something is trying to call it - surely it wouldn't even compile?
Himanshu Kansal
Ranch Hand

Joined: Jul 05, 2009
Posts: 257
It won't compile if that the compiler gets it while it is compiling. But there can be situations in interactive applications where the conditions come up at run time. The compiler won't be able to play the game then. Sad

We just need to be very sure that such a situation does not arise. If I am sure that nothing of the type is going to happen in my application, I need not care about that extra constructor.

Still, I believe it does no harm in providing an empty constructor and setting the default values for the object... or even do nothing.

Regards
Ankit Garg
Sheriff

Joined: Aug 03, 2008
Posts: 9293
    
  17

Himanshu, if you see the Java IO API, most of the classes used for reading and writing don't have any default constructor. This is because you don't want to create a FileWriter for example, that doesn't point to a file. Also there can't be any default value for the file to which the FileWriter points. So it can't be said that providing a default no-arg constructor is always a good option. It depends on the purpose of the class. If someone is using your class where there is a chance of a run-time exception due to this (like while using reflection), then its the fault of the person who is using your class. Anyone who's using your class or API, must know the use of your classes and what constructor and methods your class provides...
Himanshu Kansal
Ranch Hand

Joined: Jul 05, 2009
Posts: 257
In that case too it would still have been better to have a single object of the writer and use to for a particular file at a moment. For multiple files, the object would remain the same. This can be done with an empty constructor if we have one. Now without an empty constructor... we have to jump b/w references.

The user need not always know what is the structure of my API or what is the API spec. Users can be end/naive users too and not only developers. For making completely generic applications we cannot take this risk of forgetting an empty constructor.

There are a lot of things in the language that need not be there. Take a big example of Interfaces. We can do without them but that would lead to some cumbersome coding. Just to make our lives more streamlined and standardized we got Interfaces.

Just because Sun said or did not say something about Java does not make or prevent it from being a good practice/standard. To err is human and they could have made mistakes.

Regards
Vinayagar Karpagam
Ranch Hand

Joined: Apr 09, 2006
Posts: 72
I'm also not well aware of why putting a default constructor for a bean is a good practice. And I dont know if one such standard exists.
But in some real-time scenarios, a default constructor is absolutely necessary.

For e.g., in case there is a Serializable class which extends a non-serializable class,
the non-serializable parent class must have an empty constructor without which a run-time exception will be thrown during the de-serialization.

But if there is one such practice defined as a standard, it could well relate to the above scenario
since as a bean, it is better to be serializable than not.
Ankit Garg
Sheriff

Joined: Aug 03, 2008
Posts: 9293
    
  17

Himanshu Kansal wrote:In that case too it would still have been better to have a single object of the writer and use to for a particular file at a moment. For multiple files, the object would remain the same. This can be done with an empty constructor if we have one. Now without an empty constructor... we have to jump b/w references.

The user need not always know what is the structure of my API or what is the API spec. Users can be end/naive users too and not only developers. For making completely generic applications we cannot take this risk of forgetting an empty constructor.


First of all I don't understand what you are trying to say as the user of your API being end user and not a developer. How will an end user call the constructor of your class?? And if someone doesn't know the structure of your API, how will they use it. How will anyone call a method on your class if he/she doesn't know what methods are available. You want to create an empty constructor for users who don't know what constructors are available in your class. But if they don't know about the constructors available, then the class is useless to them because they don't know what the class is for and what they can use with the class.

Vinayagar Karpagam wrote:But if there is one such practice defined as a standard, it could well relate to the above scenario since as a bean, it is better to be serializable than not.


Well such a standard is defined for Java Bean compatible classes. A class must declare a no-arg constructor if it follows the java beans standards. But that usually applies to bean classes which store information with getter and setter methods. You'll try to serialize an instance of LivingBeing or a sub-class like Human. But you won't try to serialize an instance of FileWriter or FileReader. So a no-arg constructor is pointless for such a class...
Vinayagar Karpagam
Ranch Hand

Joined: Apr 09, 2006
Posts: 72
Ankit Garg wrote:
But you won't try to serialize an instance of FileWriter or FileReader. So a no-arg constructor is pointless for such a class...


Absolutely.. by its name itself, a bean represents a value holder and FileReader/Writer clearly wouldn't be classified as a bean.
So, I think the "best" practice of adding an empty constructor wouldn't apply for such classes.
Himanshu Kansal
Ranch Hand

Joined: Jul 05, 2009
Posts: 257
ankit garg wrote: First of all I don't understand what you are trying to say as the user of your API being end user and not a developer. How will an end user call the constructor of your class?? And if someone doesn't know the structure of your API, how will they use it. How will anyone call a method on your class if he/she doesn't know what methods are available. You want to create an empty constructor for users who don't know what constructors are available in your class. But if they don't know about the constructors available, then the class is useless to them because they don't know what the class is for and what they can use with the class.

Why are we stuck at a thought that this has to be an API to be used by the developers? Why cannot it be an application developed by a programmer and to be used by the end user where at runtime it would be decided what happens. My end user could be someone who hardly knows anything. My application could be a game where the user tells what to do and I have no control over it. This is the way generic applications work and this is the age of generic applications.

Another simple example: If there's an API where there were some super classes which hardly required constructors but as a "good" programming practice at least 1 constructor should be there, so private constructors were given and now a Java Guru wants to enhance the capabilities by inheritance, what should he do? The API was created by a bad programmer or anything you may assume to your convenience.

If anyone thinks that I am discussing/arguing beyond reason, then we shall stop it here.

Regards

Ankit Garg
Sheriff

Joined: Aug 03, 2008
Posts: 9293
    
  17

Himanshu Kansal wrote:If anyone thinks that I am discussing/arguing beyond reason, then we shall stop it here.


Don't worry, no one's going to think that you are arguing. This is a forum and everyone's free to express their own point of view .

Another simple example: If there's an API where there were some super classes which hardly required constructors but as a "good" programming practice at least 1 constructor should be there, so private constructors were given


I think this example doesn't fit here. Private constructors are a completely different topic. If there's a class which only has parametrized constructor(s), still any class can inherit from it. So a no-arg constructor is not mandatory there too. Anyways I think we are going off the topic as the original question has already been solved ...
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: question