1.Request

4.Transport

There are five types of contexts in the hierarchy, which have been listed below with a brief explanation:

ConfigurationContext: This is the run-time representation of whole system. To start an Axis2 system, we need to have configuration context. The lifetime of configuration context will be the lifetime of the system. So, if we store some state (a property) it will last forever (until system shutdown).
ServiceGroupContext: In Axis2, we can deploy multiple services together as a service group. Then, the run-time representation of that is called ServiceGroupContext.
ServiceContext: This represents the run time of one service. The context lifetime will be the lifetime of the session. There can be one or many service contexts in the system, depending on the session scope of the corresponding service.
OperationContext: This context represents the lifetime of an MEP (Message Exchange Pattern). The lifetime of an operation context is, usually less than the lifetime of the ServiceContext.
MessageContext: The lifetime of an incoming message is represented by the message context. If two handlers in a given execution chain want to share data, then the best way to store them is in message context. One OperationContext may have one or more MessageContexts.

Request Session Scope

Request session scope is the default session scope in Axis2. When we deploy a service without knowing anything about session management, then our service will be deployed in request session scope. The lifetime of this session is limited to the method invocation lifetime, or request processing time. When we deploy a service in request scope, it simply means that we are not going to worry about the session management at all. So it is not like session management at all.

SOAP Session Scope

The idea of a SOAP session is to have a transport-independent way of managing session between two SOAP nodes, obviously between the client and the server. Here, Axis2 uses SOAP headers in order to manage the session. SOAP session scope has slightly longer lifetime as compared to a request session scope, and deploying a service in a SOAP session requires changing services.xml as well. Managing SOAP session requires both the client and the service to be aware of the sessions, that is, the client has to send the session-related data if it wants to access the same session, and the service has to validate the user using session-related data.

Transport Session Scope

In the case of Transport Session, Axis2 uses transport-related session management techniques to manage session. As an example, in the case of HTTP, it uses HTTP cookies to manage session. Then the lifetime of the session is controlled by the transport session and not by Axis2. What Axis2 does is store service context and ServiceGroupContext in the transport session object so that the service can access those contexts, as long as the session lives.

One of the key advantages that the Transport Session has over other sessions is that we can talk to multiple service groups within one transport session. In a SOAP session, we don’t have a way to communicate between two service groups, but with the transport session, we have that capability too. In this case, the number of service instances created depends on the number of transport sessions created.

Application Scope

Application scope has the longest lifetime as compared to all the others, and the lifetime of the application session is equal to the lifetime of the system. If we deploy a service in application scope, we will find that there is only one instance of the service implementation class. In addition to that, there will be only one ServiceContext for the deployed service. Considering the memory footprint, in the Axis2 world, it is better to deploy the service in application scope, if we don’t want to manage the session.

Reference : Quickstart Apache Axis2
by Deepal Jayasinghe

Directed by Prabhu Deva
Produced by Karunamoorthy, Arun Pandian
Written by Prabhu Deva
Starring
Vijay
Nayanthara
Vadivel
Biju Menon
Prakash Raj
Music by Devi Sri Prasad
Cinematography Ravi Varman

Devi Sri Prasad has already composed a music album for vijay and is well known for his peppy and energetic music. Sachin had really good music as the focus was on the story and not Vijay the actor. The script is different this time around as the music director has tried to score the music for a typical Vijay movie.If I were to rate the music director on that basis he has done a commendable job.

Dheemthanakka Thillana (Devi Sri Prasad , Divya)
Devi Sri Prasad is all about the energy he brings to the table and this song is a classic example. This is a fast paced song with a catchy tune. It is not electrifying by any means but the heavy voice of Divya and Devi Sri Prasad seems to fit the bill perfectly for this song.

Jalsa ( Baba Sehgal , Rita)
Baba Sehgal is an iconic Indian rapper who was famous in the mid 1990s. I think this is the first time he has sung a tamil song. He has done a decent job and the song is tailor made for his voice. The heavy beats in the middle are interesting. Baba gets to Rap a bit as well . Rita does not have a lot to do in this Sehgal dominated song.

Nee Kobapattal (Sagar)
The only slow song in the album. There is no dearth of orchestration even in this song . Sagar seems to be an exact replica of Devi Sri Prasad as his voice is very similar to that of the music director. The news is that Devi Sri Prasad has a twin named Sagar who is currently a playback singer.This is just an average song which passes muster.

