CS W3139-02 Data Structures and Algorithms -- Spring 1999

Recitation 5 - Date, Calendar, Calculating Run Time, and jdb

The Date Class
The Calendar and GregorianCalendar Classes
Calculating the runtime of code
jdb - The Java Debugger
- Starting a jdb Session
- jdb Commands

The `Date` Class

This class represents dates and times.
It lets you work with them in a system independent way.
You can instantiate Date with no arguments, to represent the current moment.
You used to be able to provide arguments to the Date Constructor (year, month, day, hour, etc.) to say "build me a Date that represents this date/time." However, that use is now deprecated (officially disapproved) and you should use the class GregorianCalendar instead.
Although the Date class has been criticized for its poor design and many of its features are now deprecated, the class itself is still used to represent an instant in time.
You get a Date representing the current point with:
```
    Date d = new Date();
```
Java uses a long int to represent an instant in time.
The value is interpreted as "milliseconds since the epoch" (January 1, 00:00:00, 1970).
You can retrieve this value using the getTime() method.

For example, to get the current milliseconds:

    Date d = new Date();
    long m = d.getTime();

Doing something with dates sometimes involves a mixture of classes.

The `Calendar` and `GregorianCalendar` Classes

The class Calendar translates between an instant in time, and individual fields like year, month, hour, etc.
Date used to do this, but it did it in a way that didn't properly internationalize, so those methods have been deprecated.
Calendar holds dates internally in two forms: the "milliseconds since the epoch" (unfortunately held in a long int, rather than a Date object) form, and the "several ints individually representing day, month, year, hour, etc." form.
In a striking example of bad-code design, updating one of these forms does not update its twin.
Calendar also knows about time zones.
The time zone information has a class of its own: TimeZone.
There is also a DateFormat class that provides elementary date formatting.
Calendar is an abstract base class, which is meant to be overridden by a subclass that implements a specific calendar system.
Its an annoying approach because it makes the common case of simple date processing un-obvious.
Most of the world uses the Gregorian calendar (named after the Pope who established it in 1582).
The class java.util.GregorianCalendar extends Calendar and provides more methods.
Since Calendar is an abstract class, and the parent of GregorianCalendar, you should simply use GregorianCalendar all the time.

Here is how you would get a date of a particular value:

    GregorianCalendar g = new GregorianCalendar(61, 7, 13);

That represents the day the Berlin wall was constructed, August 13, 1961 in the European Central Time (ECT) zone.

So a more accurate way to construct that date is to first set the correct time zone, then set the date:

    TimeZone z_ect = TimeZone.getTimeZone("ECT");
    GregorianCalendar g = new GregorianCalendar(z_ect);
    g.set(61, 7, 13);

Note that (rather stupidly) months are on the range 0 to 11, and years are represented by the 4-digit year less 1900.
If you don't specify a time zone, GregorianCalendar defaults to the time zone the where the program is running.
A list of all the time zones can be found by looking in the source for java.util.TimeZone.java.

You can pull the individual values out of a date like this:

    int year = g.get(Calendar.YEAR);
    int month = g.get(Calendar.MONTH);
    int day = g.get(Calendar.DAY_OF_WEEK);

You can also check if one date is before or after another date, but there is no simple way to get the amount of time between two dates.
The whole time zone / date / calendar thing in Java is really ridiculous. It is often viewed as a real weak point of Java.

Calculating the Runtime of Code

In Homework 2 (which I really hope you have started by now) you are required to determine the running time of your two concordance implementations, on varying sizes of unique words.
The way we will go about doing this is to determine the number of milliseconds your search function took to run, and then convert the milliseconds to seconds.
There are several ways to do this.
The first example uses the Date and GregorianCalendar to determine the running time.
We will consider this the object oriented version because we will actually be instantiated objects to hold the time for us.
The second method utilizes a shortcut in the java.lang.System class.

Here is the first method:

import java.util.*;

// user-defined exception
class BadRange extends Exception {}

public class time {

