How remote debugging an java application server using eclipse

Start java application and tell the JVM that it will be debugged remotely
For this, add the following options to the JVM arguments for remote debugging:

java -Xdebug -Xrunjdwp:transport=dt_socket,address=8998,server=y,suspend=n

And then just start IDE's remote debugger to listening on port 8998

transport=dt_socket tells that the debugger connections will be made through a socket while the address=8998 parameter informs it that the port number will be 8998. For suspend=y , the JVM starts in suspended mode and stays suspended until a debugger is attached to it.

Configuring Eclipse to Debug a Remotely Running Application

  • Start Eclipse
  • Navigate to Run -> Debug Configurations
  • Create a new Remote Java Application configuration
  • Configure the remote application's details
  • click Apply
See Also
Debugging J2EE Applications
Debugging with the Eclipse Platform

Some key points include

  • Ant 1.8 has improved directory scanning performance and better symbolic link cycle handling
  • Brings enhancements and bug fixes to many tasks and types (a strong point for Ant) as well as some core changes.
  • With more than 275 fixed Bugzilla issues, Ant 1.8 flaunts some new performance improvements. A large directory scan, which would have taken 14 minutes in Ant 1.7.1, now takes as little as 22 seconds with Ant 1.8.
  • Ant 1.8 includes a handful of new elements including , a new top-level element that assists in writing reusable build files that are meant to be imported.Its name and dependency-list are similar to and it can be used like a from the command line or a dependency-list but in addition, the importing build file can add targets to the 's depends list.

Other additions include:
  • New lexically scoped local properties.
  • An enhanced that can import from any file or URL resource.
  • An easier mechanism for extending Ant's property expansion.
  • A new task called include that provides a preferred alternative to when you don't want to override any targets.
  • Rewritten if and unless attributes that do what is expected when applied to a property expansion (i.e. if="${foo}" means "yes, do it" if ${foo} expands to true. In Ant 1.7.1 it would mean "no" unless a property named "true" existed). This adds "testing conditions" to property expansion as a new use-case.

Ant 1.8 now requires at least Java 1.4 or later.

Other References

Release notes

Why Overriding hashCode() and Equal() method contract?

Every Java object has two very important methods i.e. hashCode() and equals() method. These methods are designed to be overridden according to their specific general contract. This article describes why and how to override the hashCode() method that preserves the contract of HashCode.

Contract For HashCode Method

The contract for hashCode says
“If two objects are equal, then calling hashCode() on both objects must return the same value”.
Now the question that will come into your mind is that; is it necessary that the above statement should always be true?

Consider the fact that we have provided a correct implementation of an equal method for our class, then what would happen if we do not obey the above contract.
To answer the above question, let us consider the two situations,
  1. Objects that are equal but return different hashCodes
  2. Objects that are not equal but return the same hashCode
Objects that are equal but return different hashCodes
What would happen if the two objects are equal but return different hashCodes? Your code would run perfectly fine. You will never come in trouble unless and until you have not stored your object in a collection like HashSet or HashMap. But when you do that, you might get strange problems at runtime.
To understand this better, you have to first understand how collection classes such as HashMap and HashSet work. These collections classes depend on the fact that the objects that you put as a key in them must obey the above contract. You will get strange and unpredictable results at runtime if you do not obey the contract and try to store them in a collection.

Consider an example of HashMap. When you store the values in HashMap, the values are actually stored in a set of buckets. Each of those buckets has been assigned a number which is use to identify it. When you put a value in the HashMap, it stores the data in one of those buckets. Which bucket is used depends on the hashCode that will return by your object. Let’s say, if the hashCode() method returns 49 for an object, then it gets stored in the bucket 49 of the HashMap.
Later when you try to check whether that collection contains an element or not by invoking the Contains(element) method, the HashMap first gets the hashCode of that “element “. Afterwards, it will look into the bucket that corresponds with the hashCode. If the bucket is empty, then it means we are done and it's return false which means the HashMap does not contain the element.
If there are one or more objects in the bucket, then it will compare “element” with all other elements in that bucket using your defined equal() function.