Vada Maapilley (Tippu , Rita , Vadivel)
A rhythmic song with interesting tune and beats. The song seems to be inspired from the ganna songs from the 80’s. The song definitely reminded me of the yesteryear block buster Surangini. I was not all that impressed but this might really interest the front benches and folks who like the gana genre.

Daddy Mummy (Divya)
The song starts with a nice piano interlude and transforms into a nice rhtymic song. The tune is very catchy and Divya’s voice is unique. The lyrics are simply horrible and are a huge let down.

Hey Rama ( Amalraj , Kovai Sarala)
This fast Kuthu Song has a very catchy tune. Kovai Sarala , the famous comdian is the surprise package. This is most likely when Vijay is introduced in the movie.

Are You Krazy (Divya)
Obviously this song is supposed to be funny and nothing else. There is nothing to review other than the fact that this piece could have been avoided.

Overall the album is decent and is strictly aimed at the actors fans. A genuine music lover will find this album average at the most.

Devi Sri Prasad has the talent to compose a much better album. That said he has delivered on the commercial front and the fast numbers will be a huge hit with the actor’s fans.

Android applications, like most mobile phone applications, are developed in a host-target development environment. In other words, you develop your application on a host computer (where resources are abundant), and download it to a target mobile phone for testing and ultimate use.

To write your own Android mobile phone applications, you’ll first need to collect the required tools and set up an appropriate development environment on your PC or Mac.

The Android SDK supports several different development environments. For this book we will focus on using Eclipse, because it is the best integrated with the SDK, and, hey, it’s free. No matter which operating system you are using, you will need essentially the same set of tools:

* The Eclipse Integrated Development Environment
* Sun’s Java Development Kit (JDK)
* The Android Software Developer’s Kit (SDK)
* A special Eclipse plug in: the Android Developer Tool (ADT)

Creating an Android Development Environment

The Android Software Development Kit supports Windows (XP and Vista), Linux (Ubuntu Dapper Drake), and Mac OS X (10.4.8 or later) as host development environments. Installation of the SDK is substantially the same for any of the operating systems, and most of this description applies equally to all of them. Where the procedure differs, we will clearly tell you what to do for each environment.

1.Install Eclipse:
2.Check for Required Plugins
3.Install JDK: The Android SDK requires JDK version 5 or version 6.
4. Install Android SDK: This is where you’d start if you already have the right versions of Eclipse and the JDK loaded. The Android SDK is distributed through Google’s code site, http://code.google.com/android/download.html.
5. Update Environment Variables: To make it easier to launch the Android tools, add the tools directory to your path.
6. Install the Android Plugin (ADT): https://dl-ssl.google.com/android/eclipse.

Starting a New Android Application: HelloWorld

Several components are needed to build an Android application. Fortunately, the Eclipse IDE with the Android plug-in automates a lot of the work needed to create and maintain these components. We will start by using the IDE to create a project for our application. Start up Eclipse and select “File -> New -> Project…” from the menu bar (be sure to select “Project…,” not “Java Project”).

Select “Android Project” and click “Next” to get the “New Android Project” dialog box.

We’ll use “HelloWorld” as the name for both the Project and the Application. You don’t need to change the button or checkbox selections, and we’ll use the package name com.oreilly.helloworld as shown.

Every Android application has to have at least one Activity (an executable that usually has a user interface), so let’s say we’re going to include an Activity called HelloWorldActivity, as shown in the dialog box. Click “Finish,” and the Android Development Kit does a number of things for you, to make your life easier as a developer. In [figure to come], I’ve expanded the tree in the Package Explorer window to show some of the files and directories that the ADK created.

The ADK created a HelloWorld directory in the default Eclipse workspace for your project. It also created subdirectories for your source files (.src), references to the Android Library, assets, resources (.res), and a manifest file (AndoidManifest.xml). In each of the subdirectories it created another level of subdirectories as appropriate. Let’s take a quick look at them:

Sources (under .src)

* Contains a directory structure that corresponds to the package name you gave for your application: in this case, com.android.helloworld.
*Contains a Java template for the Activity you indicated was in the application (HelloWorldActivity) and a directory of resource references (R.java). We’ll come back to R.java later.

Android Library

This is just what it says. If you like, you can expand the android.jar tree and see the names of the modules included in the library. This is where your application will go for Android library references.

assets

Files you want to bundle with your application. We won’t have any for HelloWorld.

Resources (under .res)

