 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / June 2006List question
I'm pretty new at Java. One thing I'm wondering about is, I see declarations like: List <int []> L = new ArrayList <int []> (); I understand the generic part of this line, but I don't understand why it's not just written as: ArrayList <int[]> L = new ArrayList <int []> (); In other words, why is the pointer type in the first line of type List and not ArrayList? Is there any advantage to making the pointer in the first line a more general type? Thanks. > I'm pretty new at Java. One thing I'm wondering about is, I see > declarations like: [quoted text clipped - 8 lines] > and not ArrayList? Is there any advantage to making the pointer in the > first line a more general type? First of all there are no pointers in Java! To answer your question: it's usually preferred to use the most generic type possible for the variable declaration because that will make later changes to the code easier. Also, it's a documentation hint that really only the contract (interface) of List is needed and not specialized functionality of ArrayList. If you do need functionality special to ArrayList or LinkedList then you must also declare the variable with this type because otherwise you cannot access those methods without casting. Regards robert >> I'm pretty new at Java. One thing I'm wondering about is, I see >> declarations like: [quoted text clipped - 10 lines] > > First of all there are no pointers in Java! Huh? Java is the most pointer-orientated language I know. There is no way to refer to any object other than through a pointer. As the JLS says in section "4.3.1 Objects": "The reference values (often just references) are pointers to these objects, and a special null reference, which refers to no object." In the early development of Java, there was an attempt to pretend it didn't have pointers, I think largely because of some problems in the design of C which made its pointers extremely dangerous. However, pretending not to have pointers only makes it harder to explain some things such as parameter passing. Patricia >> First of all there are no pointers in Java! > [quoted text clipped - 11 lines] > pretending not to have pointers only makes it harder to explain some > things such as parameter passing. I prefer not to use the term "pointer" because most people think "C pointers" and there are significant differences between Java references and pointers: - Java references do not refer a memory location - There's no pointer arithmetic for Java references, also arrays are implemented differently - There is no explicit dereferencing and address of operator - You cannot have illegal Java references other than null and dereferencing this is caught by the language runtime and not the OS So while Java references have some pointer like properties (i.e. they are not the object but refer to a location on the heap) I usually call them "references". Parameter passing uses call by value - but the value is a Java reference. Kind regards robert >>> First of all there are no pointers in Java! >> [quoted text clipped - 17 lines] > > - Java references do not refer a memory location Neither do C pointers, on most modern systems. They go through at least one level of address translation before any memory access. > - There's no pointer arithmetic for Java references, also arrays are > implemented differently [quoted text clipped - 3 lines] > - You cannot have illegal Java references other than null and > dereferencing this is caught by the language runtime and not the OS Although the last three are differences from C pointers, the fact that Java pointers are not C pointers can be explained very simply: "Java pointers are not C pointers. They are much safer and more organized." Patricia > I prefer not to use the term "pointer" because most people think "C > pointers" and there are significant differences between Java references > and pointers: My feeling is that this may be a reasonable justification to be cautious about using the word "pointer" in your own writing. It certainly doesn't constitue any kind of reason for correcting others when they speak about pointers in Java. If the language specification says there are pointers, then it certainly can't be wrong to use the word in that way. If we wanted to be quite pedantic, though, I would see some validity in complaining about the use of the phrase "pointer type". A reference type can be either null or a pointer, but there is no type that is constrained to ONLY contain pointers.  SignatureChris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation >> I prefer not to use the term "pointer" because most people think "C >> pointers" and there are significant differences between Java references [quoted text clipped - 6 lines] > are pointers, then it certainly can't be wrong to use the word in that > way. Well, even language specs can err at times. Especially the JLS is known for its pragmatic approach which also leads to ambiguities or issues not being clear (just think about the memory model in the light of multithreading / multiple CPU's which needed rework). (Note, I'm not saying the JLS is bad in general - just that it also has it's shortcomings. There are certainly more formal, more strict and thus less ambiguous specs around.) Btw, the JLS speaks of references and uses the term "pointer" to explain them - "pointer" seems to be used as the general term not as the specific CS term "(memory) pointer": "4.3.1 Objects 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." Note also that section 4.3's heading reads "Reference Types and Values". My remark is more based on the CS notion of "pointer". Please have a look at Wikipedia's definition of "pointer": http://en.wikipedia.org/wiki/Pointer IMHO the more general term "reference" describes more precisely what Java's references are: http://en.wikipedia.org/wiki/Reference_%28computer_science%29 > If we wanted to be quite pedantic, though, I would see some validity in > complaining about the use of the phrase "pointer type". A reference > type can be either null or a pointer, but there is no type that is > constrained to ONLY contain pointers. I'm not sure I get what you are saying here. Do you mean that the term "pointer type" mandates that no pointer values may be null? Kind regards robert > Btw, the JLS speaks of references and uses the term "pointer" to explain > them - "pointer" seems to be used as the general term not as the [quoted text clipped - 6 lines] > > Note also that section 4.3's heading reads "Reference Types and Values". This seems pretty clear to me. Specifically: - Reference types are types that may contain reference values. - There are two kinds of reference values: pointers, and null. It would be misleading for the section heading to say "pointer values", since it deals with reference values in general, rather than the subset of pointer values. It would be wrong to talk about pointer types, since there are no pointer types in Java: all reference types may contain the reference value null, which is not defined to be a pointer. > My remark is more based on the CS notion of "pointer". Please have a > look at Wikipedia's definition of "pointer": > > http://en.wikipedia.org/wiki/Pointer I don't believe there is a general CS definition of "pointer". Wikipedia certainly is not an authority on the matter. It is well-known that a compliant C compiler, for example, could use a representation for pointers other than memory locations. This is even more clearly true of other languages that use the word "pointer" where the set of allowable operations are no different from those of Java. In the end, this is one of those terms that just needs to be language- dependent in terms of its precise definition... and the JLS provides quite a clear definition, whatever its other ambiguities. > I'm not sure I get what you are saying here. Do you mean that the term > "pointer type" mandates that no pointer values may be null? The JLS defines pointers as equivalent to the set of non-null reference values. No types are constrained to only contain non-null reference values in Java. Therefore, there are no pointer types. That's what I mean. Yes, I realize that "NULL" is considered a pointer in C. As I said, the language is not standardized and the precise meaning of a pointer is language-specific. SignatureChris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation >Yes, I realize that "NULL" is considered a pointer in C. In C, as specified by ISO/IEC 9899:1999 (E), »NULL« has no special meaning other than »NIHFUIWEHIWHFI«. Only, if one directly or indirectly includes »stddef.h« or certain other headers, »NULL« will be defined as a null pointer constant. A null pointer constant, however, is not a pointer: By ISO/IEC 9899:1999 (E), 6.3.2.2#3, an integer constant expression with the value 0 is also a null pointer constant. Especially, the literal »0« is a null pointer constant. However, a null pointer constant (and this also holds for »NULL«, given the inclusion of an appropriate header file) is not a pointer. It can be /converted/ to a pointer type. So, a wording compliant with ISO/IEC 9899:1999 (E) would be: »0 is considered a null pointer constant in C.« or »NULL, after the inclusion of "stddef.h", is considered a null pointer constant in C.« >> My remark is more based on the CS notion of "pointer". Please have a >> look at Wikipedia's definition of "pointer": [quoted text clipped - 7 lines] > other languages that use the word "pointer" where the set of allowable > operations are no different from those of Java. Still those pointers would have to have the same set of properties that C pointers are known for - and that Java references do not have. > In the end, this is one of those terms that just needs to be language- > dependent in terms of its precise definition... and the JLS provides > quite a clear definition, whatever its other ambiguities. Can you please post a reference as to where in the JLS this definition can be found? Kind regards robert >>> My remark is more based on the CS notion of "pointer". Please have a >>> look at Wikipedia's definition of "pointer": [quoted text clipped - 10 lines] > Still those pointers would have to have the same set of properties that > C pointers are known for - and that Java references do not have. Huh? I first learned about pointers in high level languages in Pascal, in the 1970's, from Niklaus Wirth's "The Programming Language Pascal (Revised Report)" http://www.moorecad.com/standardpascal/Wirth-PascalRevisedReport.pdf See section "6.3 Pointer types", "No operations are defined on pointers except for the test for equality." In section "7.3 Referenced variables", "If p is a pointer variable which is bound to a type T , p denotes that variable and its pointer value, whereas p^ denotes the variable of type T referenced by p ." [I'm using ^ for the up-arrow symbol] I don't see anything about arithmetic on pointers, conversions to/from integer types, or any requirement that they have anything to do with memory addresses, just that the pointer somehow "denote" the variable it references. When I learned C, I could see why it added some of the baggage it did to pointers. It makes it possible to write malloc in C. However, I think it would have been much better if wild conversions had been kept in their place, in functions like malloc that needed them. Patricia >>> I don't believe there is a general CS definition of "pointer". >>> Wikipedia certainly is not an authority on the matter. It is [quoted text clipped - 15 lines] > See section "6.3 Pointer types", "No operations are defined on pointers > except for the test for equality." My remark referred to the C pointers that are not implemented as memory addresses. These still must obey the same rules about pointer arithmetic as those implemented as memory addresses. But you're right that C pointers seem to server as a bad example for defining pointers. Pascal pointers are definitively more Java reference like than C pointers. I do think though that nowadays the dominating use of "pointer" refers (points?) to C pointers. And I still do not believe that Java explicitly defines the term "pointer" as a language element until proven otherwise. I didn't find anything like that in the JLS. Kind regards robert Patricia Shanahan sez: ... > When I learned C, I could see why it added some of the baggage it did to > pointers. It makes it possible to write malloc in C. However, I think it > would have been much better if wild conversions had been kept in their > place, in functions like malloc that needed them. A C pointer is a memory address. Generally speaking, compiler doesn't know what may live at a particular heap location at runtime, so it makes perfect sense that all pointers are void.[0] Adding types to pointers is a compiler sugar that makes life easier, but that's about it. [0] Well, it makes sense to me. But then I also believe C doesn't have strings or arrays. Dima SignatureI have not been able to think of any way of describing Perl to [person] "Hello, blind man? This is color." -- DPM > Patricia Shanahan sez: > ... [quoted text clipped - 8 lines] > pointers is a compiler sugar that makes life easier, but that's about > it. This is not a correct description of C. Pointer artihmetic is defined in ways that critically depend on the type of a pointer. Even neglecting that, you are only describing one possible implementation... and that's the point. Even in C, a "pointer" is a rather abstract concept, which just happens to be (*) defined in a way that makes it legal to implement pointers in some reasonably straight-forward way as memory addresses. (*) Of course it's not a coincidence; this was quite deliberate. Nevertheless, the foresight of language designers should not be confused with specified behavior. Java references are also memory addresses, incidentally, in most common implementations I'm aware of. They only differ in that there are fewer operators defined on pointers, and certain operations that would lead to undefined behavior in C are explicitly forbidden from passing the compiler in Java. SignatureChris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation Chris Smith sez: >> Patricia Shanahan sez: >> ... [quoted text clipped - 11 lines] > This is not a correct description of C. Pointer artihmetic is defined > in ways that critically depend on the type of a pointer. I can run an external program (whose source is not available to the compiler) that will stick something other than int into shared memory location pointed to by "int * a". My compiler will (assuming 32-bit ints) translate "a++" to "5th byte after a" -- whether that location contains anything useful is another question. The same "5th byte after a" will result from "a + sizeof int", except it'll work for "void *a" or "MyObject *a" just as well. The "a++" form is a nice shortcut, it saves keystrokes for "sizeof type" and having to remember what the type was. Especially handy when dealing with "arrays" and structures: "a->myMethod()" is way nicer than calculating offset to myMethod() by hand. ...Even in C, a "pointer" is a rather abstract > concept, which just happens to be defined in a way that makes it > legal to implement pointers in some reasonably straight-forward way as > memory addresses. Oh please. C is a glorified assembly, and if more C programmers remembered that, there'd be far fewer buffer overflows and memory leaks that plague C programs. Dima SignatureI like the US government, makes the Aussie one look less dumb and THAT is a pretty big effort. -- Craig Small > > This is not a correct description of C. Pointer artihmetic is defined > > in ways that critically depend on the type of a pointer. [quoted text clipped - 6 lines] > after a" -- whether that location contains anything useful is another > question. This would be implementation-defined behavior. In other words, there are no statements you can make about what the compiler will do when you modify memory under its back. (IIRC, though I'm not entirely sure, unless your variable is a "volatile int *", it's actually undefined behavior rather than implementation-defined, which means, "DON'T DO THAT!") Your concept of C is different from the actual C language. It is common in system programming to use this "C, augmented by some implementation- defined assumptions" kind of language. However, it's not really appropriate for more programming tasks. It's certainly incorrect to say that there will be fewer buffer overflows if programmers play fast and loose with what constitutes defined behavior and what doesn't. Rather, that's a very likely source of buffer overflows and other secuerity errors. It would probably be best, though, to continue this discussion in comp.lang.c if you like. For our purposes, it remains sufficient to point out that there is no reason not to call a reference value a "pointer" in Java, if it's not null. SignatureChris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation Chris Smith sez: >> > This is not a correct description of C. Pointer artihmetic is defined >> > in ways that critically depend on the type of a pointer. [quoted text clipped - 8 lines] > > This would be implementation-defined behavior. (Which part, "a++ == a + sizeof( int )" ???) ...In other words, there > are no statements you can make about what the compiler will do when you > modify memory under its back. Oh, I think "segfault" would be right most of the time, but how you got to modifying compiler's memory while it's compiling your code, or why, is way beyond me. ... It's certainly incorrect to say > that there will be fewer buffer overflows if programmers play fast and > loose with what constitutes defined behavior and what doesn't. I quite agree. How did you manage to read "fast and loose" into what I said (and you conveniently snipped)? > For our purposes, it remains sufficient to > point out that there is no reason not to call a reference value a > "pointer" in Java, if it's not null. It's my #1 pet peeve wrt. Java terminology: they should have called them "pointers" in the first place. Because to those of us who know C++ "reference" means something profoundly different. Dima SignatureSurely there is a polite way to say FOAD. -- Shmuel Metz "Go forth and multiply". -- Paul Martin > [...] > Oh please. C is a glorified assembly, and if more C programmers > remembered that, there'd be far fewer buffer overflows and memory > leaks that plague C programs. At the risk of fanning a flame war: You don't know C. It's the people who abuse it as a high-level assembler -- the people who confuse representation with value (in Java terms, implementation with interface) who are responsible for most of the grief. In one area I feel Java is a step backwards from C. Just the other day I was reviewing some of my own Java code, and I found it crammed with magic numbers: 52, 0x7ff, 1075. Where did these come from, and why are they magical? It's because Java promises that these numbers are special and will never change. A machine that uses different values for the quantities these numbers represent simply won't be able to run Java, not at all. (ObPuzzle: What was my code doing? Plenty of hints ...) When writing C, though, I would never even dream of chaining my code down this way. Instead of fiddling with these magical values, I would use the abstractions provided by C but absent from Java, and my code would stand a chance of being more immune to the whims of machine designers. Or perhaps I could state it differently: C itself is more immune to the whims of machine designers, precisely because it bends to those whims and accommodates them in a way Java can never do. Prediction: When 96-bit and 128-bit machines come along, C will adapt to them and keep on moving, while Java will hit an immovable wall. Observation: The fact that C is more portable than Java should not be taken as an assertion that the programs people write are necessarily more portable. Of course, the same holds in the other direction, too -- just look at the ever-recurring question about "How can I compile my Java to a Windows executable so I can avoid all that nasty portability?" Both languages are cursed with user populations that (mostly) don't understand them. SignatureEric Sosman esosman@acm-dot-org.invalid > > I don't believe there is a general CS definition of "pointer". > > Wikipedia certainly is not an authority on the matter. It is well-known > > that a compliant C compiler, for example, could use a representation for > > pointers other than memory locations. > Still those pointers would have to have the same set of properties that > C pointers are known for - and that Java references do not have. Indeed. However, the set of pointer behaviors in standard C is smaller than many people think. Roughly, given a pointer, I must be able to follow it to obtain the value (which is an lvalue) that it points to; I must be able to compare two pointers in a way that is consistent with pointer arithmetic; and I must be able to add to, subtract from, increment, and decrement pointers in ways that are defined only for arrays and blocks of memory allocated, for example, with malloc. In particular, pointer arithmetic need have little to do with memory locations. The expression (p + 4) just means "a pointer to the element 4 beyond the one I'm pointing to now." What math gets done to obtain that value is undefined. In fact, quite a few things are undefined in C. When you consider the class of correct C programs that avoid undefined behavior, you find that C is a lot more abstract than you may have thought it was. As I said, though, C is a bit complex in this area. Patricia's response regarding Pascal makes the point clearer. Certainly Pascal has pointers. > Can you please post a reference as to where in the JLS this definition > can be found? You quoted it several messages ago. I understand that you're saying you don't think it's clear. I know you made a comment on how the word seems to be used. Nevertheless, in a specification, a word means what the spec says it means. The Java Language Specification says that a reference value may either be a pointer or the special reference value null. Together with the specified behavior of reference values, this constitutes an operational definition of a "pointer" in Java. A pointer is a value that designates some object, and excludes null. SignatureChris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation Sorry for the late reply, I was too busy. >> Can you please post a reference as to where in the JLS this definition >> can be found? [quoted text clipped - 7 lines] > constitutes an operational definition of a "pointer" in Java. A pointer > is a value that designates some object, and excludes null. Point taken. After all this discussion and some more meditation about the topic it seems that terms are by far not as strictly used as I had the impression they were. Especially the JLS seems to support the ambiguity. For example in Chapter 4 "Types, Values, and Variables" you can find the sentence "The values of a reference type are references to objects" which is not exactly consistent with the earlier quote. My impression is that usually people use the term "reference" also for values, which one might or might not consider to be correct with regard to the JLS... Thanks! Kind regards robert > First of all there are no pointers in Java! When was the last time you saw a piece of buggy code throw a NullReferenceException? SignatureEric Sosman esosman@acm-dot-org.invalid Eric Sosman schrieb: >> First of all there are no pointers in Java! > > When was the last time you saw a piece of buggy code > throw a NullReferenceException? I never saw one, but according to the API doc of java.io.ObjectOutputStream#replaceObject, it can happen: | Null can be returned as the object to be substituted, but may cause | NullReferenceException in classes that contain references to the | original object since they may be expecting an object instead of null. http://java.sun.com/j2se/1.5.0/docs/api/java/io/ObjectOutputStream.html#replaceO bject(java.lang.Object) :) > Eric Sosman schrieb: > [quoted text clipped - 11 lines] > > http://java.sun.com/j2se/1.5.0/docs/api/java/io/ObjectOutputStream.html#replaceO bject(java.lang.Object) Ha! Interesting -- have you reported the documentation bug? (Since the Javadoc index has nothing called NullReferenceException one might guess that the text is wrong and ought to refer to NullPointerException. Just possibly, the text is right and the index is broken -- either way, the Javadoc is rong.) SignatureEric Sosman esosman@acm-dot-org.invalid > I'm pretty new at Java. One thing I'm wondering about is, I see > declarations like: [quoted text clipped - 8 lines] > and not ArrayList? Is there any advantage to making the pointer in the > first line a more general type? Yes. At least in theory, it ensures that any code using L depends only on it pointing to a List, not specifically an ArrayList. A change to a different List implementation would affect only the declaration. In practice, an algorithm that depends on random access using "get" calls could go from e.g. O(n) to O(n*n) if an ArrayList were replaced with a LinkedList, even if both are accessed only through the List interface. It is still good practice to code use the interface type and code to the interface unless you deliberately intend to make your code depend on it being an ArrayList. Patricia Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.