java.util.Calendar and java.util.Date

java.util.Date – Is a point in time (maintains millisecond accuracy)

java.util.Calendar –helps manipulate and compare java.util.Date

 

To convert Date to Calendar

 

        Calendar cal1 = Calendar.getInstance();

        Date currentTime = new Date(); // run on May, 28^th 2009

        cal1.setTime(currentTime);

        assertEquals(2009, cal1.get(Calendar.YEAR)); // returns true

        assertEquals(Calendar.MAY, cal1.get(Calendar.MONTH)); // returns true

        assertEquals(28, cal1.get(Calendar.DATE)); // returns true

 

To convert Calendar to Date

 

        Date date2 = cal1.getTime();

 

To find dates relative to each other – example to find the date tomorrow and yesterday

 

        Calendar cal1 = Calendar.getInstance();

        Date currentTime = new Date();// run on May, 28^th 2009

        cal1.setTime(currentTime);

        cal1.roll(Calendar.DATE, 1); // one day after the date represented by cal1 i.e. 29th

        assertEquals(2009, cal1.get(Calendar.YEAR)); // returns true

        assertEquals(Calendar.MAY, cal1.get(Calendar.MONTH)); // returns true

        assertEquals(29, cal1.get(Calendar.DATE)); // returns true

 

        cal1.roll(Calendar.DATE, -1); // one day before the date represented by cal1 i.e. 28th

        assertEquals(2009, cal1.get(Calendar.YEAR)); // returns true

        assertEquals(Calendar.MAY, cal1.get(Calendar.MONTH)); // returns true

        assertEquals(28, cal1.get(Calendar.DATE)); // returns true

 

JDBC Notes (Source)

JDBC Notes (Source)

Types of JDBC drivers:
Type 1: Drivers that implement JDBC APIs to map to another API such as ODBC. Dependent of native library (limited portability). e.g. JDBC-ODBC bridge

Type 2:Partly written in java and partly in native code (limited portability). Use native client library specific to the data source. E.g. JDBC driver that wraps around the oracle client lib.

Type 3:Fully implemented in Java. Interfaces with middleware server using db independent protocol. Middleware server then interfaces with the actual data source.

Type 4:Fully implemented in Java. Implemented network protocol for a data source. Directly communicates with data source.

Basics steps in using JDBC

1. Establish a connects
   
1. Load the driver

Class.forName("org.apache.derby.jdbc.EmbeddedDriver");// Driver document details class name to use

Creates a instance of the driver clas
Registers the instance with DriverManager
Once created the driver instance can make a connection to DBMS.

            B.  Make a connection
                     i.  Using DriverManager

• Works with Driver interface to manage the set of drivers available to a jdbc client (code that makes jdbc calls)
• JDBC client provides the URL (of the data source to connect to) and requests a connection with the DriverManager
• DriverManager finds out a driver that recognizes the URL and uses the driver to connect to the data source
• URL Pattern

<<protocol>>:<<sub-protocol>>:<<sub_name/db_name>>[property_list]

e.g.jdbc:derby:babudb

where 

<<protocol>> Usially jdbc

<<sub-protocol>> Specified in driver documentation

<<sub_name/db_name>> Usually data base name

<<property_list>> attributes supported by driver specified in driver documentation

• Making a connection

public static Connection DriverManager.getConnection(String URL, Properties info);

public static Connection DriverManager.getConnection(String URL, String user, String password);

e.g.

Connection conn = DriverManager.getConnection("jdbc:derby:COFFEES");

Connection conn = DriverManager.getConnection("jdbc:derby:COFFEES", "babu", "babupassword"); // Connect to COFFEES database using babu/babupassword as cred.

If one of the drivers registered with DriverManager recognizes JDBC URL, then the driver establishes connection with the specified DBMS
DriverManager.getConnection() returns a open connection
The DriverManager manages all details of establishing the connection
Only driver authers need to know about Driver interface

                    ii.  Using DataSource

• Increases application portability by using a logical name for data sources instead of referencing driver specific information in the JDBC client/application
• Some examples:

// DataSource as a JNDI resource

InitialContext ic = new InitialContext()

DataSource ds = ic.lookup("java:comp/env/jdbc/myDB");
Connection con = ds.getConnection();

// DataSource implementation provided by vendor
DataSource ds = (DataSource) org.apache.derby.jdbc.ClientDataSource()
ds.setPort(1527);
ds.setHost("localhost");
ds.setUser("APP");
ds.setPassword("APP");
Connection con = ds.getConnection();

The start of nuclear weapons

May 7th, 1945 - German Surrender
July 16th, 1945 - First U.S. Nuclear test
July 26th, 1945 - U.S., Britain (a day before Churchill's end of term )and China give ultimatum(Not intended to be acceptable by Japan)
August 6th, 1945 - Hiroshima bombing (Bomb name: Little boy, Uranium based)
August 9th, 1945 - Nagasaki bombing (Bomb name: Fat Man, Plutonium based)
August 29th, 1949 - First U.S.S.R Nuclear test

Overriding methods can only throw exception that are thrown by the overridden method

import java.io.IOException;

 

interface TestInterface

{

        void test();

}

 

public class Second implements TestInterface

{

        public void test() throws IOException

        {

                System.out.println("Second.test() invoked");

        }

 

        public static void main(String[] args) throws IOException

        {

                TestInterface j = new Second();

                j.test();

        }

}

 

C:\users\Babu\temp\java>javac Second.java

Second.java:10: test() in Second cannot implement test() in TestInterface; overridden method does not throw java.io.IOException

        public void test() throws IOException

                    ^

1 error

An implementation of a method need not throw all exceptions thrown by the interface

import java.io.IOException;

 

interface TestInterface

{

        void test() throws IOException;

}

 

public class Second implements TestInterface

{

        public void test() // DOES NOT THROW IOEXCEPTION

        {

                System.out.println("Second.test() invoked");

        }

 

        public static void main(String[] args) throws IOException

        {

                TestInterface j = new Second();

                j.test();

        }

}

 

C:\users\Babu\temp\java>javac Second.java

 

C:\users\Babu\temp\java>java Second

Second.test() invoked

All methods of a interface are public

import java.io.IOException;

 

interface TestInterface

{

        void test() throws IOException;

}

 

public class Second implements TestInterface

{

        void test() throws IOException

        {

                System.out.println("Second.test() invoked");

        }

 

        public static void main(String[] args) throws IOException

        {

                Second j = new Second();

                j.test();

        }

}

 

C:\users\Babu\temp\java>javac Second.java

Second.java:10: test() in Second cannot implement test() in TestInterface; attempting to assign weaker access privileges; was public

        void test() throws IOException

             ^

1 error

log4j log levels

Eric says:

 

Trace – I use for start and end of methods.

Debug – I use for low level debugging, info about the processing of single records.

Info – I use as a sparse group type comment, like ‘101 records processed.’

Warn – I use when something I don’t like happened, but the user may not care.

Error – I use when something un-expected happened and I’m stopping the processing.

Fatal –

                I don’t really use fatal I suppose I should – but how is it different then Error