* Drawable resources are any images, bitmaps, etc. that you need for your application. For HelloWorld, the ADK has supplied us with the default Android icon, and that’s all we’ll need.
* Layout resources tell Android how to arrange items on the screen when the application runs. These resources are XML files that give you quite a bit of freedom in laying out the screen for different purposes. For HelloWorld, we’ll just use the defaults generated by the ADK
* Values are constants, strings, etc. available for use by your application. Keeping them outside the sources makes it easier to customize the application, such as adapting it for different languages.

Manifest (AndroidManifest.xml)

This is another XML file that tells the Android build system what it needs to know to build and package your application so it can be installed on an Android phone or the emulator. This file has its own specialized editor, which we’ll describe as we get to more complicated applications.

Double Click on HelloWorldActivity.java
Looking quickly at the template code that the ADK has provided for us, we can note several things:

*The ADK has included the package reference we asked for, which is consistent with the directory structure it created.
*It has also created a (collapsed) set of imports for the library references it knows we need.
*It created a class definition for the Activity we said we wanted (HelloWorldActivity) including a method called OnCreate.

For the moment, don’t worry about the parameter passed into OnCreate. The icicle Bundle is a way of passing data between activities and storing data between instantiations of the same Activity. We won’t need to use this for HelloWorld.
* One special line of code has been included in OnCreate:

setContentView (R.layout.main);

Remember that Android uses layouts to define screen layouts on the target, and that main.xml was the name of the default layout file that the ADK created for us under .res/layout. The R.java file is generated automatically and contains java references for each of the resources under .res. You will never need to edit the R.java file by hand— the ADK takes care of it as you add, change or delete resources.

Double Click on main.xml
Again, let’s look at the key features of this template code:

* Like any other XML file, this one starts with a reference to the XML version and encoding used.
* LinearLayout is one of the screen layout formats provided by the ADK. There are several others, which can be combined hierarchically to create very complex screen layouts. For our purposes, a simple linear layout is fine.

Within the LinearLayout definition:
o The code:

xmlns:android=”http://schemas.android.com/apk/res/android”

identifies the XML schema being used.
o The code:

android:orientation=”vertical”
android:layout_width=”fill_parent”
android:layout_height=”fill_parent”

defines an orientation, width and height for the entire scope of the layout.
*TextView describes how to handle text within…. It resembles the text boxes you may have encountered when programming in other graphical environments.

Within the TextView definition:
o The code:

android:layout_width=”fill_parent”
android:layout_height=”wrap_content”

a width and height for the TextView box.
o The code:

android:text=”Hello World, HelloWorldActivity”

provides some text to display in the TextView. By a stroke of luck, the ADK has already included text that is almost what we wanted to display anyway. Just to show them who’s boss, change the android:text line to say “Hello, Android!”, or something else equally clever:

android:text=”Hello, Android!”

if you edit the file, save it either from the Eclipse File menu (File -> Save) or by clicking on the diskette icon in the menu bar.

Believe it or not, we’re done. We don’t have to write a single line of Java to create this application.

From the Eclipse menu bar, select Run -> Run. A “Run As” dialog box will pop up. Select “Android Application” from the list and you can see your first Android Application.

Reference : Android Application Development, 1st Edition
By: Rick Rogers

The original source is here : http://www.javaworld.com/javaworld/jw-07-2008/jw-07-harmful-idioms.html

Four harmful Java idioms, and how to fix them
Rewrite convention and optimize your code for maintainability

By John O’Hanley, JavaWorld.com, 07/29/08

Idioms in any programming language help you get your bearings and provide structure when you start writing code. But, as John O’Hanley points out, some Java programming idioms are both widespread and harmful, having a negative influence on code maintainability. Read on if you’re ready to break with convention, rewrite four harmful Java idioms, and optimize your code for maintainability.

Coding idioms exist to make life easier for programmers — in particular for maintenance programmers, who are usually reading code produced by someone else. Coding conventions are fundamentally about showing compassion for these maintenance workers; the conventions you choose should allow them to read, understand, and use your code as quickly and as painlessly as possible. The more you optimize your coding style for the mental experience of those who will be maintaining your code, the more compassionate your code becomes, and the more quickly it will be understood.

Similarly, higher-level idioms (immutability and package structure, for example) aim to both improve the design and make code easier to understand. In fact, some might say that “improving the design” and “making the code easier to understand” are, in the end, one and the same thing.

In this article, you’ll see that some popular idioms should be changed in favor of alternatives that are demonstrably more compassionate towards the reader. One might argue that any idioms that are already widespread should never be abandoned, simply because they are expected by most readers. However, reader expectations are only one part of the equation, and they shouldn’t necessarily override all other considerations. The fundamental question should not be “Does the reader expect this?” but rather “How fast will the reader understand it?” I’ll approach four different problematic — but common! — idioms in turn.
Local variables, method arguments, and fields: Which is which?

