|
home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs
The Java language has many good design features. However, it's not particularly well suited for introductory teaching: exceptions to basic rules come up frequently. We'll teach you the basic rules as you're learning, but will intentionally hide the complicated exceptions, at first. But if you're curious, here's the List of Lies. (Don't worry, every lie on here will get cleared up by the end of the semester; you don't need to pay any attention to this page.)
Lie (kinda): To call a method, you must write object-dot-methodName-openParen-inputs.
Truth: If you leave off the object-dot, Java will (behind your back) write in “this.” for you. (This is only true inside of method bodies; not in BlueJ's Code Pad.) So you can technically leave off the word this; however be sure you understand that it really is there, whether you write it or not! (So the rule isn't “When calling a method-name, sometimes “object-dot” is required and sometimes it isn't”; the truth is ““object-dot” is always required to call a method, and if you leave it blank then it's as if you wrote “this.””.)
Lie: Math is an object, so Math.sqrt(16.0) fits our
Truth: Math is a class, and sqrt is a static method — a method which exists independently of any objects. (The tip-off is that we never created a new Math object, the same way we had to create a new PizzaServer() before we call that method.)
We'll discuss static methods (and static fields) ...later.
(This lie is the general case of the preceding lie.)
Lie: Method calls always start with “object-dot-…”.
Truth: Static methods are (usually) called via “class-dot-…”. We'll update our mantra later: “To call a method, “objectOrClass dot methodName open arguments”.”
We'll discuss static methods (and static fields) ...later.
Lie: + can be applied to two numbers (in which case Java call the built-in addition-function), or to two Strings (in which case Java calls the built-in string-concatenation function), but not to one-number-and-one-String.
Truth: If you evaluate "hi" + 3, Java will (behind your back) call a function to convert 3 into a String, and then it will procede with string-concatenation: "hi" + (new Integer(3)).toString().
Actually, there's a lot more going on here; "hi" is (nearly) shorthand for new String("hi"), and the string-concatenation method is really concat, so "hi"+3 gets re-written as (new String("hi")).concat( (new Integer(3)).toString() ). And actually, that's a lie too -- String literals are interned, the concatenation probably uses StringBuilder (on which toString() gets called), and some of this may be done at compile-time instead of run-time.
Hey, you asked. Sometimes, it's easier to live with a lie (especially when trying to learn the fundamentals of programming and good design).
Lie: import is a shallow concept -- it only helps you avoid typing.
Truth: It's possible -- but ill-advised -- to abuse import. For example, you might write a program using import MyDebuggingClasses.LinkedList;, do all your testing, and then just before shipping change this to import java.util.LinkedList;. Nothing inherently wrong with this, other programmers reading your code are probably not going to be aware of how you're changing the meaning of LinkedList in your code.
If you want to achieve the above effect, I recommend instead keeping two source files -- MyClassForDebugging.java, and then write a short script which automatically generates MyClassForShipping. The auto-generated class just has a different import statement, and a warning “/* Do not edit this file; it is auto-generated from the file ...*/”.
Also: don't re-use the names of existing, standard classes like String, Iterator, etc.. Give the classes your own names, so other programmers are always reminded that these aren't quite the class they might otherwise think. For example, javax.swing.JList is so-named to avoid confusion with java.util.List, even when using an import. (In fact, both these classes are commonly imported in the same file.)
home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs
©2007, Ian Barland, Radford University Last modified 2007.Aug.27 (Mon) |
Please mail any suggestions (incl. typos, broken links) to ibarlandradford.edu |