Zero Turnaround time with javarebel

JavaRebel is a java agent which enables reloading changes made to java classes on the fly. It enables developers to work without redeploying or re-starting a container. It works in both the Java EE and SE environment.
A normal deployment cycle looks like
1) Make changes to your classes
2) Create the new archive
3) Touch the archive in the deployment environment
4) Restart application server/Redeploy application
5) Check the modifications
With JavaRebel, you can reduce the above steps to
1) Make changes to your classes
2) Background compilation
3) Check for modifications

For standard environments using java 5 and above, we need to add the following to the jvm path
-noverify -javaagent:/path/to/javarebel.jar

For an app-server environment, for JBoss 4.x, we need to add the following in the $JBOSS_HOME/bin/run.sh(%JBOSS_HOME%/bin/run.bat on windows), add the following
JAVA_OPTS="-noverify -javaagent:javarebel.jar $JAVA_OPTS"
or on Windows
set JAVA_OPTS= -noverify -javaagent:javarebel.jar %JAVA_OPTS%

Happy Non-Deployment :-)

New features in EJB 3.1

There are some key changes which are going to be part of EJB 3.1 . Some important changes are cataloged here
1) Session bean business interfaces are going to be optional. The intent is to bring the Session beans as close to POJO's. Another advantage is that the it makes using EJB 3.1 beans easier to use in Web Beans (JSR 299).
2) Singleton Beans - These are the middleware equivalent of the GOF singleton pattern. These can be used to store shared application scope data. Although there are alternatives for caching shared data, the issue with these solutions is that they lack services like thread management, security, transaction management etc. Singleton beans being Enterprise beans have these services provided by the container. All singleton methods are assumed to be thread-safe and transactional(@Required). Thread safety can be changed using @ConcurrencyAttribute and transaction demarcation can be done the standard way transaction demarcation and transaction attributes. Concurrency management can also be managed at the bean level using @ConcurrenyManagement(BEAN) and synchronizing on methods you want to be thread-safe
3) Timer service - The main enhancements is the ability to trigger EJB methods using a cron like scheduling using the @Schedule. The bean method can be triggered based on seconds till the level of year.
4) EJB packaging -- As of now, EJB's need to go as a separate jar file. A typical ear contains a separate ejb-jar for an EJB and a war for the web app. However for simple applications, it would be possible to place the EJB's directly in the war's WEB-INF/classes to simplify the packaging process.
5) Asynchronous invocation of session beans- Although MDB's provide the capability of using asynchronous invocations, it is an overkill for using for simple applications. You are forced to use messages and JMS even for very simple scenarios. With EJB 3.1, session beans can be invoked asynchronously.
6) EJB Lite -- a subset of the EJB features based on the Java EE 6 profiles(ref --http://weblogs.java.net/blog/robc/archive/2008/02/profiles_in_the_1.html).


External References
1. JSR 316: Java EE 6, http://jcp.org/en/jsr/detail?id=316.
2. JSR 318: Enterprise JavaBeans 3.1, http://jcp.org/en/jsr/detail?id=318.
3. JSR 299: Web Beans, http://jcp.org/en/jsr/detail?id=299.
4. Spring Pitchfork Project, http://static.interface21.com/projects/pitchfork/files/m4/docs/reference/html_single/.

Using the ternary operator

There are many scenarios i which developers have to narrow to a specific type based on a super type which is passed. The following code is what i have normally observed
Lets assume we have the following hierarchy

Class A {
...
}
Class B extends A {
...
...
}
Class C extends A{
...
...
}
Now someMethod takes A as a parameter and needs to narrow it to a specific type B or C
public void someMethod(A a){
A a1=null;
if(a instanceof B) {
a1=new B();
}
else{
a1=new C();
}
.....
//other stuff here
}
A better approach for brevity sake would be use the ternary operator
A a1= a instanceof B ? new B() : new C() ;
This reduces 4 lines to 1 which is some improvement.

Exception handling on a per thread basis

The following applies to Tiger and above. Prior to Tiger, an uncaught exception would propagate from a Thread to its ThreadGroup, propagate up to the root ThreadGroup and print the trace. To circumvent this, we can now implement a nested interface of the Thread class called Thread.UncaughtExceptionHandler. You can create your own implementation of this interface to handle uncaught exceptions.
Note - prior to Tiger, we would have to create our own ThreadGroup, assign any Thread we create to this ThreadGroup and handle the uncaught exception in the ThreadGroup ( a lot of shit for nothing of substance)

Autoboxing and Unboxing

Integer i1 = 256;
Integer i2 = 256;
if (i1 == i2) System.out.println("Equal!");
else System.out.println("Not equal!");
The output in this case would be "Not equal!" as these are two separate Integer objects,
so "==" returns false.
However, the following
Integer i1 =100;
Integer i2 = 100;
if (i1 == i2) System.out.println("Equal!");
else System.out.println("Not equal!");
will return "Equal!", Remember that int values from -127 to 127 are in that
range of immutable wrapper types, so the VM actually uses the same
object instance (and therefore memory address) for both i1 and i2. As a
result, == returns a true result.

Perfecting OO classes/methods

The following constraints help in writing better OO code
1) Use only one indention per method, if there is a need to indent again create another method and call that method from the first one.
2) Don't use else. Use the if condition to test the condition and exit the method if the condition is false. So every method tests for just one thing
3) Wrap all primitives and Strings to prevent primitive obsession. If you need to use a primitive, create a class to define its role.
4) Use only one dot per line. This prevents you from reaching deeply into objects to get to methods and fields and prevents breaking encapsulation.
5) Don't abbreviate names. Hence you spend less time thinking about method names. Thus have methods for Order like ship() rather than Order.shipOrder() ;
6) Keep entities small. No more than 50 lines per class and no more than 10 classes per package. This helps to keep classes concise and focused.
7) Don't use classes more than 2 instance variables. Difficult but then a lot of instance variables might warrant extracting a class.
8) Use first-class collections. In other words, any class that contains a collection should contain no other member variables. The idea is an extension of primitive obsession. If you need a class that’s a subsumes the collection, then write it that way.
9) Don’t use setters, getters, or properties. This is a radical approach to enforcing encapsulation. It also requires implementation of dependency injection approaches and adherence to the maxim “tell, don’t ask.”