Is it important to teach pointers in a first course using Java?

Question

Many instructors teaching with Java started their education using earlier languages such as C or C++ in which pointers are essential. Pointers, however, are not a Java concept, though those same instructors may think of, for example, object references as pointers.

How important is it to teach pointers in a first Java course assuming the students don't have much of a prior programming background?

If you think it is important, say why, but also say how much of pointers do you think should be taught. Just as a metaphor/analogy? Or also including, say, pointer arithmetic?

If you think it is not important say why also.

Note that both Python and Ruby are similar to Java in lacking the "pointer" concept. References might be implemented as pointers or not, but the definition of reference is actually abstract in these languages.

---

Note that I take "pointer" to mean the actual machine address of some entity that might, in principle, be manipulated as an integer, whereas "reference" is a more abstract concept that implies that the entity may be accessed via the reference however implemented.

The Java language definition is careful not to discuss the implementation of references, explicitly disassociating them from the C-like notion of pointer.

Answer 1

For a beginning course: no.

I have helped clarify behavior for fellow students who got lost by an instructor who explained things in terms of pointers. I have programmed in C, and most of my current programming is done in Rust; I understand pointers and what problems they are best suited to solve. But in Java, you don't have any access to pointers, so explaining pointers only serves to muddy the waters for a student trying to grep the way a computer thinks.

I take the position that a intro-level course should only cover programming, and the actual science of computer science should be postponed to at earliest 102. But my college also lacks a Software Engineering track, and I would argue most people pursuing a CS education actually want that instead of the science.

In any case, Java uses pass by reference. I know exactly what anyone who cares about terminology and grew up in C/++ is thinking as soon as I say that: Java is pass reference by value. But this is inconsistent with Java's own mental model.

Here's the mental model I have shared multiple times to great effect with students who failed to understand Java's Objects the first time:

A variable is a binding to a value. Thus, when you do Animal c = new Cat();, c is a binding to the constructed Cat. This binding is transparent, and when you use it, you are talking directly to the bound object.

However, in order to facilitate resource sharing, when you pass this object as a parameter to a method, a new binding is created. This binding is to the same object, but is a new binding, so assignment to the binding does not effect the old one (the pass by value).

But because these two bindings are bound to the same object, there is only one object. This means that mutating this object by using its fields or methods will have the effect that the object the original binding is bound to also changes, because they are the same object.

Note that nothing about this mental model breaks on primitives (or the quasi-primitive String), since primitives can only be changed by reassigning. A slightly higher-level course, or even later in the course once students understand the shared resource concept, can mention that primitives aren't bindings but rather just their value.

Once binding misdirection gets multiple layers deep (Objects containing Objects containing etc), it can be useful to talk about and diagram name bindings as a pointer to a value, but that's as far as I go. Stack/Heap doesn't need to be discussed in a Java class: the GC and no stack allocated objects mean that just "somewhere in memory" is all that really needs to be mentioned on object storage until you're at an advanced level where cache coherency or GC overload matters.

---

Post Script:

I've called Java pass by reference here, which will (and has) riled up a bunch of people who want pass by reference to only mean what is expressed in C as function(&name), which Java is not doing. As such, it may be better to call it pass by resource sharing, pass by resource binding, or pass by binding. In C's definition, you are passing a copy of the reference by value (function(&*name)). By my reading of Java, though, I argue that we are passing by the reference to the value, because the binding is not separate from the value. This is a terminology problem, and unfortunately, even in a field that relies on unambiguous interpretations, we do overload our terminology.

Answer 2

Learning about references is important, but I don't feel that learning about pointers is that important for beginning Java students. Certainly intermediate students will need to understand them.

When I started learning about pointers, I had a hard time grasping them at all until I learned assembly language. Once I learned assembly (for any processor), pointers made sense. It helped that I learned PDP-11 assembly at about the same time I learned C. Since C is essentially structured PDP-11 assembly language, I was easily able to see the relationship between the pointer structures and the compiled code.

Java hides the concept of a pointer sufficiently deeply that I would be hard pressed to explain it with java. I can explain java structures in terms of pointers, but have difficulty expressing it the other way around. For teaching pointers and pointer concepts, I would probably use C (yep - plain old C, without the ++) and the x86 assembly language as a starting point.

After that, it's easy to explain that the JVM is built in C, and java object references are implemented as pointers.

Answer 3

No

Because of the way that you learn, you think of them as fundamental, to the way references work. They are not. References do not have to work this way. [I would still agree that pointers are fundamental to understanding memory in Von Neumann / Harvard architecture.]

