What is the difference between class and type.

[Marc Twain]

I apologize for what must be an absolutely silly question, but:

What is the difference between class and type? I see books referring
to both interchangeably. I though that type meant 'primitive type' and
class for the 'reference types' like objects. Obviously I am
completely wrong.

I looked online quite a bit for that answer but couldn't find a
document detailing what the exact difference is.

TIA,

Mark

 

[Bjorn Abelli]

"Marc Twain" ...

What is the difference between class and type?

The answers you'll get will surely differ depending on who answers your
question...

I see books referring
to both interchangeably.

And some argue that they'e synonyms...

I though that type meant 'primitive type' and
class for the 'reference types' like objects.

And that answer will surely be one...

Obviously I am
completely wrong.

I looked online quite a bit for that answer but
couldn't find a document detailing what the exact
difference is.

In my opinion the most semantically correct answer should be that the
concept of "type" itself is an abstraction, such as it can be either a
"value type" or a "reference type".

In other languages than Java, they actually have classified it in this way,
with "Type" as the most general abstraction, with "value types" and
"reference types" as subtypes of the general type.

Value types in turn can be of different kinds, such as the "primitive"
types, but some languages also allows you to construct "compound types" that
can be mixed up with classes. Reference types can also have different
constructions, such as "class" as one and some would consider arrays as
another.

So my simple answer would be that a "type" is whatever type you can assign
as a type to a variable, which includes both "value types" and "reference
types". In Java as in many other languages, a type would hence be anything
you can write instead of X in the following line:

X myVariable;

// Bjorn A

 

[Joona I Palaste]

I apologize for what must be an absolutely silly question, but:

What is the difference between class and type? I see books referring
to both interchangeably. I though that type meant 'primitive type' and
class for the 'reference types' like objects. Obviously I am
completely wrong.

I looked online quite a bit for that answer but couldn't find a
document detailing what the exact difference is.

Simple. Objects have classes, values have types. In Java, a value can
be either a primitive (sort-of like a scalar) or a reference to an
object. The former is what is meant by "primitive type" and the latter
is what is meant by "reference type".
The type of a value that refers to an object must be a reference to
the class of the object, or to any superclass of the class of the
object. An object's class can never change, but the types of the values
referring to it can.

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"It's time, it's time, it's time to dump the slime!"
- Dr. Dante

 

[Chris Smith]

I apologize for what must be an absolutely silly question, but:

What is the difference between class and type? I see books referring
to both interchangeably. I though that type meant 'primitive type' and
class for the 'reference types' like objects. Obviously I am
completely wrong.

Though the terms don't have universal definitions, that is not the
common usage within Java. Primitive and reference types are both types,
and "class" describes the actual form of an object (which is not a
variable at all).

The primary difference is that "type" is a compile-time concept. Except
for a brief interlude of bytecode verification and the reflection API
(which can be seen as echos of the source language from a compiler
standpoint, in a sense), it's lost in the actual application at runtime.
The class of an object, though, exists and is important at runtime,
primarily in polymorphism, and in the behavior of casting operations.

Perhaps this will make it clear. In the expression:

Object a = new Date();
String s = a.toString();

The *type* of the variable 'a' is Object (which is actually a type
notation in Java source code meaning a *reference* to an Object), but
the *class* of the object it points to is Date. The type (Object) only
affects what code is valid according to the compiler's type-checking,
but *not* what the code actually does. The class of the object affects
what the code does, so that the a.toString() call in the second line
returns a String that looks like a Date, not one that looks like
"java.lang.Object@XXXXXXXX".

HTH,

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Dale King]

Though the terms don't have universal definitions, that is not the
common usage within Java. Primitive and reference types are both types,
and "class" describes the actual form of an object (which is not a
variable at all).

The JLS has a section describing this.

http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html#
24887

 

[Marc Twain]

Thank a lot - very informative indeed!

 

[Michael Borgwardt]

Perhaps this will make it clear. In the expression:

Object a = new Date();
String s = a.toString();

