some personal rambling on java the lang

[projectmoon]

C# has evolved to become a much bigger language than Java, and
significantly different, e.g. the two took very different approaches to
generics. But C# 1.0 was very much Java with slightly different syntax,
and a few added bits of syntactic sugar (events, delegates, stc.)

I think a lot of this stems from the fact that Microsoft took their JVM
and used it as the basis of the .NET runtime.

 

[projectmoon]

Moreover, the .NET CLR was not a copy of the JVM ... it evolved from a
fusion of COM with the managed environments of Visual Basic and Foxpro
(all of which predate Java). Microsoft's IL byte code evolved from the
Visual Basic pcode engine which itself evolved from prior versions going
back at least to 1985 and Microsoft C 3.0. [I can't locate a cite for
the introduction of the M$ pcode compiler, but I know from personal
experience with C 3.0 in 1987 that some version of it was included.
What I remember most about it was that there was absolutely no floating
point support.]

There is little doubt that there was cross pollination of CLR from the
MSJVM which was an incompatibly extended 1.0 JVM that Sun sued to
exterminate. But feature and implementation wise, CLR and JVM were
going in parallel but different paths almost from the start.
[Similarities between the JDK and .NET programming frameworks are for a
different discussion.]

I did not actually know this. Is there a source for this? All I've ever
heard is that that .NET runtime began as a modified MS JVM.

 

[George Neuner]

Moreover, the .NET CLR was not a copy of the JVM ... it evolved from a
fusion of COM with the managed environments of Visual Basic and Foxpro
(all of which predate Java). Microsoft's IL byte code evolved from the
Visual Basic pcode engine which itself evolved from prior versions going
back at least to 1985 and Microsoft C 3.0. [I can't locate a cite for
the introduction of the M$ pcode compiler, but I know from personal
experience with C 3.0 in 1987 that some version of it was included.
What I remember most about it was that there was absolutely no floating
point support.]

There is little doubt that there was cross pollination of CLR from the
MSJVM which was an incompatibly extended 1.0 JVM that Sun sued to
exterminate. But feature and implementation wise, CLR and JVM were
going in parallel but different paths almost from the start.
[Similarities between the JDK and .NET programming frameworks are for a
different discussion.]

I did not actually know this. Is there a source for this? All I've ever
heard is that that .NET runtime began as a modified MS JVM.

Much of it is documented, but I'm afraid it is spread through decades
of whitepapers, product release, developer and technical notes. If
you have access to some old versions of M$ developer tools and SDKs,
you should be able to find some of it.

Some history you can probably glean by searching MSDN. Searching
"p-code", for example, you'll find - eventually - articles on QBasic,
debugging p-code executables in DOS 4 and how to get VB2 to make
p-code OLE DLLs for Windows 3.1 (all of which predate the first
release of JVM).

The only non-M$ source I'm aware of is in Kevin Burton's book:
".NET Common Language Runtime - Unleashed".
The first chapter talks some about the evolution of COM into CLR and
discusses the goals of the various intermediate projects - which IMO
pretty clearly demonstrates that CLR had different goals than JVM from
the start. Burton doesn't really establish a clear time line for the
history, but he does touch briefly on most of the salient points.
There are other interesting tidbits scattered through the book.
[It's a 1000 page book so don't buy it for a history lesson ... but
despite the age (2002), IMO it's still one of the best introductions
into .NET development.]

Sorry I can't just point you to a URL.
George

 

[Joshua Maurice]

I believe that is the only way to pass parameters in Python - by
"value of a reference".




You can't increment/decrement them and you can't assign an arbitrary
memory location (including invalid memory locations) as you can C/C++
pointers. They can only "point" to controlled areas of memory where an
object of a specific type exists. They aren't the same as C/C++
pointers which I think is why they didn't call them pointers.

This is an often misunderstood aspect of C and C++. Attempting any
kind of "unorthodox" pointer cast or pointer arithmetic results in
undefined behavior. You're not allowed to have a pointer pointing to a
sufficiently different type and dereference (with some small
exceptions).

