Using JDBC in our Java code

Creating JDBC Application

Today I'm going to explain a really basic example about using JDBC in our java code. 

First of all, we have to create the data we need to extract from our DB. 

Create the table Employee as follows:

mysql> use EMP;
mysql> create table Employees
    -> (
    -> id int not null,
    -> age int not null,
    -> first varchar (255),
    -> last varchar (255)
    -> );
Query OK, 0 rows affected (0.08 sec)
mysql>

Create Data Records

Finally you create few records in Employee table as follows:

mysql> INSERT INTO Employees VALUES (100, 18, 'Zara', 'Ali');
Query OK, 1 row affected (0.05 sec)

mysql> INSERT INTO Employees VALUES (101, 25, 'Mahnaz', 'Fatma');
Query OK, 1 row affected (0.00 sec)

mysql> INSERT INTO Employees VALUES (102, 30, 'Zaid', 'Khan');
Query OK, 1 row affected (0.00 sec)

mysql> INSERT INTO Employees VALUES (103, 28, 'Sumit', 'Mittal');
Query OK, 1 row affected (0.00 sec)

mysql>

There are following six steps involved in building a JDBC application −

• Import the packages: Requires that you include the packages containing the JDBC classes needed for database programming. Most often, using import java.sql.* will suffice.
• Register the JDBC driver: Requires that you initialize a driver so you can open a communication channel with the database.
• Open a connection: Requires using the DriverManager.getConnection() method to create a Connection object, which represents a physical connection with the database.
• Execute a query: Requires using an object of type Statement for building and submitting an SQL statement to the database.
• Extract data from result set: Requires that you use the appropriate ResultSet.getXXX() method to retrieve the data from the result set.
• Clean up the environment: Requires explicitly closing all database resources versus relying on the JVM's garbage collection.

Sample Code

This sample example can serve as a template when you need to create your own JDBC application in the future.

Copy and paste the following example in FirstExample.java, compile and run as follows:

//STEP 1. Import required packages
import java.sql.*;

public class FirstExample {
   // JDBC driver name and database URL
   static final String JDBC_DRIVER = "com.mysql.jdbc.Driver";  
   static final String DB_URL = "jdbc:mysql://localhost/EMP";

   //  Database credentials
   static final String USER = "username";
   static final String PASS = "password";
   
   public static void main(String[] args) {
   Connection conn = null;
   Statement stmt = null;
   try{
      //STEP 2: Register JDBC driver
      Class.forName("com.mysql.jdbc.Driver");

      //STEP 3: Open a connection
      System.out.println("Connecting to database...");
      conn = DriverManager.getConnection(DB_URL,USER,PASS);

      //STEP 4: Execute a query
      System.out.println("Creating statement...");
      stmt = conn.createStatement();
      String sql;
      sql = "SELECT id, first, last, age FROM Employees";
      ResultSet rs = stmt.executeQuery(sql);

      //STEP 5: Extract data from result set
      while(rs.next()){
         //Retrieve by column name
         int id  = rs.getInt("id");
         int age = rs.getInt("age");
         String first = rs.getString("first");
         String last = rs.getString("last");

         //Display values
         System.out.print("ID: " + id);
         System.out.print(", Age: " + age);
         System.out.print(", First: " + first);
         System.out.println(", Last: " + last);
      }
      //STEP 6: Clean-up environment
      rs.close();
      stmt.close();
      conn.close();
   }catch(SQLException se){
      //Handle errors for JDBC
      se.printStackTrace();
   }catch(Exception e){
      //Handle errors for Class.forName
      e.printStackTrace();
   }finally{
      //finally block used to close resources
      try{
         if(stmt!=null)
            stmt.close();
      }catch(SQLException se2){
      }// nothing we can do
      try{
         if(conn!=null)
            conn.close();
      }catch(SQLException se){
         se.printStackTrace();
      }//end finally try
   }//end try
   System.out.println("Goodbye!");
}//end main
}//end FirstExample

Now let us compile the above example as follows:

C:\>javac FirstExample.java
C:\>

When you run FirstExample, it produces the following result:

C:\>java FirstExample
Connecting to database...
Creating statement...
ID: 100, Age: 18, First: Zara, Last: Ali
ID: 101, Age: 25, First: Mahnaz, Last: Fatma
ID: 102, Age: 30, First: Zaid, Last: Khan
ID: 103, Age: 28, First: Sumit, Last: Mittal
C:\>

---

Programming thought of the day:

• Q: What do you call the security outside of a Samsung Store? 
• A: Guardians of the Galaxy.
• 
  

Java Version-wise Features History

Have you ever wondered what are the new features released in all Java versions? Well, if it not your case, it was mine =) 