  public static void main(String args[]) {

    time T = new time();
    long  start, end; 
    double totalseconds;

    // instantiate a GregorianCalendar object
    GregorianCalendar cal = new GregorianCalendar();
    
    // instantiate a Date object
    Date date = new Date();

    // refresh date
    cal = (GregorianCalendar)cal.getInstance();

    // getTime() is a method of class Calendar (and therefore 
    // GregorianCalendar). It returns a Date class with the
    // current time since the epoch

    date = cal.getTime();
      
    // get current milliseconds from the Date object
    start = date.getTime();
      

    /* place whatever code you want to time execution of
       in here... */
      
 
    // refresh date
    cal = (GregorianCalendar)cal.getInstance();
    date = cal.getTime();
      
    //get current milliseconds from the Date object
    end = date.getTime();
      

    // calculate the total seconds from milliseconds
    totalseconds = (double)(end - start) / (double)1000;
     
    return;

  }

}

The next method is much more suitable for our purposes.
It does not bother instantiating any objects to calculate the date or time.
Instead it uses a method from the java.lang.System class called currentTimeMillis().

This is simply a static method.

import java.util.*;


class BadRange extends Exception {}

public class time2 {

  public static void main(String args[]) {

    time2 T = new time2();
    long  start, end; 
    double totalseconds;

    // get current milliseconds from java.lang.System
    start = System.currentTimeMillis();


    /* place whatever code you want to time execution of
       in here... */

    //get current milliseconds
    end = System.currentTimeMillis();
      
    // calculate the total seconds from milliseconds
    totalseconds = (double)(end - start) / (double)1000;

    return;

  }

}

jdb - The Java Debugger

jdb is a debugger for Java classes.
It is text-based, command-line oriented, and has a command syntax like that of the UNIX gdb debugger for C.
When jdb is invoked with the name of a Java class, it starts another copy of the Java interpreter, passing any specified Java options to the interpreter.
jdb is itself a Java program, running in its own copy of the interpreter.
This new interpreter loads the specified class file and stops for debugging before executing the first Java byte-code.

Starting a jdb Session

There are two ways jdb can be used for debugging.
The most frequently used way is to have jdb start the Java interpreter with the class to be debugged.
This is done by substituting the command jdb for java in the command line.
Suppose you wanted to debug your class myclass.class (note this is a .class file, not a .java file, so it has already been compiled):
```
    $ jdb myclass
```

Note that you can still specify options:

    $ jdb -classpath $INSTALL_DIR/classes myclass

The second way to use jdb is by attaching it to a Java interpreter that is already running.
For security reasons, Java interpreters can only be debugged if they have been started with the -debug option.
When started with the -debug option, the Java interpreter prints out a password for jdb's use.
To attach j-DB to a running Java interpreter (once the session password is known), invoke it as follows:
```
    $ jdb -host <hostname> -password <password>
```

So an example would be:

    $ jdb -host cunix.cc.columbia.edu -password 4tmc2b

If you would like to browse local (stack) variables, the class must have been compiled with the -g option.

jdb Commands

The following is a list of jdb commands. For a full list of commands and their specifications, you can view the man page of jdb (unfortunately, I believe only the CS machines have the man page):
```
    $ man jdb
```
Here are some of the commands:
!!
catch [ exception class ]
classes
clear [ class:line ]
cont
down [ n ]
dump id(s)
exit (or quit)
help (or ?)
ignore exception class
load classname
locals
print id(s)
run [ class ] [ args ]
step
stop [ at class:line ]
stop [ in class.method ]
up [ n ]
where [ thread ] [ all ]
There are a few more notes about exceptions in jdb.
When an exception occurs for which there isn't a catch statement anywhere up a Java program's stack, the Java runtime normally dumps an exception trace and exits.
When running under jdb, however, that exception is treated as a non-recoverable breakpoint, and jdb stops at the offending instruction.
If that class was compiled with the -g option, instance and local variables can be printed to determine the cause of the exception.
Specific exceptions may be caught with the catch command (see above), for example:
```
    catch FileNotFoundException
    catch mypackage.BigTroubleException
```
The Java debugging facility keeps a list of these exceptions, and when one is thrown, it is treated as if a breakpoint had been on the instruction which caused the exception.
The ignore command (see above) removes exception classes from this list.
Note: the ignore command does not cause the Java interpreter to ignore specific exceptions, only the debugger.

[ CS3139 Home]

CS W3139-02 Data Structures and Algorithms -- Spring 1999

Recitation 5 - Date, Calendar, Calculating Run Time, and jdb

Contents

The Date Class

The Calendar and GregorianCalendar Classes

Calculating the Runtime of Code

jdb - The Java Debugger

Starting a jdb Session

jdb Commands

The `Date` Class

The `Calendar` and `GregorianCalendar` Classes