C and C++ could very well have the full bounds check, type checking,
etc., of Java. It's not required by the language standards, but it's
allowed, whereas Java requires it. The C and C++ standards are in
terms of an abstract machine, so there is no requirement that a C
pointer be an actual hardware memory address. It's just that the most
common implementation of C and C++ is that pointers are raw memory
addresses of the underlying hardware (as this is consistent with the
general design goals of C and C++).

However, as evidenced by "NullPointerException" and well known facts
of JVM implementations, this is also the common and intended
implementation technique for Java. Each Java reference is commonly
just a hardware memory location, though it's not required to be so. At
the compiler level, pointer arithmetic is simply disallowed whereas in
C and C++ it is allowed, but "bad use" results in undefined behavior.

But I
have no idea why they used NullPointerException instead of
NullReferenceException.

I would surmise that's because the expected underlying implementation
technique is the same as C pointers, and because Java references were
modeled after C pointers.

I still say that Java was intended to be a "better" or "safer", and
more portable, C++, and many of its ideas were directly taken from C
and C++, though greatly modified since then to meet Java's new design
goals. Java's syntax is an obvious derivation of C and C++, and its
closest past relatives are C and C++, so again to purposefully
conflate and confuse these two pre-existing terms is a disservice.

 

[Joshua Maurice]

Java references are indeed different from C/C++ pointers. They have more
in common with Pascal pointer types.

While I dispute the claim that Java references are "very" different
from C and C++ pointers, I can continue from what you just said to
again conclude that Java did a disservice by using the term
"reference" instead of the well known term "pointer".

 

[MarkHaniford]

This month, my Java tutorial become quite popular. Here's the most
popular pages, with number of page views in the past 30 days.

The “static” Keyword In Java   5.803k
Java Tutorial: “this” Keyword  5.589k
Interface in Java  4.627k
Java Tutorial: The “extend” Keyword    4.402k
Java's Access Specifiers   2.935k
Java Tutorial: Arrays      2.673k
Java Tutorial: Defining a Function 2.596k
The “abstract” Keyword In Java 2.316k
Xah's Java Tutorial        2.168k

There are several links to them from stackoverflow.com.

[...]

for links, see:
http://xahlee.blogspot.com/2010/10/inanities-of-java.html

Out of sheer curiosity I checked a few links.

Your problem with Java is that it is an OOP language, and you hate OOP.
OOP indeed isn't a one-size-fits-all tool. If you are unconfortable with
it or if it just simply does not serve your purpose it is quite okay to
leave it alone.

Case closed.

I won't speak for Xah, but I suspect many people (especially that use
CL) don't get Java's very inexpressive form of OO, and consider it
pretty much broken.

 

[Stefan Ram]

Agreed. I think Sun made a bad choice in moving in the direction of
muddled terminology, rather than going for clarity and education.

Sun /did/ use the term pointer:

»(...) reference values (...) are pointers«

JLS3, 4.3.1.

However, this is another meaning of »pointer« than in C,
where pointers are not values, but variables (which are
called »objects« in C):

»A pointer type describes an object whose value provides
a reference to an entity of the referenced type.«

ISO/IEC 9899:1999 (E), 6.2.5, #20

So, matching up terms from different languages is a difficult
business where it does not matter much if the same words
are used or not. (Strictly, C does nowhere define »pointer«
nor »pointer type«, but only says what a pointer type
»describes« - a wording too vague for my taste.)

 

[Stefan Ram]

»(...) reference values (...) are pointers«
JLS3, 4.3.1.
»A pointer type describes an object whose value provides
a reference to an entity of the referenced type.«
ISO/IEC 9899:1999 (E), 6.2.5, #20

And, I only now observe that C uses the word »reference«
above twice to explain what a pointer type is, once as a
noun, once as a verb. So does this »muddle« the C
terminology, then?

Exaggerated, one might say that Sun explains references
as pointers, while C explains pointers as references.

 

[Arne Vajhøj]

