Why do we need a default no argument constructor in Java?

Why do we need a default no argument constructor in many Java related APIs? Like as a general rule all java bean classes or entity classes (JPA etc) or JAX-WS implementation classes require a explicit no开发者_开发技巧 argument constructor.

If by default Java provides a no argument constructor then why most of these standards require a explicit constructor?

Java only provides a default no-argument constructor if no other constructors are defined. Thus, if you have other constructors you must explicitly define a no-arg constructor yourself.

These frameworks use the reflection API and look at method names to determine how to set properties. The arguments of a constructor can only be found by type, not by name, so there is no way for the framework to reliably match properties to constructor args. Therefore, they require a no-arg constructor to create the object, then can use the setter methods to initialise the data.

Some frameworks may support @ConstructorProperties as an alternative.

I believe frameworks that require public nullary constructors do so because they use reflection to instantiate types, e.g. through Class.newInstance().

As to why the default constructor may not work for this case, here's the relevant JLS section:

JLS 8.8.9 Default Constructor

If a class contains no constructor declarations, then a default constructor that takes no parameters is automatically provided:

• if the class is declared public, then the default constructor is implicitly given the access modifier public;
• if the class is declared protected, then the default constructor is implicitly given the access modifier protected;
• if the class is declared private, then the default constructor is implicitly given the access modifier private;
• otherwise, the default constructor has the default access implied by no access modifier.

So in a public class, the default constructor would have the right visibility, but otherwise an explicitly public one must be provided.

A constructor is needed to initialise any non-default values and can contain side effects which are needed.

If you have a programing style which encourages a minimal constructor for data transfer objects this would seem unneccasary, but the libraries have chosen not to assume any programming style for the constructors.

You can write a library which doesn't assume a default constructor, but you have to make assumptions about what the constructor would do and wouldn't do. i.e. I have written such libraries but was able to also mandate what a constructor was allowed to do so that not calling it directly was safe.

Java only supplies a no-arg constructor if no other constructor is applied. In a number of Java APIs (e.g. JPA, Serialisation and many others that build objects from an external representation) an instance of the object is required before the data values of the object can be set, as the definition of how the values are applied are defined through instance members of the object (e.g. readExternal(ObjectInput)). If a class only has a constructor that takes some arguments then it may not be possible for the library to construct an instance unless a separate no-arg constructor is defined.

It is worth noting that this is a design choice by the implementer of the particular library, it is possible to build an API/Framework that can externalise and recreate objects that don't have a no-arg constructor (defining a separate factory class is one approach). The pattern of requiring a no-arg constructor turned up first in Java Serialisation (I think) and has been adopted as the de-facto standard approach on other libraries (e.g. JPA). The weakness of this approach is that it prevents the use of immutable objects.

Two reasons: 1) to avoid NullPointerException if an instance data field of a reference data type is uninitialized. Providing an explicit constructor would give you the chance to initialize such data fields, if they have not been initialized when declared 2) for users who would like to use no-arg constructors; these are not automatically provided if other constructors exist

Many of these frameworks derive from the earlier ideas of "POJO" and especially JavaBeans. The smallest useful Java Object would, by convention, have a no-arg constructor and every member accessible through methods like get/setProperty1 and is/setProperty1 for booleans. If Classes follow that convention of the interface, tools and frameworks using reflection can work 'out of the box'.

Default No-Argument constructor provides default values to the object like 0 or null, hence it is mandatory in java coding.