When trying to understand code, a reader often needs to answer a simple question: Where did this data come from? In particular, when trying to understand a method, a reader needs to know which items are local variables, which are fields, and which are method arguments. To exercise compassion for your reader, and to absolutely minimize the effort required to understand your code, it’s likely best to use a simple naming convention to distinguish between these three cases.

Many organizations qualify field variables with this to distinguish them from other kinds of variables. That’s good, but it doesn’t go far enough: there should be a convention to distinguish method arguments as well. The logic that justifies naming conventions for fields also applies to method arguments, and for exactly the same reasons.

Listing 1 offers an example of an equals() method that does not distinguish between the three kinds of variables.
Listing 1. A method that doesn’t distinguish between variable types

public boolean equals (Object arg) {
if (! (arg instanceof Range)) return false;
Range other = (Range) arg;
return start.equals(other.start) && end.equals(other.end);
}

The French writer Marcel Proust was famous for analyzing human experience to microscopic levels. How would a modern-day Proust describe the experience of reading this equals() method? When you try to understand it, you experience a small amount of discomfort when you encounter start, because it’s suddenly referenced out of the blue. Your brain hits a speed bump as it encounters something it hasn’t seen before — Uh oh, what’s this? After a moment, through a tedious process of elimination (the length of which is proportional to the size of the method), you will eventually figure out that start is actually a field. The same sort of trivial and tedious reasoning is also needed to distinguish method arguments from other types of data.

Listing 1 isn’t very long. If the method were larger, then the effort necessary to understand it would be increased as well.

Why make the reader experience this jolt, this moment of confusion, however slight? Why not spare your readers the unpleasant experience of not understanding something immediately? Why force them to figure it out? If a simple naming convention can allow the reader to distinguish the three kinds of variables almost unconsciously, then shouldn’t it be used? As Steve McConnell says in Code Complete, “It’s OK to figure out murder mysteries, but you shouldn’t need to figure out code. You should be able to read it.”

One might argue that this is why fields should be declared at the start of a class. But that isn’t a good solution, because it forces the reader to either memorize field names or perform a lookup operation in a distant section of the class. Either option makes the reader do more work. And the whole point is to exercise maximal compassion for the readers, and let them read and understand your code with minimal effort.

Listing 2 contains the example code from Listing 1, rewritten. It uses a naming convention in which:

* Method arguments are prefixed with a
* Fields are prefixed with f
* Local variables have no prefix at all

Listing 2. Variable types are now clearly distinguished

public boolean equals (Object aOther) {
if (! (aOther instanceof Range)) return false;
Range other = (Range) aOther;
return fStart.equals(other.fStart) && fEnd.equals(other.fEnd);
}

You might object to the style on display in Listing 2, protesting that “Hungarian notation is obsolete.” But that objection is erroneous: Hungarian notation specifies type information. The above naming convention says nothing about type. Rather, it distinguishes between fields, arguments, and local variables. These are two completely different concepts.

The idea of using naming conventions in this way may seem trivial, but it isn’t: when such conventions are used throughout your code, the effort needed to understand it is significantly reduced, because you can perform more operations without thinking about them.

“By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and in effect increases the mental power of the race. Before the introduction of the Arabic notation, multiplication was difficult, and the division even of integers called into play the highest mathematical faculties. Probably nothing in the modern world would have more astonished a Greek mathematician than to learn that … a large proportion of the population of Western Europe could perform the operation of division for the largest numbers. This fact would have seemed to him a sheer impossibility … Our modern power of easy reckoning with decimal fractions is the almost miraculous result of the gradual discovery of a perfect notation.”
— Alfred North Whitehead, An Introduction To Mathematics

Package-by-layer: Preventing the use of package-private scope

A common way of dividing up an application is package-by-layer:

* com.blah.action
* com.blah.dao
* com.blah.model
* com.blah.util

In other words, items belonging to any one feature are spread out over different packages, according to what might be called behavioral categories. Because the items in each feature need to be visible to each other, this implies that nearly all of the classes in such an application are public.

In effect, this common packaging style throws package-private scope out the window. Package-private scope isn’t simply ignored; you’re actually prevented from using it. Now, package-private scope was chosen as the default scope by the designers of the Java programming language. This choice was made, of course, to push you gently in the direction of better design — to start with minimal scope, and increase it only if necessary. (This is the usual “minimize ripple effects by keeping secrets” technique, an idea at the very heart of object programming.) For some strange reason, a significant part of the Java community has, by adopting the package-by-layer convention, rejected an important way of minimizing scope. This seems unjustified.