And, I only now observe that C uses the word »reference«
above twice to explain what a pointer type is, once as a
noun, once as a verb. So does this »muddle« the C
terminology, then?

Exaggerated, one might say that Sun explains references
as pointers, while C explains pointers as references.

Arne

 

[Keith Thompson]

Sun /did/ use the term pointer:

»(...) reference values (...) are pointers«

JLS3, 4.3.1.

However, this is another meaning of »pointer« than in C,
where pointers are not values, but variables (which are
called »objects« in C):

»A pointer type describes an object whose value provides
a reference to an entity of the referenced type.«

ISO/IEC 9899:1999 (E), 6.2.5, #20

So, matching up terms from different languages is a difficult
business where it does not matter much if the same words
are used or not. (Strictly, C does nowhere define »pointer«
nor »pointer type«, but only says what a pointer type
»describes« - a wording too vague for my taste.)

But the C standard also uses the word "pointer" to refer to
a *value* of pointer type. See, for example, C99 7.20.3.3p3:

The malloc function returns either a null pointer or a pointer to
the allocated space.

 

[Joshua Maurice]

  Sun /did/ use the term pointer:

      »(...) reference values (...) are pointers«

    JLS3, 4.3.1.

That does nothing to address my concern. It fact, it adds to my
concern. My concern is: Java is a derivative of C and C++, and Java
shared a lot of the common syntax and semantics of C and C++. As such,
it causes undo confusion to purposefully confuse and conflate two
formerly distinct, well defined terms.

  However, this is another meaning of »pointer« than in C,
  where pointers are not values, but variables (which are
  called »objects« in C):

      »A pointer type describes an object whose value provides
      a reference to an entity of the referenced type.«

    ISO/IEC 9899:1999 (E), 6.2.5, #20

You cherry picked quotes, and/or the quotes are incorrect. The
terminology in this domain of discourse is loose. This probably is
because we all understand what's going on. It's like mixing up class
and object - you instantiate a class to create an object. You can't
new a class, though we all know what the speaker means. Your cherry
picked quote is an informal use of the term "value". A Java reference
is not a "value", even according to the Java standard.