These are pretty much frequently asked questions in java interviews. In this page, I listing down all JDK changes from JDK 1.x to Java SE 8, sequentially. Though I have tried to cover as much as information I can gather, though if you know something which I missed below, please let me know and I will add that information.

Java SE 9 Features

Possible Release Date : September 21, 2017. Please see the updated release info here.

Proposed features are:

• Support for multi-gigabyte heaps
• Better native code integration
• Self-tuning JVM
• Java Module System
• Money and Currency API
• jshell: The Java Shell
• Automatic parallelization

Java SE 8 Features

Release Date : March 18, 2014

Code name culture dropped. Included features were:

• Lambda expression support in APIs
• Functional interface and default methods
• Optionals
• Nashorn – JavaScript runtime which allows developers to embed JavaScript code within applications
• Annotation on Java Types
• Unsigned Integer Arithmetic
• Repeating annotations
• New Date and Time API
• Statically-linked JNI libraries
• Launch JavaFX applications from jar files
• Remove the permanent generation from GC

Java SE 7 Features

Release Date : July 28, 2011

This release was called “Dolphin”. Included features were:

• JVM support for dynamic languages
• Compressed 64-bit pointers
• Strings in switch
• Automatic resource management in try-statement
• The diamond operator
• Simplified varargs method declaration
• Binary integer literals
• Underscores in numeric literals
• Improved exception handling
• ForkJoin Framework
• NIO 2.0 having support for multiple file systems, file metadata and symbolic links
• WatchService
• Timsort is used to sort collections and arrays of objects instead of merge sort
• APIs for the graphics features
• Support for new network protocols, including SCTP and Sockets Direct Protocol

Java SE 6 Features

Release Date : December 11, 2006

This release was called “Mustang”. Sun dropped the “.0” from the version number and version became Java SE 6. Included features were:

• Scripting Language Support
• Performance improvements
• JAX-WS
• JDBC 4.0
• Java Compiler API
• JAXB 2.0 and StAX parser
• Pluggable annotations
• New GC algorithms

J2SE 5.0 Features

Release Date : September 30, 2004

This release was called “Tiger”. Most of the features, which are asked in java interviews, were added in this release.

Version was also called 5.0 rather than 1.5. Included features are listed down below:

• Generics
• Annotations
• Autoboxing/unboxing
• Enumerations
• Varargs
• Enhanced for each loop
• Static imports
• New concurrency utilities in java.util.concurrent
• Scanner class for parsing data from various input streams and buffers.

J2SE 1.4 Features

Release Date : February 6, 2002

This release was called “Merlin”. Included features were:

• assert keyword
• Regular expressions
• Exception chaining
• Internet Protocol version 6 (IPv6) support
• New I/O; NIO
• Logging API
• Image I/O API
• Integrated XML parser and XSLT processor (JAXP)
• Integrated security and cryptography extensions (JCE, JSSE, JAAS)
• Java Web Start
• Preferences API (java.util.prefs)

J2SE 1.3 Features

Release Date : May 8, 2000

This release was called “Kestrel”. Included features were:

• HotSpot JVM
• Java Naming and Directory Interface (JNDI)
• Java Platform Debugger Architecture (JPDA)
• JavaSound
• Synthetic proxy classes

J2SE 1.2 Features

Release Date : December 8, 1998

This release was called “Playground”. This was a major release in terms of number of classes added (almost trippled the size). “J2SE” term was introduced to distinguish the code platform from J2EE and J2ME. Included features were:

• strictfp keyword
• Swing graphical API
• Sun’s JVM was equipped with a JIT compiler for the first time
• Java plug-in
• Collections framework

JDK 1 Features

Release Date : January 23, 1996

This was the initial release and was originally called Oak. This had very unstable APIs and one java web browser named WebRunner.

The first stable version, JDK 1.0.2, was called Java 1.

On February 19, 1997, JDK 1.1 was released havind a list of big features such as:

• AWT event model
• Inner classes
• JavaBeans
• JDBC
• RMI
• Reflection which supported Introspection only, no modification at runtime was possible.
• JIT (Just In Time) compiler for Windows

Again, feel free to suggest any java feature in any java version which I missed in above lists.

Happy Learning !!

---

Programming thought of the day:

• 1f u c4n r34d th1s u r34lly n33d t0 g37 l41d.

Wolfram Alpha

https://www.wolframalpha.com/

Wolfram Alpha is a computational search engine (sometimes referred to as an "answer engine"). The interface looks similar to that of a regular search engine but queries typed into the search box result answers to specific questions rather than listings of websites that may be relevant to the query.

