How to determine which jar a class is loaded from?

When the method that contains this sniplet is called, it will print out something like:


Will the codeSource be null? The answer is yes. When a jar file is loaded by the system class loader, it’s codeSource will be null. What jars will be loaded by the system class loader? the rule of thumb is that all the jars in the class path (not the ones you package in your application) will be loaded by the system class loader. Obviously the above code can’t used to find out which jar a class is loaded from, if the jar is loaded by the system class loader. You can use the “verbose” java command line argument when you start the application:

java -verbose app

it will print out every class in each jar the system class loader loads, ie:

[Opened C:\dev\bea\JDK160~1\jre\lib\rt.jar]
[Loaded java.lang.Object from C:\dev\bea\JDK160~1\jre\lib\rt.jar]
[Loaded from C:\dev\bea\JDK160~1\jre\lib\rt.jar]
[Loaded java.lang.Comparable from C:\dev\bea\JDK160~1\jre\lib\rt.jar]
[Loaded java.lang.CharSequence from C:\dev\bea\JDK160~1\jre\lib\rt.jar]
[Loaded java.lang.String from C:\dev\bea\JDK160~1\jre\lib\rt.jar]
[Loaded java.lang.reflect.GenericDeclaration from C:\dev\bea\JDK160~1\jre\lib\rt.jar]


HackerRank: DynamicArray

Problem Statement

There are N sequences. All of them are initially empty, and you are given a variable lastans = 0. You are given Q queries of two different types:

  • 1 x y” – Insert y at the end of the ((x XOR lastans) mod N)th sequence.
  • 2 x y” – Print the value of the (y mod size)th element of the ((x XOR lastans) mod N)th sequence. Here, $size$ denotes the size of the related sequence. Then, assign this integer to lastans.

Note: You may assume that, for the second type of query, the related sequence will not be an empty sequence. Sequences and the elements of each sequence are indexed by zero-based numbering.

You can get more information about XOR from Wikipedia. It is defined as ^ in most of the modern programming languages.

Input Format

The first line consists of $N$, number of sequences, and $Q$, number of queries, separated by a space. The following $Q$ lines contains one of the query types described above.

1 < N,Q < 10^5
0 < x < 10^9
0 < y < 10^9

Output Format

For each query of type two, print the answer on a new line.

Sample Input

2 5
1 0 5
1 1 7
1 0 3
2 1 0
2 1 1

Sample Output



The first sequence is 5, 3 and the second sequence is 7.


How to create a Custom ADF Component

In this tutorial, we will create a custom ADF Component.

Create new files and package structure as shown:

Create a Custom ADF Component

Source Code of the required files is as below:

Final Output:

Create a Custom ADF Component

Comparable vs Comparator

There are many articles available on internet for this. But still I would write something about it.

What when and why?

A Comparable class is a class, which can be compared with the objects of its own type. Let us take an example of a book.

public class Book implements Comparable {
    String title;
    int    isbn;

