As usual, there will be a MWotD that should be submitted as "hello.txt". Due to the late release of this lab, if you don't want to attend lab, submit your work before Thursday at 11:59 PM (as usual you may continue resubmissions until Friday at 11:59 PM).
Decide if you'd like to use an IDE or not. See the introduction.
In the real world, it is very common for Java programmers to use an Integrated Development Environment or IDE. IDEs provide a number of handy features like real-time syntax checking, automatic code completion, refactoring tools (e.g. renaming variables, methods, or classes across an entire project), and a debugger.
The downside of using an IDE is that it does a lot of things magically that one really ought to know how to do from the command line, like compile files, run programs, I/O redirection, etc. Since the command line is the common communication channel used by every program, we felt it was important that you get a chance to work with it closely.
Furthermore IDEs can be quite complex compared with a text editor like Sublime, and it can be annoying to try to find the magic command that does what you want. IDEs also have persistent state
Separate command line tools vs. an IDE.
In this lab, you'll be debugging broken project 1 submissions using one of the following three recommended approaches (your choice):
You are also welcome to use any other IDE (e.g. NetBeans, IntelliJ, jGrasp), but official support will not be provided for those IDEs. Note that NetBeans is (IMO) easier to figure out on your own. You're welcome to try.
Eclipse, NetBeans, and IntelliJ can also be used on your own machine for code editing, execution, and testing, even if you're on Windows, but official support by the course staff will not be provided. However, there will be two unofficial workshops on setting up Eclipse and Intellij on Wednesday November 5th in room 275 at 7-9 PM and 9-11 PM. These workshops will count as lab attendance for this week (so if you copy down the MWotD during these workshops, that's OK).
Your first step is to decide which approach to take. If you don't already have an opinion, I found Netbeans the easiest of the four options to figure out.
A brief summary is provided below. When you've chosen, click on the provided link to begin this lab in the environment of your choice. If you change your mind, you can always come back and try another one.
An important part of debugging is working with a simplest case that reproduces the error. This can either be a JUnit test or a simple system level test (in jump61 and in db61b, this would be a short list of commands that shows the error).
For this problem, pretend that your colleague has skipped town, leaving you only with a note that says:
"Single table select causes exception. Example: load enrolled2; select SID from enrolled2 where CCN > '200';
Looking at his code, you'll see that he has written some JUnit tests (BasicTests.java). Run these tests and verify that they pass. If you're using Eclipse (or some other graphical IDE) you'll have to spend some time figuring out how to actually run the tests -- don't skip this step, as you'll want to know how to run UnitTest.java for project 2. If you're using the command line, you can just run "make bcheck" from the bugs/bug2 folder.
While we could try to write a JUnit reproducer, our colleague has already given us one in his note. Start up bugs.bug2.db61b.Main and run the test. To do this from the command line, run the following from the bugs/testing folder.
$ java -cp ../:$CLASSPATH bugs.bug2.db61b.Main
If load enrolled2 doesn't work, make sure your classpath (if working from the command line) or your working directory (if working from within Eclipse) is set. Also that was three different uses of work in a single sentence. Fun.
Using what we learned earlier in this lab, find and fix the bug that is causing the exception (hint: it can be fixed in two (and maybe possible one... not sure) lines of code).
Even after you fix the exception, there's still a bug where duplicates are allowed, i.e. you'll see:
$ java -cp ../:$CLASSPATH bugs.bug2.db61b.Main DB61B System. Version 2.0. > load enrolled2; Loaded enrolled2.db > select SID where CCN < '200'; Error: unexpected token: '<' > select SID from enrolled2 where CCN > '200'; Search Results: 104 104 104 104
This is a less interesting bug to identify and find and is therefore optional, but you're welome to fix it if you'd like.
Do not use print statements. If you do, you're defeating the point of this entire lab.
Submit your lab files including the corrected bugs.bug2.db61b package.
For those of you with some kind of commit error (does not appear to be an assignment directory, already under version control, already tracked, untracked, etc, etc, etc.): Something has gone wrong with the version-control-tracking-information in your working directory.
If you're on the instructional machines, the answer is simple: Use the fix-hw command on the folder containing your work, e.g. if your working directory (which contains bugs, Makefile, testing, and staff-version) is ~/labs/lab10, you'd do:
$ cd ~/labs $ fix-hw lab10 $ cd lab10 $ hw commit
The folder must be named lab10.
If you're on your own machine, it's a little trickier but not much. In this case, transmit your files using ftp/scp/cyberduck/whatever to a folder on the instructional machines. This folder must have the name proj0. Then you can use the command described above.
While we are almost certain our commands won't mess up your files, you should not completely trust us. Always keep your own backups!
If you have extra time, work on the project or on HW8.