Try loading the driver prior to using the DriverManager class.
try{
     String dbURL = "jdbc:mysql://localhost:3306/murach";
     String username="root";
     String password="1234";
     Class.forName("com.mysql.jdbc.Driver");//load driver
     Connection con2 = DriverManager.getConnection(dbURL, username, password);
     String query = "insert into tblUser1(firstname) values('shaon')";
     Statement statmnt = con2.createStatement();
     statmnt.executeUpdate(query);
}
From O'Reilly:
Before you can use a driver, it must be registered with the JDBC
  DriverManager. This is typically done by loading the driver class
  using the Class.forName( ) method:
This is required since you have placed the library within the JDK/lib folder which I'm assuming is loaded using a different ClassLoader than the one used by your application.  Since different class loaders were used the automatic registration that takes place by JDBC 4.0+ drivers will not take effect.  You could try to place the driver jar file within the lib of your application server, which should use the same ClassLoader of your application.  See: When is Class.forName needed when connecting to a database via JDBC in a web app?
Regarding Automatic Registration
In JDBC 4.0, we no longer need to explicitly load JDBC drivers using
  Class.forName(). When the method getConnection is called, the
  DriverManager will attempt to locate a suitable driver from among the
  JDBC drivers that were loaded at initialization and those loaded
  explicitly using the same class loader as the current application.
The DriverManager methods getConnection and getDrivers have been
  enhanced to support the Java SE Service Provider mechanism (SPM).
  According to SPM, a service is defined as a well-known set of
  interfaces and abstract classes, and a service provider is a specific
  implementation of a service. It also specifies that the service
  provider configuration files are stored in the META-INF/services
  directory. JDBC 4.0 drivers must include the file
  META-INF/services/java.sql.Driver. This file contains the name of the
  JDBC driver's implementation of java.sql.Driver. For example, to load
  the JDBC driver to connect to a Apache Derby database, the
  META-INF/services/java.sql.Driver file would contain the following
  entry:
org.apache.derby.jdbc.EmbeddedDriver
Let's take a quick look at how we can use this new feature to load a
  JDBC driver manager. The following listing shows the sample code that
  we typically use to load the JDBC driver. Let's assume that we need to
  connect to an Apache Derby database, since we will be using this in
  the sample application explained later in the article:
Class.forName("org.apache.derby.jdbc.EmbeddedDriver");
Connection conn =
    DriverManager.getConnection(jdbcUrl, jdbcUser, jdbcPassword);
But in JDBC 4.0, we don't need the Class.forName() line. We can simply
  call getConnection() to get the database connection.
Source
Regarding Service Loaders
For the purpose of loading, a service is represented by a single
  type, that is, a single interface or abstract class. (A concrete class
  can be used, but this is not recommended.) A provider of a given
  service contains one or more concrete classes that extend this service
  type with data and code specific to the provider. The provider class
  is typically not the entire provider itself but rather a proxy which
  contains enough information to decide whether the provider is able to
  satisfy a particular request together with code that can create the
  actual provider on demand. The details of provider classes tend to be
  highly service-specific; no single class or interface could possibly
  unify them, so no such type is defined here. The only requirement
  enforced by this facility is that provider classes must have a
  zero-argument constructor so that they can be instantiated during
  loading.
A service provider is identified by placing a provider-configuration
  file in the resource directory META-INF/services. The file's name is
  the fully-qualified binary name of the service's type. The file
  contains a list of fully-qualified binary names of concrete provider
  classes, one per line. Space and tab characters surrounding each name,
  as well as blank lines, are ignored. The comment character is '#'
  ('\u0023', NUMBER SIGN); on each line all characters following the
  first comment character are ignored. The file must be encoded in
  UTF-8.
If a particular concrete provider class is named in more than one
  configuration file, or is named in the same configuration file more
  than once, then the duplicates are ignored. The configuration file
  naming a particular provider need not be in the same jar file or other
  distribution unit as the provider itself. The provider must be
  accessible from the same class loader that was initially queried to
  locate the configuration file; note that this is not necessarily the
  class loader from which the file was actually loaded.
Source