Class Loaders

In a JVM, each class is loaded by some instance of a java.lang.ClassLoader. The ClassLoader class is located in the java.lang package and developers are free to subclass it to add their own functionality to class loading.

Whenever a new JVM is started by typing java MyMainClass, the "bootstrap class loader" is responsible for loading key Java classes like java.lang.Object and other runtime code into memory first. The runtime classes are packaged inside of the JRE\lib\rt.jar file. We cannot find the details of the bootstrap class loader in the Java documentation, since this is a native implementation. For the same reason, the behavior of the bootstrap class loader will also differ across JVMs.

In a related note, we will get null if we try to get the class loader of a core Java runtime class, like this:

    log(java.lang.String.class.getClassLoader()); 

Next comes the Java extension class loader. We can store extension libraries, those that provide features that go beyond the core Java runtime code, in the path given by the java.ext.dirs property. The ExtClassLoader is responsible for loading all .jar files kept in the java.ext.dirs path. A developer can add his or her own application .jar files or whatever libraries he or she might need to add to the classpath to this extension directory so that they will be loaded by the extension class loader.

The third and most important class loader from the developer perspective is the AppClassLoader. The application class loader is responsible for loading all of the classes kept in the path corresponding to the java.class.path system property.

"Understanding Extension Class Loading" in Sun's Java tutorial explains more on the above three class loader paths. Listed below are a few other class loaders in the JDK:

• java.net.URLClassLoader
• java.security.SecureClassLoader
• java.rmi.server.RMIClassLoader
• sun.applet.AppletClassLoader

java.lang.Thread, contains the method public ClassLoader getContextClassLoader(), which returns the context class loader for a particular thread. The context class loader is provided by the creator of the thread for use by code running in this thread when loading classes and resources. If it is not set, the default is the class loader context of the parent thread. The context class loader of the primordial thread is typically set to the class loader used to load the application.

transient and volatile in Java

Java defines two interesting type modifiers: transient and volatile. These modifiers are used to handle somewhat specialized situations.

When an instance variable is declared as transient, then its value need not persist when an object is stored. For example:

class T {

transient int a; // will not persist

int b; // will persist

}

Here, if an object of type T is written to a persistent storage area, the contents of a would not be saved, but the contents of b would. The volatile modifier tells the compiler that the variable modified by volatile can be changed unexpectedly by other parts of your program. One of these situations involves multithreaded programs. In a multithreaded program, sometimes, two or more threads share the same instance variable. For efficiency considerations, each thread can keep its own, private copy of such a shared variable. The real (or master) copy of the variable is updated at various times, such as when a synchronized method is entered. While this approach works fine, it may be inefficient at times. In some cases, all that really matters is that the master copy of a variable always reflects its current state. To ensure this, simply specify the variable as volatile, which tells the compiler that it must always use the master copy of a volatile variable (or, at least, always keep any private copies up to date with the master copy, and vice versa). Also, accesses to the master variable must be executed in the precise order in which they are executed on any private copy.

Hibernate

Advanced features

Caching solutions, transactions and other features Hibernate provides are not so easy to
implement. It is actually non sense to develop something which already exist.
Using Hibernate everything is there. You just have to use it.

How Hibernate works

What is nice and in my opinion an advantage over entity beans, hibernate starts from simple java
classes (Pojo = Plain Old Java Objects).

To use hibernate you will create a simple java class:

public class Bug
implements Serializable
{
private int hashValue = 0;
private java.lang.Integer id;
private java.lang.String title;
public Bug()
{
}
public Bug(java.lang.Integer fid)
{
this.setId(fid);
}
public java.lang.Integer getId() {
return id;
}
public void setId(java.lang.Integer id) {
this.id = id;
}
public java.lang.String getTitle() {
return title;
}
public void setTitle(java.lang.String title) {
this.title = title;
}
.............
Than you create a mapping file. The mapping file explains Hibernate which field in the class is
mapped to which field in the database.

And you start using your hibernate class.

Example to create a new entry in the database:

try {
Bug bug = new Bug();
bug.setTitle("Title");
bug.setTuserFk(tuser);
Transaction tx = session.beginTransaction();
session.save(bug);
tx.commit();
} catch (HibernateException e) {
e.printStackTrace();
}

The creation of the description file can be done with tools like MyEclipse. MyEclipse provides
functionality to create classes and description files directly from database tables.
Hibernate includes tools to
• generate Java classes from description files
• description files from existing database tables
• database tables from description files.

Hibernate

Why using Object Relational Mapping?

Better system architecture

When you include all functionality of your application and the access to the database
within your dialogs, you will have some severe disadvantages.

It is really difficult to reuse code. You will repeat code at many places. If you change
anything it is quite hard to find out all places where you have to add changes,
when you separate your dialogs from your logic and the logic from the persistence
mechanism you can more easily apply changes to one part without influencing the other
parts.

Reduce time for standard DB actions

Most queries in database development are simple “insert, update, delete” statements.
There is no need to develop all these tedious statements. Hibernate helps you to save time.
Loading classes from the database looks like

Query query = session.createQuery("select b from Bug as b");
for (Iterator iter = query.iterate(); iter.hasNext();) {
bugs.add((Bug) iter.next());
}
return bugs;

saving a class “bug” to the database looks like

session.update(bug);

Hibernate

Some primary information about hibernate:

Main features

Hibernate is a solution for object relational mapping and a persistence management
solution or persistent layer.

What you can imagine is probably that you have your application with some functions
(business logic) and you want to save data in a database. When you use Java all the
business logic normally works with objects of different class types. Your database tables
are not at all objects.

Hibernate provides a solution to map database tables to a class. It copies the database
data to a class. In the other direction it supports to save objects to the database. In this
process the object is transformed to one or more tables.

Saving data to a storage is called persistence. And the copying of tables to objects and
vice versa is called object relational mapping.