The Wolfram Alpha search box accepts natural language input in keyword, phrase, or sentence format, as well as mathematical equations. The results are dynamically computed. The project website lists the system's components:

• Linguistic analysis
• New kinds of algorithms for 1000+ domains
• Curated data
• 10+ trillion pieces of data from primary sources with continuous updating
• Dynamic computation
• 50,000+ types of algorithms & equations
• Computed presentation
• 5,000+ types of visual and tabular output.

Here are a few examples -- from a huge number of possibilities -- of categories, queries and results:

Units and Measures - Includes conversions, calculations, industrial measures, and so on. Under "units," examples include "get information and conversions for a unit," "get unit conversions for a quantity," "convert to a specified unit," "do a calculation with units," and "compare physical quantities and compute dimensionless combinations." Entering "1500 sq. ft primer" into the search box results in "18.7 liters" - the amount of primer required to cover that square footage. The result can be changed to display in gallons rather than liters. Typing in "U.S. women's size 5 shoe" yields a list of the dimensions of that size and its equivalent in other countries.

Physics - Includes mechanics, electricity and magnetism, thermodynamics, particle physics, quantum physics, and so on. Under "particle physics," examples include "get information about a particle," "specify a particle symbol," "compare several particles," "request a property of a particle," "do a calculation on particle properties," "compute the reduced mass of a system of two particles" and "get information about a particle accelerator." Typing "proton" into the search box yields the particle's mass, electric charge, particle type, quark content, quantum numbers, lifetime, symmetry operations and excitations.

People and History - Includes people, genealogy, political leaders, historical events, and so on. Under "people," examples include "get information about a person," "compare several people," "find a date or place associated with a person" and "use a birth or death date in a computation." Typing "Charlie Parker" into the search box yields the information that he was a jazz musician, along with his full name, places and dates of birth and death, an image and a timeline.

Wolfram Alpha was developed by Wolfram Research, a maker of mathematical software including Mathematica. The WolframAlpha website describes the ultimate goal of the project:

"We aim to collect and curate all objective data; implement every known model, method, and algorithm; and make it possible to compute whatever can be computed about anything. Our goal is to build on the achievements of science and other systematizations of knowledge to provide a single source that can be relied on by everyone for definitive answers to factual queries."

In this video, Stephen Wolfram, CEO of Wolfram Research, demonstrates and explains Wolfram Alpha:

---

Programming thought of the day:

• My New Years resolution is 1080p.

What is an Integration Test ?

What is an Integration Test ?

Sometimes there is not a clear distinction on what is an integration test and what is a unit test.

My basic rule of thumb is that if

• a test uses the database
• a test uses the network
• a test uses an external system (e.g. a queue or a mail server)
• a test reads/writes files or performs other I/O

…then it is an integration test and not a unit test. I have seen several developers who talk about “tests” and either they mean both or just integration tests. Here is also a brief comparison between the two.

Unit test	Integration test
Results depends only on Java code	Results also depends on external systems
Easy to write and verify	Setup of integration test might be complicated
A single class/unit is tested in isolation	One or more components are tested
All dependencies are mocked if needed	No mocking is used (or only unrelated components are mocked)
Test verifies only implementation of code	Test verifies implementation of individual components and their interconnection behaviour when they are used together
A unit test uses only JUnit/TestNG and a mocking framework	An integration test can use real containers and real DBs as well as special integration testings frameworks (e.g. Arquillian or DbUnit)
Mostly used by developers	Integration tests are also useful to QA, DevOps, Help Desk
A failed unit test is always a regression (if the business has not changed)	A failed integration test can also mean that the code is still correct but the environment has changed
Unit tests in an Enterprise application should last about 5 minutes	Integration tests in an Enterprise application can last for hours

You should now know the difference between the two....well, I hope so =)

How to write an integration test

Writing an integration test is heavily dependent on your environment. The first thing that you should decide is the scope of your integration test. So, let's say we are building a huge RESERVATION SYSTEM, we could write integration tests for:

• Verifying correct integration of the RESERVATION SYSTEM with the printer (in a staging environment of course)
• Verifying correct integration of this RESERVATION SYSTEM with the mail server
• Verifying correct reading/writing of invoices from/to the DB
• Verifying the whole data flow of receiving an order, creating an invoice, saving it to the DB and mailing it to the client. This is an End-To-End integration test

Since some of the integration tests in the case of this RESERVATION SYSTEM, use a staging environment (e.g. the mail server) it is also important to document these dependencies so that his fellow developers know about them. I always hate it when I run the test suite on a new application and half the tests fail because my workstation has no network access to the testing database!