What follows are the actual definitions, simplified for brevity. (I
don't want to quote an entire treatise on type theory.)

In C, objects are pieces of memory (on some abstract machine) which
hold values. A value of an object is the sequence of bits of the
object, aka the data contents of that object. Each object has a type
which constrains the allowed bit patterns of the object, and provides
a means to interpret those bit patterns, and provides operations on
those bit patterns.

In C, variables are objects which have declarations and definitions
with names in source code.
//Please forgive the C code.
//x is a variable and an object
int x;
//y is a variable and an object, *y is an object but not a variable
int* y = new int;

In C, a pointer is a somewhat vague term. A type can be a pointer (a
pointer-type). An object can be a pointer (an object of pointer-type).
A variable can be a pointer (an object of pointer-type).

Obviously, in Java the situation is slightly different because Java
defines Object to be a very particular thing, and Java defines objects
to be garbage collected entities allocated from the heap. The
definition of "value" remains largely unchanged: a value is the "bit
pattern" (simplification) of a Java object, a Java reference, or a
Java primitive. A value is the current contents of the entity, the
state of the entity.

So, matching up terms from different languages is a difficult
business where it does not matter much if the same words
are used or not. (Strictly, C does nowhere define »pointer«
nor »pointer type«, but only says what a pointer type
»describes« - a wording too vague for my taste.)

It's only difficult in this case because Sun purposefully changed the
meaning, and their change largely broke with past definitions of the
terms. The syntax of Java references and C pointers is largely the
same, and the semantics are exactly the same. A Java reference behaves
exactly like a C pointer (except with null pointer checking and no
pointer math). It does not behave as a C++ reference, which does not
have a distinct "state" apart from the referred-to object. C++ has
pass by reference and pass by value. Java only has pass by value - but
the only things which can be passed are primitives and Java
references.

Again, my contention is that they didn't need to pick a new word which
could cause confusion when a clear and precise term, pointer, clearly
and aptly described the semantics, and again, it's only a minor
inconvenience. It's not the end of the world.

 

[Keith Thompson]

In C, objects are pieces of memory (on some abstract machine) which
hold values. A value of an object is the sequence of bits of the
object, aka the data contents of that object. Each object has a type
which constrains the allowed bit patterns of the object, and provides
a means to interpret those bit patterns, and provides operations on
those bit patterns.

Pretty much, except that an object doesn't necessarily inherently have a
type. For example, malloc() allocates memory and returns a void*
pointer to it; that memory doesn't have a type until you impose one on
it, for example by assigning the void* pointer to a some_type* pointer
(the standard uses the term "effective type".

(Note that the C++ standard's definition of "object" is very similar
to C's; a C++ "object" isn't necessarily of some class type.)

The sequence of bits is the representation of an object. The value is
an interpretation of those bits with respect to some specified type.

In C, variables are objects which have declarations and definitions
with names in source code.
//Please forgive the C code.
//x is a variable and an object
int x;
//y is a variable and an object, *y is an object but not a variable
int* y = new int;

That's a perfectly reasonable definition of the word "variable", but the
C standard doesn't define or use the term.

In C, a pointer is a somewhat vague term. A type can be a pointer (a
pointer-type). An object can be a pointer (an object of pointer-type).
A variable can be a pointer (an object of pointer-type).

If you think of "pointer" as an adjective, there's no vagueness;
you can have a pointer type, a pointer object, or a pointer value.
But yes, the unqualified term "pointer" is potentially ambiguous.
It most commonly refers to a pointer object, though the standard
also uses it to refer to a pointer value. (I don't think a pointer
type is commonly called a "pointer", though.) In practice this
doesn't usually cause problems; in most contexts the meaning is clear
enough, and when it isn't it's easy enough to qualify it.

[...]

 

[Joshua Cranmer]

No ... C# is widely misperceived (mainly by Java users) to be a
derivative of Java. However, beyond minor syntactic differences lie
much greater semantic differences. C# and Java are, in fact, quite
different languages that only superficially look similar.

I think C# was heavily influenced by Java, sufficiently so that you
could put a link in there on one of those "History of Programming
Languages" timelines. I might even go so far as to call it a
`derivative', by which I mean that C# incorporated some concepts from
Java and learned from some of the mistakes that Java made in the
language. Which also means that Java is, to a degree, derivative of C#,
especially in the realm of generics.

An acyclic graph the history of programming languages is not.

 

[Arne Vajhøj]

I think C# was heavily influenced by Java, sufficiently so that you
could put a link in there on one of those "History of Programming
Languages" timelines. I might even go so far as to call it a
`derivative', by which I mean that C# incorporated some concepts from
Java and learned from some of the mistakes that Java made in the
language. Which also means that Java is, to a degree, derivative of C#,
especially in the realm of generics.

I completely agree that:
- C# was heavily influenced by Java when it started
- ideas for Java 7 has been heavily inspired by C# 2/3/4

But Java got generics a year before C#, so ...

Arne

 

[TheFlyingDutchman]

This is an often misunderstood aspect of C and C++. Attempting any
kind of "unorthodox" pointer cast or pointer arithmetic results in
undefined behavior. You're not allowed to have a pointer pointing to a
sufficiently different type and dereference (with some small
exceptions).

Would you agree I can do:

int *a = (int *) 22222222;
double *b = (double *) 1111111;


and the memory addresses do not have to be valid to compile and
attempt a run?

How would you do that in Java with references?

or how would you use Java references and do:

while (*myInt++ != 0)

Would you tell a C programmer who wanted to convert his code to Java
that "You don't have to worry about your code that uses pointers -
Java has you covered there, except they call them references"??

 

[Joshua Maurice]

Would you agree I can do:

  int *a = (int *) 22222222;
  double *b =  (double *) 1111111;

and the memory addresses do not have to be valid to compile and
attempt a run?

How would you do that in Java with references?

or how would you use Java references and do:

 while (*myInt++ != 0)

Would you tell a C programmer who wanted to convert his code to Java
that "You don't have to worry about your code that uses pointers -
Java has you covered there, except they call them references"??

You seemed to miss something I said, which you even quoted. Let me
replicate it:

Attempting any
kind of "unorthodox" pointer cast or pointer arithmetic results in
undefined behavior.

As I said, the difference between Java references and C pointers
largely is no pointer math and no null pointer checking. Obviously I
missed "casting from unrelated types without runtime checks" as well.
I also emphasized that the difference largely was when you misuse C
pointers, you get undefined behavior, whereas when you misuse Java
references, you get well defined behavior (typically an exception).
Obviously they're not interchangeable. However, under "correct use"
their semantics are mostly the same, much moreso than C++ references
and Java references, enough that it causes /minor/ confusion because
of the ill naming of Java references.

 

[TheFlyingDutchman]

Attempting any
kind of "unorthodox" pointer cast or pointer arithmetic results in
undefined behavior.

What do you mean by undefined behavior? That it is up to the compiler
implementation what takes place? I think every C compiler will produce
the same output from

int *ip = (int *) 222222;

And I think a lot of applications depend on that compiler output. How
else to write to video card memory that is at memory address 222222?

 

[Pascal J. Bourguignon]

What do you mean by undefined behavior? That it is up to the compiler
implementation what takes place? I think every C compiler will produce
the same output from

int *ip = (int *) 222222;

And I think a lot of applications depend on that compiler output. How
else to write to video card memory that is at memory address 222222?

Tthe C standard does not specify any specific behavior for this
instruction. It's entirely implementation dependant.

It is exactly the case for most other programming languages.

In most other programming language, you may have a pair of functions
peek(address) and poke(address,byte) to access random memory bytes. The
same HAS TO BE DONE in C if you want to write a portable program.

Notably, C is totally useless when it comes to device drivers on x86
processors, since they are usually accessed not in the memory address
space, but in the I/O address space with the INP and OUT
microinstructions. So you need a iopeek() and iopoke() pair of
functions anyways.


In conclusion, pointer and pointer arithmetic in C is useless and should
be removed from any serrious system programming language. You can do
arithmetic with integers, and let the peek and poke primitive deal with
the mapping between integers and hardware addresses.

 

[Joshua Maurice]

Tthe C standard does not specify any specific behavior for this
instruction.  It's entirely implementation dependant.

It is exactly the case for most other programming languages.

In most other programming language, you may have a pair of functions
peek(address) and poke(address,byte) to access random memory bytes.  The
same HAS TO BE DONE in C if you want to write a portable program.

Really off-topic here, but let me correct this. While I agree that
this should be done for other reasons, portability is not one of them.
As soon as you're writing to particular hardware memory addresses,
there is no such thing as portability, with peek and poke functions or
not. It is inherently tied to the system, and the C standard says
little to nothing about such things (though it was explicitly written
to allow the system to take some of the undefined behavior and make it
defined /for that platform/).

What I have said in this thread was for portable C programs, aka
programs written to the C standard and not to platform extensions.
Obviously writing device drivers and such is possible in C and not in
Java because of C's unchecked pointer casts and other "unsafe" pointer
stuffs. It's not fair to compare this. What is fair is to compare the
semantics of pointers and Java references. You can assign to a pointer
without changing the pointed-to object, changing a passed by value
pointer in a function call leaves the callee pointer unchanged, and so
on. This is very much unlike C++ references which act more like
aliases, and I again contend that because Java in its beginning
largely lifted its syntax and semantics from C++, it should not have
conflated and confused these two terms because it causes (minor) undue
confusion in the communities.

 

[Stefan Ram]

Would you agree I can do:

int *a = (int *) 22222222;
double *b = (double *) 1111111;

»An integer may be converted to any pointer type. Except
as previously specified, the result is implementation-
defined, might not be correctly aligned, might not point
to an entity of the referenced type, and might be a trap
representation.«

ISO/IEC 9899:1999 (E), 6.3.2.3, p5