Why can I not use: Math a=new Math();

[chirs]

Hi,

Why cannot I use this stmt: Math a=new Math(); The Java document does
not say I cannot use it.

Thanks.

 

[Gordon Beaton]

Why cannot I use this stmt: Math a=new Math(); The Java document
does not say I cannot use it.

Because it doesn't have any public constructors.

Anyway it only has static methods. Why you you think you need to
create a new instance?

/gordon

 

[Rob]

It has a private constructor, so no one can instantiate it. This comes from
the actual Math source:

/**
* Don't let anyone instantiate this class.
*/
private Math() {}

All of the methods in Math are static. Therefore, (1) you should never have
a need to instantiate it (there is no instance information), and (2) you
should use the "Math.methodName()" convention when calling any of its static
methods (since they are all "Class" methods -- not "Instance" methods).

For example:

double myLog = Math.log(anExampleDouble);

Good luck,
Rob

 

[Marco Schmidt]

chirs:

Why cannot I use this stmt: Math a=new Math(); The Java document does
not say I cannot use it.

Sure you can use it, you just can't create a Math object because there
is no public constructor. But you don't need one anyway because Math
only contains static methods. So you can use Math like that:

double x = 1.2;
double y = Math.sin(x);

Regards,
Marco

 

[George W. Cherry]

Hi,

Why cannot I use this stmt: Math a=new Math(); The Java document does
not say I cannot use it.

What's you gonna do with a if you could
do what you can't do? In other words,
an instance of a class with all static members
ain't gonna be very useful.

George

 

[Dale King]

What's you gonna do with a if you could
do what you can't do? In other words,
an instance of a class with all static members
ain't gonna be very useful.

I've actually thought about this subject a lot. I even thought of proposing
to Sun that instead of using the convention that you add a private
constructor that instead you could declare the class both abstract and
final, which would eliminate any possibility of creating an instance.

But then I began to ask myself what is the actual problem I am trying to
prevent. Who cares if someone actually creates an instance of an object that
has no instance fields or methods other than those in Object? It doesn't
cause any harm so why take any deliberate steps to prevent it? So I settled
on just not declaring a constructor. If someone wants to use the default
constructor I didn't feel a need to prevent that.

But I am beginning to change my mind and the reason is that I am starting to
use test coverage tools and they report that default constructor as not
having been executed. I don't have a test for it and it seems silly to add a
test to check if it has the default constructor when there is no purpose to
having a constructor on this class. If I switch to a private constructor the
situation is worse because then there is no way to even write a test that
will exercise it. I'm thinking about switching to the convention of
declaring a public constructor that throws an exception. If the class does
that then it makes sense to test for that and then I get my coverage up to
100%.

 

[Daniel Chirillo]

You're also thinking "inorrectly". The javadocs don't (necessarily) tell
you what you "can't" use; they tell you what you *can* use.

 

[Chris Smith]

But I am beginning to change my mind and the reason is that I am starting to
use test coverage tools and they report that default constructor as not
having been executed. I don't have a test for it and it seems silly to add a
test to check if it has the default constructor when there is no purpose to
having a constructor on this class. If I switch to a private constructor the
situation is worse because then there is no way to even write a test that
will exercise it. I'm thinking about switching to the convention of
declaring a public constructor that throws an exception. If the class does
that then it makes sense to test for that and then I get my coverage up to
100%.

Does your test coverage tool complain about untested private
constructors? That seems a little odd.

In any case, the deciding factor for me is that if the interface
includes a public constructor, that implies that it's intended to be
used. Tools that document interfaces (particularly JavaDoc) will not
forget to include it, and that creates misleading documentation. It's a
matter of cleanliness and attention to detail, for me, to declare a
private constructor in those cases.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Dale King]

Does your test coverage tool complain about untested private
constructors? That seems a little odd.

Unfortunately, yes. It's the GPL edition of JCoverage. It's not meant to be
a full blown coverage tool and is more of an advertisement for their
commercial tools.

For this and other reasons I've been looking for alternative free coverage
tools. Clover is available for open source projects, but did not work well
for me, reporting most of my class as unexercised. I'm thinking of joining
or modifying an open source project to get teh coverage tool I want. One of
the features that I really want in a coverage tool is the ability to declare
a piece of code unreachable so that is not included in the total, BUT if it
ever does get executed it should be indicated as an error.

In any case, the deciding factor for me is that if the interface
includes a public constructor, that implies that it's intended to be
used. Tools that document interfaces (particularly JavaDoc) will not
forget to include it, and that creates misleading documentation. It's a
matter of cleanliness and attention to detail, for me, to declare a
private constructor in those cases.

Yeah, I know. I've actually been stewing over this for a week. The
documentation for the constructor would tell you that it will throw an error
if you call it. And as I said I am considering writing or modifying a
coverage tool to work the way I want.

 

[Scott Ellsworth]

Unfortunately, yes. It's the GPL edition of JCoverage. It's not meant to be
a full blown coverage tool and is more of an advertisement for their
commercial tools.

For this and other reasons I've been looking for alternative free coverage
tools. Clover is available for open source projects, but did not work well
for me, reporting most of my class as unexercised. I'm thinking of joining
or modifying an open source project to get teh coverage tool I want. One of
the features that I really want in a coverage tool is the ability to declare
a piece of code unreachable so that is not included in the total, BUT if it
ever does get executed it should be indicated as an error.