An alternate style is package-by-feature:

* com.blah.painting
* com.blah.buyer
* com.blah.seller
* com.blah.auction
* com.blah.webmaster
* com.blah.useraccess
* com.blah.util

Here, items are not grouped according to their behavioral style. Instead, the behavior of individual classes is treated as an implementation detail, and classes are grouped according to the highest possible level of abstraction — the level of the feature — wherein all items related to a feature (and only to that feature) reside in one and the same package. This is not a revolutionary or heretical idea; this is exactly what packages were created for in the first place.

For example, in a Web application, the com.blah.painting package might consist of these items:

* Painting.java: A model object
* PaintingDAO.java: A data access object
* PaintingAction.java: A controller or action object
* statements.sql: The SQL statements used by the DAO
* view.jsp: The JSP used to render the result to the user

It’s important to note that, in this style, each package should contain all items related to a feature (and only that feature). In particular, the package may contain files other than Java source code. In package-by-feature, the ideal is to pass the deletion test: you should be able to delete a feature by deleting a single directory, without leaving behind any cruft.

The benefits of this style over package-by-layer are compelling:

*

Packages have much higher cohesion and modularity. Coupling between packages is minimized.
*

Code is much more self-documenting. The reader gets a general idea of what features are included just by reading the package names. In Code Complete, Steve McConnell refers to self-documenting code as “the Holy Grail of legibility.”
*

The design still honors the idea of separation of layers, simply by using separate classes within each feature.
*

Related items are in the same place. There is no need to navigate around the source tree to edit closely related items.
*

Items are package-private by default, as they should be. If an item needs to be visible from another package, then it’s changed to public. (Note that changing a class to public does not mean that all of its members should be made public as well; there can be a mixture of public and package-private members in the same class.)
*

Deleting a feature is often as simple as deleting a single item: a directory.
*

There are fewer items in each package, and the overall package structure evolves more naturally. For example, if a package gets too large, then it can be refactored as desired into two or more new packages. The alternative package-by-layer style, however, does not scale or evolve in this way at all: its packages contain an arbitrarily large number of classes, and you cannot easily refactor the package structure.

Some frameworks promote a package-by-layer style with conventional package names as a purported advantage: because conventional package names are used, programmers always know where to navigate to find items. But why force them to navigate at all? With the alternative package-by-feature style, such tedious navigation is usually not needed, so it entirely transcends the need for any such naming convention.

“The single most important factor that distinguishes a well-designed module from a poorly designed one is the degree to which the module hides its internal data and other implementation details from other modules.”
— Joshua Bloch, Effective Java

JavaBeans: Why use them when immutables will do?

Immutable objects are objects that do not change state (their data, in other words) after construction. Martin Odersky, the principal creator of Scala, has recently praised the qualities of immutables. In Effective Java, Joshua Bloch makes a very convincing case in favor of strongly preferring immutable objects. To summarize Bloch’s points, immutables:

* Are simple
* Are thread-safe, and require no synchronization
* Can be shared freely
* Never need to be defensively copied
* Never need a copy constructor, or a clone() method
* Make good building blocks for other classes
* Make good Map keys and Set elements
* Have failure atomicity — that is, they cannot be left in an invalid state when an error occurs

“Classes should be immutable unless there is a very good reason for making them mutable,” says Bloch. But his advice seems to have been largely ignored. In place of immutable objects, most applications use JavaBeans (or something similar) instead. JavaBean objects are significantly more complex than immutables. Their complexity arises from their large state space. In a rough sense, you might think of a JavaBean as the diametric opposite of an immutable object: it allows maximal mutability.

It’s common to use JavaBeans to model database records. Is that an appropriate design? Think of it this way: if you were modeling a row from a database ResultSet, without any preconceptions or framework constraints whatsoever, what would your design be like? Would it be similar to a JavaBean, or would it be significantly different?

I think it would be enormously different:

*

It would likely not include a no-argument constructor, as such constructors carry no data. Does it make sense to model a database ResultSet by creating objects that by design can carry no data, even temporarily? Does a no-argument constructor suggest itself naturally to the mind for this domain? No, it doesn’t. (It’s true that data is often optional, but how often are all columns in a ResultSet optional?)
*

It would likely not have anything to say about events and listeners.
*