Objects that are not equal but return the same hashCode
The hashCode contract does not say anything about the above statement. Therefore different objects might return the same hashCode value, but collections like HashMap will work inefficiently if different objects return the same hashCode value.

Why Buckets

The reason why bucket mechanism is used is its efficiency. You can imagine that if all the objects you put in the HashMap would be stored into one big list, then you have to compare your input with all the objects in the list when you want to check if a particular element is in the Map. With the use of buckets, you will now compare only the elements of the specific bucket and any bucket usually holds only a small portion of all the elements in the HashMap.

Overriding hashCode Method

Writing a good hashCode() method is always a tricky task for a new class.

Return Fixed Value
You can implement your hashCode() method that always returns fix value, for example like this:

//bad performance
public int hashCode() {
    return 1;
The above method satisfies all the requirements and is considered legal according to the hash code contract but it would not be very efficient. If this method is used, all objects will be stored in the same bucket i.e. bucket 1 and when you try to ensure whether the specific object is present in the collection, then it will always have to check the entire content of the collection.

On the other hand, if you override the hashCode() method for your class and if the method breaks the contract then calling contains() method may return false for the element which is present in the Collection but in a different bucket.

Method From Effective Java
Joshua Bloch in Effective Java provides good guidelines for generating a hashCode() value
  • 1. Store some constant nonzero value; say 17, in an int variable called result.
  • 2. For each significant field f in your object (each field taken into account by the equals()), do the following
  • a. Compute an int hashCode c for the field:
  • i. If the field is a boolean, compute c = (f ? 1 : 0).
  • ii. If the field is a byte, char, short, or int, compute c = (int) f.
  • iii. If the field is a long, compute c = (int) (f ^ (f >>> 32)).
  • iv. If the field is a float, compute c = Float.floatToIntBits(f).
  • v. If the field is a double,compute long l = Double.doubleToLongBits(f),
    c = (int)(l ^ (l >>> 32))
  • vi. If the field is an object reference then equals( ) calls equals( ) for this field. compute
    c = f.hashCode()
  • vii. If the field is an array, treat it as if each element were a separate field.
    That is, compute a hashCode for each significant element by applying above rules to each
  • b. Combine the hashCode c computed in step 2.a into result as follows:result = 37 * result + c;
  • 3. Return result.
  • 4. Look at the resulting hashCode() and make sure that equal instances have equal hash codes.
Here is an example of a class that follows the above guidelines

public class HashTest {
    private String field1;
    private short  field2;

    public int hashCode() {
        int result = 17;
        result = 37*result + field1.hashCode();
        result = 37*result + (int)field2;
        return result;
You can see that a constant 37 is chosen. The purpose of choosing a prime number is that it is a prime number. We can choose any other prime number. Using prime number the objects will be distributed better over the buckets. I encourage the user to explore the topic further by checking out other resources.

Using java.util.Objects.hash
java.util.Objects class contains a utility method hash(Object... values) that can be used to calculate hash for sequence of objects. With this method, we can implement hashcode for our example HashTest class as follows:
public class HashTest {
    private String field1;
    private short  field2;

    public int hashCode() {
        return java.util.Objects.hash(field1, field2);
Apache HashCodeBuilder
Writing a good hashCode() method is not always easy. Since it can be difficult to implement hashCode() correctly, it would be helpful if we have some reusable implementations of these.

The Jakarta-Commons org.apache.commons.lang.builder package is providing a class named HashCodeBuilder which is designed to help implement a hashCode() method. Usually, developers struggle hard with implementing a hashCode() method and this class aims to simplify the process.
Here is how you would implement hashCode algorithm for our above class

public class HashTest {
    private String field1;
    private short  field2;

    public int hashCode() {
        return new HashCodeBuilder(83, 7)
Note that the two numbers for the constructor are simply two different, non-zero, odd numbers - these numbers help to avoid collisions in the hashCode value across objects.

If required, the superclass hashCode() can be added using appendSuper(int).
You can see how easy it is to override HashCode() using Apache HashCodeBuilder.

Mutable Object As Collection Key

It is a general advice that you should use immutable object as a key in a Collection. HashCode work best when calculated from immutable data. If you use Mutable object as key and change the state of the object so that the hashCode changes, then the store object will be in the wrong bucket in the Collection

The most important thing you should consider while implementing hashCode() is that regardless of when this method is called, it should produce the same value for a particular object every time when it is called. If you have a scenario like an object produces one hashCode() value when it is put() into a HaspMap and produces another value during a get(), in that case, you would not be able to retrieve that object. Therefore, if you hashCode() depends on mutable data in the object, then made changing those data will surely produce a different key by generating a different hashCode().
Look at the example below
public class Employee {

    private String name;
    private int age;

    public Employee() {

    public Employee(String name, int age) { = name;
        this.age = age;

    public String getName() {
       return name;

    public void setName(String name) { = name;

    public int getAge() {
        return age;

    public void setAge(int age) {
        this.age = age;

    public boolean equals(Object obj) {
        //Remember: Some Java gurus recommend you avoid using instanceof
        if (obj instanceof Employee) {
            Employee emp = (Employee)obj;
            return ( == name && emp.age == age);
        return false;

    public int hashCode() {
        return name.length() + age;

    public static void main(String[] args) {
        Employee e = new Employee("muhammad", 24);
        Map<Object,Object> m = new HashMap<Object,Object>(); 
        m.put(e, "Muhammad Ali Khojaye");  
        // getting output 
        System.out.println(m.get(e)); = "abid";  
        // it fails to get System.out.println(m.get(e)); = "amirrana";  
        // it fails again
        System.out.println(m.get(new Employee("muhammad", 24))); 
So we can see in the above examples that how are we getting some unpredictable results after modifying the object state.

Another Example of Mutable Field as Key

Let consider an another example below:
public class HashTest {
    private int mutableField;
    private final int immutableField;

    public HashTest(int mutableField, int immutableField) {
        this.mutableField = mutableField;
        this.immutableField = immutableField;

    public void setMutableField(int mutableField) {
        this.mutableField = mutableField;

    public boolean equals(Object o) {
        if(o instanceof HashTest) {
            return (mutableField == ((HashTest)o).mutableField)
               && (immutableField ==  ((HashTest)o).immutableField);
        }else {
            return false;

    public int hashCode() {
        int result = 17;
        result = 37 * result + this.mutableField;
        result = 37 * result + this.immutableField;
        return result;

    public static void main(String[] args) {
        Set<HashTest> set = new HashSet<HashTest>();
        HashTest obj = new HashTest(6622458, 626304);
After changing mutableField, the computed hashCode value is no longer pointing to the old bucket and the contains() returns false.
We can tackle such situation using either of these methods
  • Hashcode is best when calculated from immutable data; therefore ensure that only immutable object would be used as key with Collections.
  • If you need mutable fields included in the hashCode method then you need to ensure that object state is not changing after they've been used as Key in a hash-based collection. If for any reason it changed, you can calculate and store the hash value when the object updates mutable field. To do this, you must first remove it from the collection(set/map) and then add it back to the collection after updating it.

Memory leaks with HashCode and Equal

It is possible that a memory leak can occur in the Java application if equals() and hashcode() are not implemented. Consider a small code example below in which HashMap keeping references active if equals() and hashcode() are not implemented. As a results the HashMap grows continuously by adding the same key repeatedly and finally throw an OutOfMemoryError
 * Example demonstrating a Hashcode leak.
public class HashcodeLeakExample {
    private String id;

    public HashcodeLeakExample(String id) { = id;

    public static void main(String args[]) {
        try {
            Map<HashcodeLeakExample, String> map = 
                  new HashMap<HashcodeLeakExample, String>();
            while (true) {
                map.put(new HashcodeLeakExample("id"), "any value");
        } catch (Exception ex) {

References and More Information

In earlier versions of Java, Marker Interfaces were the only way to declare metadata about a class. With the advent of annotation in Java 5, it is considered that marker interfaces have now no place. They can be completely replaced by Annotations, which allow for a very flexible metadata capability. Everything that can be done with marker interfaces can be done instead with annotations. In fact, it's now recommended that the marker interface pattern should not be used anymore. Annotations can have parameters of various kinds, and they're much more flexible. We can also see that the examples used in Sun API’s are rather old and that no new ones have been added since after introduce of Annotation. In this post, we will see whether Marker Interfaces can still be used for any reasons.

Purpose of Marker Interfaces in Java

A marker interface is an interface with no method declarations. They just tell the compiler that the objects of the classes implementing the interfaces with no defined methods need to be treated differently. These Marker interfaces are used by other code to test for permission to do something.

marker interfaces list in java

Some well-known examples are

  • - object implement it can be serialized using ObjectOutputStream.
  • java.lang.Clonable - objects clone method may be called
  • java.util.RandomAccess- support fast (generally constant time) random access

They are also known as tag interfaces since they tag all the derived classes into a category based on their purpose

Difference between Interface and Marker Interface

Interface in general defines a contract. They represent a public commitment and when implement form a contract between the class and the outside world. On the other hand, an empty interface does not define any members, and as such, does not define a contract that can be implemented.

Normally, when a class implements an interface, it tells something about the instances of the class. It represent an "is a" relationship that exist in inheritance. For example, when a class implements List, then object is a List.

With marker interfaces, this inheritance mechanism usually does not obey. For example, if class implements the marker interface Serializable, then instead of saying that the object is a Serializable, we say that the object has a property i.e. it is Serializable.

Should Avoid Marker Interfaces?

One common problem occurs while using marker interfaces is that when a class implements them, each subclasses inherit them as well. Since you cannot unimplemented an interface in Java, therefore a subclass that does not want to treat differently will still be marked as Marker. For example, Foo implements Serializable, any subclass Bar etc does too as well.

Moreover, there are places in the Sun API’s where such interfaces have been used for messy and varying purposes. Consider Cloneable Marker Interface. If the operation is not supported by an object, it can throw an exception when such operation is attempted, like Collection.remove does when the collection does not support the remove operation (eg, unmodifiable collection) but a class claiming to implement Cloneable and throwing CloneNotSupportedException from the clone() method wouldn't be a very friendly thing to do.

Many developers consider it as broken interface. Ken Arnold and Bill Venners also discussed it in Java Design Issues. As Ken Arnold said,

If I were to be God at this point, and many people are probably glad I am not, I would say deprecate Cloneable and have a Copyable, because Cloneable has problems. Besides the fact that it's misspelled, Cloneable doesn't contain the clone method. That means you can't test if something is an instance of Cloneable, cast it to Cloneable, and invoke clone. You have to use reflection again, which is awful. That is only one problem, but one I'd certainly solve.

Oracle has also reported it as Bug which can refer at

Are Marker Interfaces end?

Appropriate Use of Marker Interfaces vs Annotation

We usually hear that Marker Interface is now obsolete and it has no place. But, there are situations where they can be handy over using annotations.

Annotations have to be checked at runtime using reflection. Empty interfaces can be checked at compile-time using the type system in the compiler. Compile-time checking can be one of the convincing reason to use such interfaces.

Consider the example below:

HasTag {

public class ClasswithTag {

public void performAction(Object obj){
    if (!obj.getClass().isAnnotationPresent(HasTag.class)) {
        throw new IllegalArgumentException("cannot perform action...");
    } else {
        //do stuff as require

One problem with this approach is that the check for the custom attribute can occur only at runtime. Sometimes, it is very important that the check for the marker be done at compile-time. Let me refine the above example to use Marker.

interface HasTag {

public class ClassWithTag implements HasTag {

public void performAction(HasTag ct){
    //do stuff as require

Similarly, in the case of the Serializable marker interface, the ObjectOutputStream.write(Object) method would fail at runtime if its argument does not implement the Interface which would not be the case, if ObjectOutputStream had a writeObject(Serializable) method instead.

Marker Interfaces can also be well-integrated in Javadoc where one can promptly see who implements marker interfaces or not by just look it up and see the list of implementing classes.

Moreover, Joshua in Effective Java also recommends using Marker interface to define the type which can result in the very real benefit of compile-time type checking.