Eclipse Code Formatter – IntelliJ IDEA

When working with a team of developers spread across globe, one challenge is to maintain code formatting.

Most of teams using Eclipse as their primary IDE, rely on Eclipse code formatter that can be configured by enabling project specific setting and then adding /.settings directory to version control system. This directory contains org.eclipse.jdt.core.prefs which has formatting details.

Since these files are part of version control, all developers now has these settings file and formatting changes gets applied automatically on saving file.

But if you are an IDEA user, then there is was no way to use these Eclipse code formatting.

To make life somewhat easy, over the weekend I created a small plugin which basically let you use the Eclipse Code Formatter from IDEA. The main feature of this is that you can apply these on a Change List. Change List in IDEA is basically list of files that you have modified/created and are going to commit.

For more details visit project page – eclipse-code-formatter-on-change-list

The plugin is also available in IDEA plugin repository.


Java Map Interface Examples

Recently I was explaining someone about Java Map and various implementations that are available as part of JDK.

I had wrote a simple program to explain him that. Thought of putting it here. Below it is –

TreeMap – The map is sorted according to the natural ordering of its keys, or by a Comparator provided at map creation time, depending on which constructor is used. Below example you will notice that treeMap toString shows that entries are ordered by performing natural ordering on Int keys.

HashMap – This class makes no guarantees as to the order of the map. Uses object equality to check if key already exist in map and replace value if it exist. As in example while trying to put key11 as it equals with key1 value “One” is replaced with “Eleven”.

IdentityHashMap – Unlike above HashMap, this uses reference-equality in place of object-equality when comparing keys. As in following example even after key11 equals key1, but as their references are not equals so a new key/value is inserted.

LinkedHashMap – This implementation keeps track of order in which keys were inserted into the map. In below example you will notice that the toString shows entries in same order in which they were inserted. This also has another feature discussed next.

LRU Caching using LinkedHashMap – Another feature of LinkedHashMap is that it provide constructor to create a linked hash map whose order of iteration is the order in which its entries were last accessed, from least-recently accessed to most-recently (access-order). In following example, you will notice that when elements are inserted and none is accessed yet, the order of Entries is same as that of above example. But after accessing elements, you will notice that the entries order is changed based on when last it was accessed. Using this feature one can create a LRU(accessed) cache as shown in example. You will need to override removeEldestEntry method of LinkedHashMap and add your logic for caching. Each put operation will call this removeEldestEntry by passing least-recently-accessed element to it and based on removeEldestEntry’s return value it will either be kept or removed from the map.

WeakHashMap– In this implementation keys are held as WeakReferences. This way if there is no strong reference for key, on next Garbage Collection this key and corresponding value will be removed from the Map. Read this article for details on Java References. As in below example we are adding three keys to map and then clearing one strong reference to key6 by setting it to null. Then we request GC by calling System.gc() and in next statement you will notice that the key/value for key6 is removed from Map.

Click to continue reading “Java Map Interface Examples”


Integrating Spring and EHCache

Using Spring Modules and EHCache, one can transparently cache method results. Spring Modules uses a proxy which intercepts call to the method of bean; consults the cache to check if method was called with same parameters before, if so will return cached result.

EHCache is the actual provider of caching solution and Spring Module handles method interception and result storing in cache.

Click to continue reading “Integrating Spring and EHCache”


Jetty Remote Debugging using IntelliJ IDEA

Recently wanted to remotely debug Jetty instance, which was using mvn jetty:run.

Using following MAVEN_OPTS worked for me –

$ export MAVEN_OPTS=”-Xms256m -Xmx512m -agentlib:jdwp=transport=dt_socket,address=7848,server=y,suspend=n”

After setting above executed –

mvn jetty:run

Then configured IDEA Remote Server by connecting to server on above configured port 7848


JSF Validations

Using JSF Standard Built-in Validations
JSF provides built-in support for validations of input component tags. You can supply it a attribute required=”true” which will check if a value is supplied or not. There are built-in validators which you can nest in all JSF input tags.

Click to continue reading “JSF Validations”


Ant Input and Passwords

Ant input task does not has a feature which will allow not to echo what user inputs, a necessity in case you are prompting for a password. As per the ant input task documentation

A regular complaint about this task is that it echoes characters to the console, this is a critical security defect, we must fix it immediately, etc, etc. We know it leaves something to be desired, but the problem is Java, not Ant. There is nothing we can do to stop the console echoing.

Click to continue reading “Ant Input and Passwords”


Killing Java Process from Ant in Windows

I wanted to write a ant script for one of the environment, which would perform following tasks in order which will be repeated
1. Take Latest Code
2. Compile
3. Create WAR
4. Undeploy currently installed WAR from tomcat
5. Stop the tomcat
6. Copy the WAR to tomcat webapps folder
7. Start the tomcat

Click to continue reading “Killing Java Process from Ant in Windows”


iBATIS and Hibernate Features

Recently evaluated Hibernate and iBATIS, there were some good points listed at this thread which I have summarized below with some of my thoughts –

  1. iBATIS maps Java Objects to the results of SQL Queries, where as Hibernate maps Java Objects directly to database tables.
  2. iBATIS is a “Sql Mapping” implementation of ORM, whereas Hibernate is traditional Object-Relational Mapping.
  3. Hibernate automatically generates all the SQL for you and the cache invalidation can be more fine grained. iBATIS is more flexible. You have control over exactly how the SQL queries are written.
  4. Use Hibernate if you have mostly standard queries(CRUD, Find by Criteria, etc.) and if you are designing your object model first, then a relational model to support the object model.If you are working with a legacy system or a schema designed by a DBA, iBATIS often makes a better choice.
  5. All of the SQL statements used by iBATIS can be stored in XML files outside of Java code, so DBA can easily review them.
  6. Also compared to Hibernate, iBATIS is more flexible, has a shorter learning curve, but can take more time to develop and maintain, since you have to write all your queries and if your object model changes you have to go through all your queries and make sure to make all the necessary changes to reflect the changes in your object model.
  7. The performance of Hibernate while working with large data sets[complex joins] is not optimal.
  8. Hibernate is great when you control the data model, and you let Hibernate do most of the work in the persisting of objects.
  9. Unless your existing model is lightweight, adding Hibernate to it is possible, just usually not trivial.
  10. Once Hibernate is setup and SQL tuned, productivity gains are very big.
  11. iBATIS, will need good DBA or good SQL Developers for SQL tune-ups.
  12. iBATIS can be fine-grained optimization for eg. I have a table, this table has a few or dozens of fields, I need to update one of a field, iBATIS is very simple to implement a sql UPDATE using WHERE but with Hibernate, default will update all fields. Though with Hibernate you can control to update only updated fields but that you will have to configure.
  13. Similar with select queries where I can choose few columns instead of *, with Hibernate you will get object with all columns. Same applies when I want to update a row in table, with Hibernate I will have to first load that object and then save, two sqls whereas with iBATIS, it would be a single update sql. These are considerations for a interactive database where improving performances is important.
  14. iBATIS, SQL maps allow SQL to be fully customized for a specific database. However, these maps do not provide an abstraction from the specific features of the target database.