The *type* of the variable 'a' is Object (which is actually a type
notation in Java source code meaning a *reference* to an Object), but
the *class* of the object it points to is Date. The type (Object) only
affects what code is valid according to the compiler's type-checking,
but *not* what the code actually does.

That's not entirely true - with static members accessed through a reference
as well as with the parameters of overloaded methods, binding is done at
compile-time and the declared type of the reference actually determines
what code is called.

 

[Chris Smith]

That's not entirely true - with static members accessed through a reference
as well as with the parameters of overloaded methods, binding is done at
compile-time and the declared type of the reference actually determines
what code is called.

Right. Some of us like to pretend that this particular language blunder
doesn't exist. Whenever I see code that uses static class members
through a reference, I change it so that it no longer does so.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Michael Borgwardt]

Right. Some of us like to pretend that this particular language blunder
doesn't exist. Whenever I see code that uses static class members
through a reference, I change it so that it no longer does so.

I agree with that sentiment, but I'm not as sure about overloaded
methods. It can make *sense* to have a method overloaded to handle Objects
in general and particular classes specially.

 

[Jon Skeet]

I agree with that sentiment, but I'm not as sure about overloaded
methods. It can make *sense* to have a method overloaded to handle Objects
in general and particular classes specially.

I'm not sure I see what you mean. Are you talking about the situation
where a class has:

static void foo()

static void foo(int)

void foo(String)

- are you saying you'd still invoke

myVariable.foo() instead of ClassName.foo()? If so, I'd certainly
disagree.

Fortunately Eclipse provides a nice warning for this, so I can easily
avoid it.

 

[Chris Smith]

I'm not sure I see what you mean. Are you talking about the situation
where a class has:

static void foo()

static void foo(int)

void foo(String)

- are you saying you'd still invoke

myVariable.foo() instead of ClassName.foo()? If so, I'd certainly
disagree.

I would too. However, I think Michael is talking about the general
concept that methods are chosen based on types in an overload scenario.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Michael Borgwardt]

I'm not sure I see what you mean. Are you talking about the situation
where a class has:

static void foo()

static void foo(int)

void foo(String)

- are you saying you'd still invoke

myVariable.foo() instead of ClassName.foo()?

No, I mean this:

public void print(Object obj)
public void print(String s)

as seen e.g. in java.io.PrintWriter

Any call to the print() method is bound at compile time using the
declared type of the parameter reference. And it makes sense to do
it that way.

 

[Jon Skeet]

No, I mean this:

public void print(Object obj)
public void print(String s)

as seen e.g. in java.io.PrintWriter

Any call to the print() method is bound at compile time using the
declared type of the parameter reference. And it makes sense to do
it that way.

Ah, right - yes, agreed in all respects.

 

[Roedy Green]

Ah, right - yes, agreed in all respects.

There is a discussion in .advocacy about Nice which does the matching
at run time so that if your Object reference were actually a String,
it would use the String variant of print. Java selects which parameter
variant method of a class at compile time, and which overridden
version at run time.

 

[Dale King]

Right. Some of us like to pretend that this particular language blunder
doesn't exist. Whenever I see code that uses static class members
through a reference, I change it so that it no longer does so.

And if you use Eclipse you can set it to generate a warning or error for
doing this. They are even improving it in 3.0 to get rid of some loopholes
that aren't caught currently.

 

[Joona I Palaste]

Right. Some of us like to pretend that this particular language blunder
doesn't exist. Whenever I see code that uses static class members
through a reference, I change it so that it no longer does so.

I agree completely. Calling static methods from instance references
must have been a "feature" that Sun decided to include just because
some engineer saw that there was no *technical* reason why it shouldn't
work, and thought "gee whiz golly", and introduced it for fun.
It only confuses the Java programmer, regardless of his/her
experience. I know Java isn't as pure an OO language as I would like it
to be, but this, this is gratuitous impurity. It should be abolished if
at all possible.

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"C++. C++ run. Run, ++, run."
- JIPsoft