It would likely not force you to use mutable objects. In Web applications in particular, model objects often exist only for the duration of a single request. Such objects aren’t long-lived, and don’t need to change state in response to user actions.
*

It would likely define a data validation mechanism. Such validation is one of the most important features of database apps, and should be supported directly in the model. (Remember the first thing you learned about objects: an object encapsulates both data and operations on the data. In this case, the operations are the validations.)
*

The validation mechanism would allow for reporting errors to the end user.

The JavaBeans specification was created for a very particular problem domain: that of manipulating graphical widgets at design time. The specification makes absolutely no mention of databases, because it was not created with databases in mind. As a result, it’s not surprising that JavaBeans aren’t a very natural choice for the problem of modeling database records.

From a practical perspective, many widely-used frameworks require application programmers to use JavaBeans (or something similar) to model database records. This is deeply unfortunate, because it doesn’t allow programmers to take advantage of the many positive qualities of immutable objects.

Private members: Why put them up front?

Old Hollywood movies usually start with the credits — all of the credits. In a similar way, most Java classes place implementation details (the private members) first. Listing 3 shows a typical example of this style.
Listing 3. Private members, listed up front

public class OilWell implements EnergySource {
private Long id;
private String name;
private String location;
private Date discoveryDate;
private Long totalReserves;
private Long productionToDate;

public Long getId() {
return id;
}
public void setId(Long id) {
this.id = id;
}

//..elided
}

However, placing private items last, not first, seems to show more compassion for the reader. When trying to understand something — anything — you should move from the general to the specific. More precisely, you should move from a higher to a lower level of abstraction. If you do the reverse, then initially the reader will likely not know the point of the whole thing, or grasp how things work together, and will be confused by trying to remember a number of potentially disconnected facts.

The whole point of abstraction is to allow you to ignore details. The higher the level of abstraction, the more details you can ignore. The more details the readers of a class can ignore, the happier they are. Holding many details in your head is painful, so fewer details are better. Thus, placing private items last seems more compassionate, as it puts off details that may not be necessary at all for the reader’s current task (whatever that may be).

Originally, the C++ programming culture placed private items first, just as in Java. However, unlike the Java community, the C++ community quickly came to realize that this was an unhelpful convention, and it is now reversed. Here is a comment from a typical C++ style guide:

Notice that the public interface is placed first in the class, protected next, and private last. The reasons are:

* programmers should care about a class’s interface more than implementation
* when programmers need to use a class they need the interface not the implementation

It makes sense then to have the interface first. Placing implementation, the private section, first, is a historical accident, as the first examples used the private-first layout. Over time emphasis has switched, de-emphasizing a class’s interface over implementation details.

Similarly, the Imperial College London C++ Style Guide says, “By placing the public section first, everything that is of interest to a user is gathered in the beginning of the class definition. The protected section may be of interest to designers when considering inheriting from the class. The private section contains details that should have the least general interest.”

One might object that that readers should use Javadoc when trying to understand a class, and not the source code. This argument doesn’t hold, however, because Javadoc includes no information regarding implementation details. When maintaining a class, a programmer clearly needs access to the source code.

