Practice reading and debugging strange code.
Textbook: 1.5 (errors)
Although you are only a young, inexperienced programmer, you have just been hired by the large faceless software company Exitech to fill one of their many office cubicles. Along with the cubicle, you have also inherited the software projects of the employee you are replacing.
You learn more about your predecessor from the other employees around the water cooler: he was considered a good programmer, though sometimes a bit careless and over-confident. In particular, he often neglected to compile his programs at all until he had written the entire thing. Apparently, this same careless over-confidence lead to his demise: he went spelunking last weekend, forgot to pack enough batteries for his flashlight, and is believed to have been eaten by a grue.
Your new boss doesn't know much about what Sammy was working on, except that it involved "efficiency in retail business operations" and that the program has to support decimal number input. He transfers the .java file to you and says, "Get it working!"
The code: ChangeCalculator.java
First, look though the code and determine what the program is supposed to do. Rename the file (and class inside) to UsernameA05.java. Add your name to the empty @author tag under Sammy's.
Now work on getting the program to compile and run correctly. Remember to consider all three types of errors: compile, runtime, and logical. (Hint: You do not need to add or remove any lines of code. If you start doing this, you're probably on the wrong track. That said, you may find it helpful to add some temporary println statements to print out the values in different variables while you're debugging runtime and logical errors.)
Remember that sometimes a single bug in the code may result in multiple compile-time errors listed, so always start fixing compile-time errors at the top of the error list given by javac.
Upload your UsernameA05.java file to Tamarin. (The program should now compile and run correctly.)
The Reason: Different operating systems use different characters to represent the end of a line in a text file. Unix--which is what the www2.hawaii.edu server is running--just uses a line-feed character (ASCII value: 0A in hex, 10 in decimal, often represented as a '\n'). Windows uses both a carriage return (ASCII value: 0D in hex, 13 in decimal, often represented as a '\r') and a line-feed. Pre-OSX Macs used only a carriage-return.
Because of this difference, text files generally need their line endings adjusted as they pass between computers running different operating systems. Usually the software that handles this transfer (web browsers, FTP software, etc) does this translation correctly, but not always.
If you're encounting this problem, it's because the translation didn't happen for some reason: the line endings are still only represented by a single line-feed character. When you open the file in a very simple Windows editor like Notepad, it doesn't treat those single characters as line-endings, since it's not both a carriage return + line-feed. It also represents those strange (to it, anyway) single line-feed characters as little boxes.
The Solution: So, the easiest way to fix this is just to open the file in WordPad, not Notepad. (WordPad is found the same place as Notepad: Start -> Programs -> Accessories.) WordPad is a bit more sophisticated than Notepad, and it can handle the foreign line-endings. The file should look correct in WordPad. Just click Save, and close WordPad. Now open the file again in Notepad the problem should have been fixed.
(You can just work in WordPad if you want to. There's just a danger of accidently saving in Rich Text Format (RTF), which includes formatting details and is not plain text. Just make sure you save any new document as a Text Document and you should be fine. Also, WordPad doesn't display line numbers--which you sort of need for this assignment.)