    Book(String title, int isbn) {
        this.title = title;
        this.isbn  = isbn;
    /* This method will be the default method used 
       to sort Book objects in a list or Array */
    public int compareTo(Object object) {
    // It should throw NullPointerException if object passed is null
    if (object==null)
        throw new NullPointerException("compareTo: Argument passed is null");
        Book other = (Book) object;
        if (this.title.equals(other.title)) {
            return this.isbn - other.isbn;
        return this.title.compareTo(other.title);

The moment your class implements Comparable, you can then use

List list = new LinkedList();
        list.add(new Book("Patterns", 12345));
        list.add(new Book("Apples", 34567));
        list.add(new Book("Examples", 23456));


Using this you can sort your list.

But what if now, you want to add or use another sorting criteria defined in Book class… Here comes the need of Comparator.
There are two ways listed here to use the Comparator class.

First method

We create a anonymous class that implements Comparator and overrides compare method.

Collections.sort(list, new Comparator() {
            public int compare(Object obj1, Object obj2) {
                if(obj1 == null || obj2 == null){
                    throw new NullPointerException("compareTo: Argument passed is null");
                Book book1 = (Book) obj1;
                Book book2 = (Book) obj2;
                return book1.isbn - book2.isbn;


Second Method

You define a class that implements Comparator like as below.

class BookComparator implements Comparator{
    public int compare(Object book1, Object book2){
        int b1= ((Book)book1).isbn;        
        int b2= ((Book)book2).isbn;
        if(b1> b2)
            return 1;
        else if(b1< b2)
            return -1;
            return 0;    

And use this newly defined comparator class as an argument to Collections.sort.

Arrays.sort(list, new BookComparator ());

Good reasons to use Comparator interface

  • I do not have permissions to edit the Book class.
  • Book class already implements Comparable interface, but I want to sort the objects using a different criteria
  • I want to have more than 1 criterias to sort the objects in different orders.

Reasons to implement Comparable interface

  • I want my class to have a default sorting criteria that can be used by the users of my class
  • Usually, one would like to sort the objects based on primary key

Few good links on this topic are here

Best practices in JDBC Connection

JDBC Connection Scope

How should your application manage the life cycle of JDBC connections? Asked another way, this question really asks – what is the scope of the JDBC connection object within your application? Let’s consider a servlet that performs JDBC access. One possibility is to define the connection with servlet scope as follows.

import java.sql.*;

public class JDBCServlet extends HttpServlet {

    private Connection connection;

    public void init(ServletConfig c) throws ServletException {
      //Open the connection here

    public void destroy() {
     //Close the connection here

    public void doGet (HttpServletRequest req, HttpServletResponse res) throws ServletException { 
      //Use the connection here
      Statement stmt = connection.createStatement();
      //do JDBC work.

Using this approach the servlet creates a JDBC connection when it is loaded and destroys it when it is unloaded. The doGet() method has immediate access to the connection since it has servlet scope. However the database connection is kept open for the entire lifetime of the servlet and that the database will have to retain an open connection for every user that is connected to your application. If your application supports a large number of concurrent users its scalability will be severely limited!

Method Scope Connections

To avoid the long life time of the JDBC connection in the above example we can change the connection to have method scope as follows.

public class JDBCServlet extends HttpServlet {

  private Connection getConnection() throws SQLException {
    // create a JDBC connection

  public void doGet (HttpServletRequest req, HttpServletResponse res) throws ServletException { 
    try {
      Connection connection = getConnection();
    catch (SQLException sqlException) {

This approach represents a significant improvement over our first example because now the connection’s life time is reduced to the time it takes to execute doGet(). The number of connections to the back end database at any instant is reduced to the number of users who are concurrently executing doGet(). However this example will create and destroy a lot more connections than the first example and this could easily become a performance problem.

In order to retain the advantages of a method scoped connection but reduce the performance hit of creating and destroying a large number of connections we now utilize connection pooling to arrive at our finished example that illustrates the best practices of connecting pool usage.

import java.sql.*;
import javax.sql.*;

public class JDBCServlet extends HttpServlet {

  private DataSource datasource;

  public void init(ServletConfig config) throws ServletException {
    try {
      // Look up the JNDI data source only once at init time
      Context envCtx = (Context) new InitialContext().lookup("java:comp/env");
      datasource = (DataSource) envCtx.lookup("jdbc/MyDataSource");
    catch (NamingException e) {

  private Connection getConnection() throws SQLException {
    return datasource.getConnection();

  public void doGet (HttpServletRequest req, HttpServletResponse res) throws ServletException {
    Connection connection=null;
    try {
      connection = getConnection();
    catch (SQLException sqlException) {
    finally {
      if (connection != null) 
        try {connection.close();} catch (SQLException e) {}

This approach uses the connection only for the minimum time the servlet requires it and also avoids creating and destroying a large number of physical database connections. The connection best practices that we have used are:

A JNDI datasource is used as a factory for connections. The JNDI datasource is instantiated only once in init() since JNDI lookup can also be slow. JNDI should be configured so that the bound datasource implements connecting pooling. Connections issued from the pooling datasource will be returned to the pool when closed.

We have moved the connection.close() into a finally block to ensure that the connection is closed even if an exception occurs during the doGet() JDBC processing. This practice is essential when using a connection pool. If a connection is not closed it will never be returned to the connection pool and become available for reuse. A finally block can also guarantee the closure of resources attached to JDBC statements and result sets when unexpected exceptions occur. Just call close() on these objects also.

For More details :