For all kinds of technical documentation, it’s commonplace to put high-level information at the start — the table of contents of a book, for instance, or the abstract of an academic paper. Why should a Java class be an exception to this rule? Placing private members first just seems like a bad habit waiting to be broken. The reason it exists in the first place is likely early coding style documents, such as the Coding Conventions published by Sun. As Joshua Bloch noted, “I wouldn’t take that document [Sun's Coding Conventions] too seriously. It is not actively maintained or used at Sun.”

It seems best to arrange code to imitate the same order used by Javadoc: first the constructors, then non-private methods, and finally private fields and methods. That’s the only style in which the reader moves naturally from a higher to a lower level of abstraction.
In conclusion

I have argued in this article that four common Java idioms should be modified. The ultimate justification for such changes is that they will make code demonstrably easier to read, understand, and use — and, in the process, they will exhibit more compassion for the mental experience of the reader. In the case of immutability and packaging style, they will also nudge you in the direction of improved design.

In summary, I suggest that the following idioms should be favored as the preferred style:

* Use a naming convention to distinguish three kinds of data, not two: local variables, fields, and method arguments.
* Prefer the package-by-feature style over package-by-layer.
* Prefer immutable objects over JavaBeans.
* Order items in a class in terms of decreasing scope, with private items appearing last.

If the arguments presented in this article are correct, then they lead to a question: Why do harmful idioms still persist in Java programming culture, after so many years? In answer to that question, I would offer the following speculation. Style guides and other tools published in the early years of Java didn’t have the benefit of long experience. They got most things right, but a few things wrong. This is completely natural, and doesn’t reflect poorly on their creators. Some of these items, which were published by Sun Microsystems, were very widely imitated. They had a very strong influence, and were often treated as authoritative. Perhaps they were treated with a little too much deference.

The few harmful idioms that were created in the early days of Java have persisted because they become popular, ingrained habits — and perhaps because of a little bit of consensus trance or groupthink, wherein the fact that something is popular or treated as authoritative often overrides any opposing viewpoint.

Will Java programming culture gradually change these bad habits, or will they persist, in spite of their defects? My guess is that, unfortunately, they will remain a part of Java programming culture. But I would love to be proved wrong!

Please click on the link below to share your thoughts :

Is Java the best programming language ?

mvn eclipse:eclipse -DdownloadSources=true

This will set up the eclipse environment and also download the source for the jar files.

mvn clean install war:inplace

This will create a open war inside the target directory. This is very useful to modify non-java resources.

mvn clean install  -Dmaven.test.skip=true

This will skip the unit tests . It helps to speed up the install but it is a bad practice.

PUBLIC "-//Hibernate/Hibernate Mapping DTD//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

import org.hibernate.Filter;
import org.hibernate.Query;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.Transaction;

import org.hibernate.cfg.Configuration;

public class SimpleFilterExample {
public static void main (String args[]) {
SessionFactory factory =
new Configuration().configure().buildSessionFactory();
Session session = factory.openSession();

//insert the users
insertUser(”ray”,true,session);
insertUser(”jason”,true,session);
insertUser(”beth”,false,session);
insertUser(”judy”,false,session);
insertUser(”rob”,false,session);

//Show all users
System.out.println(”===ALL USERS===”);
displayUsers(session);

//Show activated users
Filter filter = session.enableFilter(”activatedFilter”);
filter.setParameter(”activatedParam”,new Boolean(true));
System.out.println(”===ACTIVATED USERS===”);
displayUsers(session);

//Show nonactivated users
filter.setParameter(”activatedParam”,new Boolean(false));
System.out.println(”===NON-ACTIVATED USERS===”);
displayUsers(session);

session.close();
}

public static void displayUsers(Session session) {
session.beginTransaction();
Query query = session.createQuery(”from User”);
Iterator results = query.iterate();
while (results.hasNext())
{
User user = (User) results.next();
System.out.print(user.getUsername() + ” is “);
if (user.isActivated())
{
System.out.println(”activated.”);
}
else
{
System.out.println(”not activated.”);
}
}

session.getTransaction().commit();
}

public static void insertUser(String name, boolean activated, Session session) {
session.beginTransaction();

User user = new User();
user.setUsername(name);
user.setActivated(activated);
session.save(user);

session.getTransaction().commit();
}
}

The natural and obvious answer is to have a cache at the client end of the database connection. Hibernateprovides one cache (the first-level cache) through which all requests must pass. A second-level cache is optional and configurable.

The L1 cache ensures that within a session the request for a object from the database always returns the same object instance hence preventing the object from being reloaded. You can always use object.evict() to discard the object and force a reload.To discard all objects in a session you can issue session.clear().This can also be called called a Java Virtual Machine (JVM) or SessionFactory-level class. . If you have a second-level cache at the SessionFactory level, the application objects are cached in a manner where they are available across sessions.

The L2 cache also called as query cache is external to hibernate . Hibernate provides a pluggable interface for the L2 cache. This allows a cache to be shared between applications on the same machine or even between multiple applications on multiple machines. The L2 cache will not be able to react to changes made by an external application so you have to be careful not to lose the state of the data. Also a distributed cache creates lot of network traffic and takes up memory as well.

Java threads do not timeout when there is a deadlock so don’t share sessions between different threads. If you absolutely must maintain an instance for a longer duration, maintain the instance within a ThreadLocal object. For most purposes, however, the lightweight nature of the Session object makes it practical to construct, use, and destroy an instance, rather than to store a session.

Some of the widely used L2 cache implementations are

EHCache
An in-process cache which is not cluster safe but supports Query Cache. It can use memory as well as disk.

OSCache
An in-process cache which is not cluster safe but supports Query Cache. It can use memory as well as disk.

SwarmCache
A multicast distributed cache which is cluster safe(clustered invalidation) but does not support Query Cache.

TreeCache
A multicast distributed transactional cache which is cluster safe but does not support Query Cache.

Configuration of EH Cache

When the objects being cached need to be updated, the read-write usage mechanism is an appropriate option to choose. If you use database imports or have an alternate way to update the database this option will not be suitable. It becomes even more difficult if the cache is clustered. The database has to be locked for the cache and the database to be in sync.

The nonstrict read-write cache is the same as read write except that it writes to the database occasionally.

The following properties are available in the Hibernate Configuration files to handle cache setup:

hibernate.cache.use_minimal_puts: Optimizes second-level cache operation to minimize writes, at the cost of more frequent reads (useful for clustered caches). Possible values are true and false.

hibernate.cache.use_query_cache: Enables the query cache. The query cache is disabled by default. Possible values are true and false.

Example
Session session = SessionFactory.openSession();
Query query = session.createQuery("from Users");
query.setCacheable(true);
List users = query.list();
SessionFactory.closeSession();

To explictly use EHCache :
Add this property to the hibernate .cfg.xml

<property name="hibernate.cache.provider_class">net.sf.ehcache.hibernate
.Provider</property>

Create a file ehcache.xml and make sure it is available in the classpath

<ehcache>

    <diskStore path="java.io.tmpdir"/>

    <defaultCache
        maxElementsInMemory="1000"
        eternal="false"
        timeToIdleSeconds="120"
        timeToLiveSeconds="120"
        overflowToDisk="true"
        />

    <cache name="example.survey.Survey"
        maxElementsInMemory="1000"
        eternal="false"
        timeToIdleSeconds="3600"
        overflowToDisk="true"
        />

    <cache name="example.survey"
        maxElementsInMemory="1000"
        eternal="true"
        overflowToDisk="true"
        />
</ehcache>

timeToIdleSeconds specifies how long an object can be idle before it expires. The timeToLiveSecondsvalue specifies the overall length of time that an object can be cached before being expired.

When not to use Cache
1) When the database can be modified by an external source. You may be able to deal with this issue by specifying a version or timestamp property for your object and using the Session.lock() method to verify that the object hasn’t been changed.
2)Caching only helps when the same data is used multiple times within the expiry time period. There is no point in caching data which expires before it can be used.
3)In financial applications where auditing is very important.
4)When the dataset is too large
5) when you don’t know what the hell you are doing