Java uses references. You can think of these as being pointers, that must point to a valid object of the correct type or to the null object. But there are other ways to thing of references, e.g. like indexes, or like references (in a book or urls). You don't even need to know what is inside.

Other languages don't have references. E.g stack based languages.

Therefore they are not fundamental in any way.

---

My thought on types of references in Object Orientated Programming. See https://richarddelorenzi.wordpress.com/2009/08/10/types-of-reference/

A reference is free or fixed:

• I fixed reference can not be reassigned. e.g. reference in (C++), const pointer (C++)
• A free reference can be reassigned. e.g. pointer in (C++), reference in (C#, Java, python …)

A reference is:

• not null-able: Can point to a valid object: e.g. Eiffel reference
• null-able: Can point to a valid object or null. e.g. Java, C#, python, Traditional Eiffel, Eiffel null-able reference
• radical: Can point anywhere. e.g. pointer, and even a reference in (C++)

A reference refers to something that is:

• Constant
• Mutable

Answer 4

What is important is to teach students the difference between Java objects, and Java variables. There are thousands of questions on Stack Overflow asked by students and by junior developers who do not understand the difference.

When we write Foobar f = new Foobar(...), it's much easier to say that f is a Foobar than it is to say that f holds a reference to a Foobar---I am guilty of taking that shortcut all the time---but nobody can get past the beginner stage until they learn that non-primitive Java variables only ever hold object references, and that the objects themselves only exist in a far-away place called "the heap."

Answer 5

A related (rhetorical) question:

Should C students be taught the [machine language] idea of reusing a pointer as a CPU instruction if the value happens to line up?

The speaker in a Functional Programming talk I recently saw discussed part of the history of programming languages, and the opinion seriously held by some at one time that assembly language was too far abstracted because it didn't allow you to reuse CPU instruction codes as pointers and vice-versa if the values lined up. :)

Also related (classic): The Story of Mel.

Then, the follow-up: How is that fundamentally different from teaching Java students pointer arithmetic?

---

Of course, this is a trick answer, because I do think both concepts (pointer arithmetic and reusing pointers as instructions) should be taught to Java students as ideas. As part of the history of the subject, and the layers of abstraction underneath the level they're working at.

But you shouldn't make them actually do any pointer arithmetic. It's totally sufficient that they understand that there is such a thing and have some idea about roughly how it was done. It's just a significance that they're not going to actually use in Java, so it's good background, but don't overdo it. It's not closely related to what you're teaching them to DO.

Your students need to have:

1. An excellent mastery on the practical skills they need to code in Java, and
2. A clear enough understanding of the theory and underlying concepts and background of what they are doing that they won't become obsolete after some new CS breakthrough or new language or new industry direction.

Does the concept of pointer arithmetic belong in a FIRST class on Java? That depends considerably on how long the course is.

I would say in a full semester course it would deserve perhaps a ten minute discussion at some point fairly well into the course, just for some comparative approach to Java's references and to emphasize that pointers are still used under the hood. And so that your students understand that there are other ways to do things than how Java does them.

---

(The balance between theoretical and practical knowledge I am advocating here is well conveyed in Mr. Hubbard's Study Technology, which I highly recommend for all educators and students.)

Answer 6

As someone who learned to program with ruby, I think that the concept of how a reference to an object works under the hood is vital. Having the knowledge that "under the hood" my variables may be represented as pointers to values makes certain things much easier to understand. For example, in ruby:

a = Object.new
b = a.clone
c = a
c == b #=> false
c == a #=> true

Behavior like this could be seen as mind boggling: Why are 2 empty Objects the same, but the other 2 are not? But when given the conceptual knowledge that a pointer is a reference to a value this can be understood because a and c both point to the same Object in memory, while b points to a different object. Thus they have different Object IDs (a.object_id == b.object_id #=> false) and:

# Define a setter and getter for the test variable
a.instance_exec { def self.test; @test; end; def self.test=(new_val); @test=new_val; end }
a.test = "Foo"
c.test == "Foo" #=> true
b.test == "Foo" #=> NoMethodError

In summary, I think that it's very important to include the concept of what a pointer is in the class, but there's no need to go into the down and dirty details unless the students will actually have to work with pointers.

The basics of what a pointer is (an integer memory address) should still be mentioned, because that gives basis to the otherwise abstract concept of a "reference". Students tend to find it useful to actually understand what's going on in hardware in that case.

Answer 7

No, you don't need to talk about pointers in an introductory Java class. You should talk about references, but even then you should keep it at a very high level.

The best tutorial on references I've seen is Cup Size -- a story about variables and its follow up Pass-by-Value Please. These talk about variables as cups that can hold different items, and references as remote controls that you can put in a cup. You can have two remote controls in two cups that control the same TV, and replacing one of the remote controls with another one that controls a different TV doesn't affect the first TV at all. This also clears up the misconception that Java is "pass-by-reference for objects" when in fact Java is always pass-by-value.

I think this kind of high-level language is what you should be using. You shouldn't get into the low-level details, and you shouldn't even use the word pointer at all.

Answer 8

I think you're asking the wrong question. In my opinion the right questions are:

1. Is it important to teach pointers at some point in the curriculum?
2. If so, which courses in the curriculum are most suitable for teaching them? (Plural to cover cases where some of the courses are optional, or where students may not grasp the concept the first time and may need reinforcement later).
3. Are there any courses which are taught earlier and which will suffer from students not understanding them?

I think it should be self-evident that pointers don't need to be taught in the first programming course: if it isn't, then consider that the first course may use e.g. Haskell, and it would be crazy to try teaching pointers using Haskell. (Of course, if the first programming course uses C then question 3 becomes relevant).

But a stronger statement can be made: it may be that the best course to teach them isn't a programming course at all. If pointers were mentioned at all in the university CS course I studied then it was either in Computer Architecture or Comparative Programming Languages (probably in the lecture on BCPL).

Question 1 is something that we can debate without additional context. But we can't answer questions 2 and 3 unless you supply considerably more detail about the curriculum. And since the question posed is really a subquestion of questions 2 and 3, I don't think we can give you a useful answer to the question as stated.

Answer 9

Pointers as used in C and C++ are a fairly specific implementation of a general concept. The details of that particular implementation are mostly irrelevant--even to people using C and/or C++, many of the details are generally irrelevant.

The general concept is indirection (and dereferencing). Indirection arises in many forms; pointers are one version of it--but so are (for only one example) foreign keys in a SQL database.

The strength (and weakness) of pointers in C and C++ is that they're a relatively general implementation of indirection. On one hand, this means that when a student has learned them, most other (more restricted) forms of indirection are fairly easy and straightforward to deal with. On the other hand, it also means that they're a fairly daunting problem for many people approaching indirection for the first time. Pointers in C and C++ are also (for one example) a common place in which the pre- and post-increment and -decrement operators are used--so when students are supposed to be learning about indirection, it's easy for them to get side-tracked into truly ugly details about the degree to which C and C++ specify (and more to the point, mostly don't specify) sequencing of these operations.

Personally, I think I got somewhat lucky in my timing in learning about such things. The first language in which I was exposed to pointers was Pascal. It had (still has, for the relatively few who still use it) a relatively clean implementation of indirection. You can dynamically allocate an object, and what you get back is a pointer. You can then dereference that pointer to get to the object you allocated. You can do things like assigning and passing pointers as parameters--but that's pretty much it. You don't get into a lot of other details about things like pointer arithmetic that are fairly central to C, but basically irrelevant to the core concept of indirection.

Java, of course, is a poor choice of vehicles for teaching this concept (or much of anything else, but I digress). It attempts to hide the concept of indirection, which makes it more difficult to teach. At the same time, what it provides is (at best) an extremely leaky abstraction. A language that claims it doesn't use pointers, but does use NullPointerExceptions leads to confusion, not enlightenment.

Given that you're apparently already using Java, perhaps it wouldn't be too much of a stretch to provide your students with at least a little exposure to Clojure. This will let you do at least a little exploration of indirection without getting into a lot of ugly details about C and C++ that are difficult to avoid, but irrelevant to the underlying concept.

Answer 10

Here is what it is important to know early.

1. Primitive type variables store their value directly (I say: "Primitive types point directly at their values.")
2. Object type variables store the location of their objects in memory. I say: "Object variables know where their object is in memory.
3. Java is a strictly pass-by-value language in this sense: functions get a copy of the value stored by the variable passed them.
4. If you pass a variable pointing at a mutable object to a function, and the function changes that object's state (e.g. remove an item from an ArrayList), the object itself is changed. Why? Because you passed that object's location in memory to the function and the callee used a mutator method on that object. BANG! Object state is changed.
5. In reference to the last item, you can treat variables pointing to primitive types as if they were pointing at immutable objects, since a copy of the variable's value is made and the original cannot be changed.

Knowing these things early saves a lot of confusion.

Answer 11

Maybe you are thinking about memory management and pointer arithmetics. There is no need for that in the first course.

However I think that it is important to teach students that in Java object are created on heap and you have named pointers (which they call references) that you pass by value when you call a method (similarity with C language).

So Java does have pointers. What Java lacks, is pointer arithmetic. For example if you define an object like this: Integer pointsToAnInt = 5 that will create a pointer 'pointsToAnInt' to a location in memory that contains number 5.

If you say pointsToAnInt = null; and then call pointsToAnInt.intValue(); you will get NullPointerException because that pointer points to null.

From the Java language specification: Chapter 4. Types, Values, and Variables

An object is a class instance or an array. The reference values (often just references) are pointers to these objects, and a special null reference, which refers to no object.

So for marketing reasons Java didn't mention pointers and they called them references but essentially you use pointers and you can get NullPointerException.

On the other hand C++ can pass values by references which Java cannot because Java is pass by value. So references should be something different but in Java a reference to an object is just a pointer to that object and you pass that pointer by value through stack while objects are created on heap and they are garbage collected when there are no more pointers that point to them.

Edit: By using sun.misc.Unsafe you can convert an int to an arbitrary address of an entity. In that case you can also have pointer arithmetic. In my personal experience telling people that Java does not have pointers did a great damage to understanding Java and introduced confusion among people to think that Java is pass-by-reference.

In C# you can pass by reference with ref keyword so you can make a swap function that you cannot make in Java static void SwapStrings(ref string s1, ref string s2). If you omit keyword ref then you get the same behavior like in Java and that is pass by value.

Answer 12

As someone who is self-taught with Python, I'd say it depends on where your students are at. If they're beginning students - no, I don't think you need too. But as your students advance, it becomes a better idea. First, it's a good idea for programmers to understand multiple languages, including languages that use pointers. Second, the term is often thrown around on forums or in books - it's good to know the lingo. Finally, when I did learn the basics of what a pointer was, it was useful for understanding how memory worked - it's good to understand the basics of lower level actions the computer takes to make your program run.

Answer 13

No. Java and Smalltalk were designed as true object oriented languages. Bjarne Stroustrup who defined and wrote the C++ programming language also had the goal of object orientation but had to carry the baggage of the procedural and scripted C programming language due to the installed user base. If he had gotten rid of pointers and other ool polluters, it would have involved a much greater overhaul of the compilers.

The compilers are the main workload when designing a new programming language since you have to write a customized compiler for each hardware and OS platform, which is very non-trivial.

I would avoid teaching not just pointers but all OOL polluters for the following reasons:

Times have changed and your students may be beginners now, but eventually they will be writing code to perform:

writing classes for inheritable exception handling, remember for each feature of a program, you have to typically write 5 - 10 exception handling classes. Well designed software would handle errors so well that they would be invisible to the user. When things do go wrong, an analyst will have a much easier time with inheritable and extendable exception classes.

Object design for artificial intelligence

Both of the above require pure knowledge of OOL. Pointers would just confuse them.

You can teach pointers to a hacking class.

Answer 14

This is a tricky issue and where I think using a bit of formal semantics may help. Of course you don't want to introduce Greek letters and inference rules for undergrads but the concepts should be laid out clearly.

The most important thing I do early when presenting a programming language is to distinguish between syntax (how you write) and semantics (how things run. I later divide it into static semantics --typing-- and dynamic semantics). So here, as others have said, introducing pointers is not a good thing and goes against the spirit of Java (pointers don't exist). But you should present something namely what a value is in Java. The notion of value is fundamental. What is the result when a particular piece of code (syntax) is evaluated.

In Java constants of primitive types are their own values, but Objects on the other hand evaluate to a unique identity (whether you want to say that this identity is the memory address depends on your students and their backgrounds). It's a bit abstract but it allows you to explain several behaviours of the language. For instance, if you pass an object as argument to a method and perform mutation, the object is mutated (although the language is "call by value", since the value of the object is its unique ID, the modification occur on this particular object, not a copy). Conversely, even if you create two instances of the same class with the same internal content (say Point p1 = new Point(0,0) and Point p2 = new Point(0,0)) both objects will compare unequal (with ==). Which then allows you to also introduce why you should compare String object with .equals and so on.

The fact that some languages allow to manipulate this unique identity (pointers, pointer arithmetic etc…) is orthogonal, and imho should not be used to justify the behaviour of Java. It can certainly help as an analogy if the students have prior background in C/C++ but introducing a foreign low-level concept is not way to go.

In summary, you should not introduce pointers but this is not an excuse to not to explain precisely what is going on (call by value semantics with value being unique identities for Objects).

Answer 15

Some people use the term "pointers" to describe Java references. References definitely do need to be described (though they should be called references rather than pointers). Fields, variables, and parameters of class type are often treated as though they hold instances, but they never actually do.

Reference-type variables can hold four different kinds of things:

1. A reference to an object that will never change (often an immutable type like String), which is used to encapsulate the contents thereof.

2. A unshared reference to an object, which could be mutable, used to encapsulate the contents thereof.

3. A reference to an object that is "owned" by the entity holding the reference, but which may also identified by references held by other entitites that don't own it.

4. A reference to an object that is "owned" by some other entity.

The Java language makes no distinction among these different categories of references, but one cannot reasonably expect to write code which is efficient and correct without knowing which category every reference belongs to. In the first two situations, code may treat a reference-type variable as though it holds the object identified thereby, but a programmer must know which of those two situations applies.

If field arr of some object holds a reference to an int[] containing {1,2,3}, and one wants arr to hold a reference to an array holding {1,2,4}, there are two ways of accomplishing that: change the third item of the int[], or create a new int[] holding {1,2,4} and store a reference to that in arr. Either approach may be correct, but if one doesn't know into which category arr belongs, one won't know which approach to use.

Answer 16

Learning pointers is not vital for learning Java, although references become very important once arrays or class instances are introduced given the importance between a reference type or a native type makes when cloning instances (shallow vs. deep copying), passing parameters into methods, or discussions regarding instance hash writing (needed for some of the ordered containers).

Answer 17

I think, no and yes. Students should know that somewhere in Memory lies an object with the values involved. They don't need to know that an internal representation is likely a memory address. Concepts that are alien to Java such as offsets and such can be ignored.

Answer 18

You need to teach about the references, regardless how you call them.

Even if you do not see the reference as a pointer, you absolutely need to explain what the reference is, as otherwise no student will understand the things going on behind

a.x = 1;
b = a;
b.x = 2;
a.x == // WTF?

or, with arrays:

a[0] = 1;
b = a;
b[0] = 2;
a[0] == // WTF?

And it is really not the best idea just to keep secret from the students how the values would change. These cases are frequent in Java code, they are far from the corner cases nobody needs to care about.

And the reference is easiest to explain in terms "it is the address in computer memory". Maybe a reference is also something deeply fundamentally else but I still need to see the easier understandable explanation and, well ... it just is, unless we start talking abut the physical, virtual address, address translation, handles that need to be resolved into addresses and other advanced concepts.

Answer 19

The following sentence from JLS Section 4.3.1

"The reference values (often just references) are pointers to these objects, and a special null reference, which refers to no object".

is sometimes exhibited as an "proof" that Java actually has pointers.

Putting it in context:

• Language specification documents are not the kind of material beginners are expected to learn programming from ;
• at the time (90's), "serious programmers" (the intended readers of language specifications) were probably familiar with mainstream programming languages of the time.

Before Java, most programming languages (C, C++, FORTRAN, Cobol, ...- counter-examples are SmallTalk and Lisp) shared the notion of a variable as a name for a memory chunk containing the binary representation of some information.

Java has some obvious similarities (syntax) with C++, but drastically differs on that notion : a variable refers to a value (of primitive type) or an object. An object is not contained in a variable.

So assigning an object in Java doesn't involve the duplication of that object.

It's a point to be stressed (heavily) when explaining Java to confused C++ programmers. And a simple way to do it is to say Java variables contain references, which are like C++ pointers containing addresses of objects (and are magically de-referenced without a star).

But it's only a way to illustrate concepts of Java with a metaphor, borrowing from a different world. It only helps if you know C++ beforehand. Having to teach pointers first makes the thing more complicated.

The basic explanation is

• objects exist somewhere in the memory space,
• references indicate where they are,

---

Actually pointers are not a "very hard" subject (addresses as first class data). The beginner's difficulties come from the algorithmic side of linked data structures.

Answer 20

This is too long to be a comment:

Java is a pass by value language. You must understand that what variables store in Java. Primitives store their values directly. Object types store heap memory addresses. In either case, when you pass that an argument to a function that argument is evaluated, and then it is assigned to the function's parameter and it behaves like a local variable.

So, if you are passing a variable to a function the evaluation process causes a copy of the bit pattern it is storing to be made. In the case of an object, that's a copy of the memory address. This is why I carefully explain the idea of memory address to my beginning programming students. Python operates similarly, but it has no primitive types. All Python data are objects stored on the heap.