A second point with integration tests that must be accounted is the use of detailed logging. When a unit test fails it is very easy to understand why since the scope is very narrow. When an integration test fails, things are not so simple. Because by definition an integration tests is based on many components and a specific data flow, identifying the failure cause is not always straightforward.

My recommended way to alleviate this problem, is the use of detailed logging statements (that are always needed in an Enterprise application regardless of unit tests). This way, when an integration test fails you can examine the logs and understand if the issue is in the code or in an external resource used by the test.

Why integration tests should NEVER run together with unit tests

Now we reach the most important point regarding unit tests. In a big enterprise application integration and unit tests MUST be handled differently. Here is an all too common scenario that I have personally seen multiple times.

Some developer has created a lot of unit and integration tests. All of them are executed by Maven when the test goal is run. However during a server migration some of the integration tests stop working. However everyone on the team is busy and nobody fixes the IPs in the configuration files.

Soon after some integration tests that depend on an external system run really slowly. But nobody has time to investigate the cause. Developers no longer run tests before committing code because the test suite is very slow. More unit tests break as a result, since developers do not maintain them.

New developers come into the team. They start working on the RESERVATION SYSTEM and soon find out that half the test suite is broken. Most of them do not even bother with unit tests anymore.

A valiant developer comes into the team and says that this madness must stop. He spends a day and finds out that the effort required to fix all tests is not realistic for the current time-frame. He also finds out that in several cases the unit tests are broken because of changes in the business requirements. So fixings the tests is not a straightforward process since somebody has to adapt them to new code.

By this point it is clear that tests are not actually used in this project. New developers simply declare that “writing unit tests is a waste of time” and they are right from their point of view, since nobody wants to work with a broken test suit.

This is a scenario that we need to avoid!

Delegating integration tests to Maven Failsafe plugin

There are many ways to split unit and integration tests. My suggestion is to use the Maven failsafe plugin.

Unit tests should follow the naming convention introduced in the first part of this series. Unit test classes are named with “name of class + Test”. Then they are placed in the test directory of the Maven project structure.

The unit tests are executed automatically when the test goal is run.

Next you should add the failsafe plugin in your pom.xml file.

<project>
  …
  <build>
    <plugins>
      …
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-failsafe-plugin</artifactId>
        <version>2.13</version>
        <executions>
          <execution>
            <id>integration-test</id>
            <goals>
              <goal>integration-test</goal>
            </goals>
          </execution>
          <execution>
            <id>verify</id>
            <goals>
              <goal>verify</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

Your integration tests however have a different naming convention. They are named as “name of class + IT”. IT stands for Integration Test.

Now the test goal will ignore them. Instead these tests will be executed by the integration-test goal which is a built-in goal into Maven. Here is a table that summarizes this split

	Unit tests	Integration Tests
Located in	Maven test directory	Maven test directory
Naming convention	name of class + Test	name of class + IT
Example class name	BasketWeightTest.java	InvoicingProcessorIT.java
Managed by	Maven surefire plugin	Maven failsafe plugin
Executed in test goal	Yes	No
Executed in integration-test goal	No	Yes

How to run integration tests in your build process

Now that all these changes are done you have great flexibility on how you run unit tests. Most importantly your build server (e.g. Jenkins) should contain a mixture of jobs that deal with both kinds of tests. Here is a overview of suggested jobs.

Job type	Schedule	Description	Tests
Main build	Every 15 minutes or half hour.	Only compiles and runs unit tests. Should finish in 15-20 minutes max	Only unit tests
Integration build	Every 24 hours (usually at night)	Runs integrations tests. Can run for 2-3 hours	All tests
QA build	Manually	Deploys to a QA environment	All tests

The suggested workflow is the following

1. Developers run the test goal during development
2. Developers run the test goal before any commit
3. Developers run the integration-test goal before a major commit with many side effects
4. Build server compiles code and runs the test goal every 15-30 minutes (main build)
5. Build server compiles code and runs the integration-test goal every day (integration build)
6. Build server compiles code and runs the integration-test goal before a release to QA

With this workflow it is clear that developers get fast feedback from the unit tests so anything that breaks can be fixed immediately. The boring process of running integration tests is left to the build server which runs them automatically in a well defined schedule.

Conclusion

In this post we have finally tackled integration tests. We showed you the differences with unit tests regarding test focus, external systems and running time.

We also hope we convinced you that they must be handled differently. Our suggested method for splitting tests is the maven failsafe plugin.

Finally we proposed some combinations of build jobs and how they run different types of tests.

Feel free to post your suggestions below regarding unit and integration tests.

---

Programming thought of the day:

• Me: Siri, why am I alone? 
• Siri: *opens front facing camera*