AutoFlushEventListener

DeleteEventListener

DirtyCheckEventListener

EvictEventListener

FlushEventListener

FlushEntityEventListener

LoadEventListener

InitializeCollectionEventListener

LockEventListener

MergeEventListener

PersistEventListener

PostDeleteEventListener

PostInsertEventListener

PostLoadEventListener

PostUpdateEventListener

PreDeleteEventListener

PreInsertEventListener

PreLoadEventListener

PreUpdateEventListener

RefreshEventListener

ReplicateEventListener

SaveOrUpdateEventListener
Let us consider the following example

public class EventExample {
public static void main(String[] args) {
Configuration config = new Configuration();

// Apply this event listener (programmatically)
config.setListener("save-update", new BookingSaveOrUpdateEventListener());

SessionFactory factory = config.configure().buildSessionFactory();
Session session = factory.openSession();

Transaction tx = session.beginTransaction();

// Make our bookings... seat R1 is NOT to be saved.
session.saveOrUpdate(new Booking("charles","R1"));
session.saveOrUpdate(new Booking("camilla","R2"));

// The confirmation letters should not be sent
// out until AFTER the commit completes.
tx.commit();
}
}

import java.io.Serializable;
import org.hibernate.HibernateException;
import org.hibernate.event.SaveOrUpdateEvent;
import org.hibernate.event.def.DefaultSaveOrUpdateEventListener;

public class BookingSaveOrUpdateEventListener
extends DefaultSaveOrUpdateEventListener
{
public Serializable onSaveOrUpdate(SaveOrUpdateEvent event)
throws HibernateException {
if( event.getObject() instanceof Booking) {
Booking booking = (Booking)event.getObject();
System.out.println("Preparing to book seat " + booking.getSeat());

if( booking.getSeat().equalsIgnoreCase("R1")) {
System.out.println("Royal box booked");
System.out.println("Conventional booking not recorded.");

// By returning null instead of invoking the
// default behavior‚ we prevent the invocation
// of saveOrUpdate on the Session from having
// any effect on the database!
return null;
}
}

// The default behavior:
return super.onSaveOrUpdate(event);
}
}

The objective of the listener is to prevent R1 from getting saved so the default behavior is overridden by the listener class.