Check out groboutils. I have had good luck with it, and it is a truly
open source project that others can contribute to.

I did notice a dramatic slowdown when I started using log4j with it, but
I have not had a chance to track down why as yet. I did not see this
with java.util.logging.

Scott
(e-mail address removed)
Java, Cocoa, and database persistence consulting for the life sciences

 

[TT \(Tom Tempelaere\)]

I've actually thought about this subject a lot. I even thought of proposing
to Sun that instead of using the convention that you add a private
constructor that instead you could declare the class both abstract and
final, which would eliminate any possibility of creating an instance.

But then I began to ask myself what is the actual problem I am trying to
prevent. Who cares if someone actually creates an instance of an object that
has no instance fields or methods other than those in Object? It doesn't
cause any harm so why take any deliberate steps to prevent it? So I settled
on just not declaring a constructor. If someone wants to use the default
constructor I didn't feel a need to prevent that.

But I am beginning to change my mind and the reason is that I am starting to
use test coverage tools and they report that default constructor as not
having been executed. I don't have a test for it and it seems silly to add a
test to check if it has the default constructor when there is no purpose to
having a constructor on this class. If I switch to a private constructor the
situation is worse because then there is no way to even write a test that
will exercise it. I'm thinking about switching to the convention of
declaring a public constructor that throws an exception. If the class does
that then it makes sense to test for that and then I get my coverage up to
100%.

Pardon me for C++ background, but I think a namespace-concept would fit in
nice. The namespace could be compared to a class with all statics, and that
cannot be instantiated (by using private constructor).

namespace Math {
// all definitions are static by nature
// the rest is comparable
}

So instead of pulling in more keywords to define the class, why not invent a
new concept that does exactly what you need? What is done for class Math is
pure workaround imho. But I wouldn't use the full C++ meaning and usage of
namespaces. That wouldn't fit the Java language. Namespace would just be
used for Math and other pure 'static' classes. Clients wouldn't need
recompile (if changed to namespace concept), the syntax stays the same.

 

[chirs]

Because it doesn't have any public constructors.

Anyway it only has static methods. Why you you think you need to
create a new instance?

/gordon

I just want to understand the syntax. If it does not have a
constructor, it should use the Object's constructor which is the super
class, is it?

Thanks.

 

[Sudsy]

chirs wrote:

I just want to understand the syntax. If it does not have a
constructor, it should use the Object's constructor which is the super
class, is it?

Please go back and re-read the responses to your original post.
java.lang.Math doesn't have a constructor; you can't instantiate
it. You just use the class static methods.

 

[chirs]

chirs wrote:


Please go back and re-read the responses to your original post.
java.lang.Math doesn't have a constructor; you can't instantiate
it. You just use the class static methods.

I tried a class without a constructor. It did not give me any
problem. You can try it.

import java.awt.Point;
public class MyRect {
int x,y,x0,y0;

MyRect build(int a, int b, int c, int d){
x=a;
y=b;
x0=c;
y0=d;
return this;
}

public static void main(String[] args) {
MyRect rect=new MyRect(); //It did not give me any problem
rect.build(10,10,100,100);
System.out.print(rect.x);
}
}

 

[Christophe Vanfleteren]

chirs wrote:


Please go back and re-read the responses to your original post.
java.lang.Math doesn't have a constructor; you can't instantiate
it. You just use the class static methods.

I tried a class without a constructor. It did not give me any
problem. You can try it.

import java.awt.Point;
public class MyRect {
int x,y,x0,y0;

MyRect build(int a, int b, int c, int d){
x=a;
y=b;
x0=c;
y0=d;
return this;
}

public static void main(String[] args) {
MyRect rect=new MyRect(); //It did not give me any problem
rect.build(10,10,100,100);
System.out.print(rect.x);
}
}

But you *do* have a constructor in MyRect, you just didn't define it
explicitly.

That is because the compiler adds a so called "default constructor" behind
your back if you do not define any constructor. A default constructor is a
constructor that doesn't accept any arguments.

That is also why you need to add a private constructor if you don't want
your class to be instantiated, otherwise the compiler would add a public
default constructor.

 

[Sudsy]

chirs wrote:

I tried a class without a constructor. It did not give me any
problem. You can try it.

If you don't specify ANY constructors then Java will build a default
(no argument) constructor for you. Isn't that nice?

 

[Chris Uppal]

If you don't specify ANY constructors then Java will build a default
(no argument) constructor for you. Isn't that nice?

Does JavaDoc generate documentation for implicitly created constructors ? I
admit I'm feeling too lazy this AM to check for myself. But if my memory is
correct then it doesn't, and (if so) then that would make it a little difficult
to tell from the JavaDoc whether a class has a constructor or not.

-- chris

 

[Sudsy]

Chris Uppal wrote:

Does JavaDoc generate documentation for implicitly created constructors ? I
admit I'm feeling too lazy this AM to check for myself. But if my memory is
correct then it doesn't, and (if so) then that would make it a little difficult
to tell from the JavaDoc whether a class has a constructor or not.

I just tested that and javadoc DOES include the default constructor.
No details, but then you wouldn't expect them...

 

[Chris Uppal]

I just tested that and javadoc DOES include the default constructor.

Thank you, I lounge corrected.

No details, but then you wouldn't expect them...

;-)

-- chris