Muhammad Khojaye's Blog

Eclipse Juno release new Features

2012-07-08T11:15:00.002-07:00

Eclipse has recently announced the release of Eclipse Juno which brings new features such as Detecting resource leaks for both Java7 and Java6 etc.

Previous Plugins to Install

I firstly install all my plugins from previous eclipse version. The process is quite simple

import and install from existing installation
refer to old eclipse location
Eclipse will show the list of plugins available and then asked for installation
After accepting license, installation should complete smoothly.

New Features available

Java 7 coding support in an IDE. Since Java 7 contains many new feature including dynamically-typed languages support and other small enhancements from Coin project, eclipse Java development tooling will include support for these features of Java 7.

Detecting resource leaks of Closeable/Autocloseable resources. This feature is really cool and it also works with “old code”. The common IO and JDBC resources now implement the relevant interfaces and the warnings are good enough to be shown on these.
Resource leaks can be occurred in the following situations:
     1. A resource opened but not closed
     2. A resource may not closed on all control flows
     3. A resource may not closed at a method exit point
     4. In a Java 7 program a resource is closed but the code could still be improved by using a try-with-resources statement.
The new version include the global search bar that gives user quick access to almost any Eclipse feature.
Code Recommenders This is amazing feature that analyzes code of existing applications and extracts common patterns of how other developers have used. It helps deal with the complexity of large APIs using intelligent code completion attribute.

More examples can be found from below links,

http://eclipsesource.com/blogs/2012/06/26/code-recommenders-top-eclipse-juno-feature-2/
http://code-recommenders.blogspot.com/
The addition of integrated debugging of JVM-based domain specific languages in the Xtext development framework, The below link provide extensive examples regarding the mentioned feature, http://eclipsesource.com/blogs/2012/06/25/xtext-xtend-top-eclipse-juno-feature-3/
Eclipse for Mobile Developers - now developers can use eclipse more easily with a variety of mobile SDKs, including the Google Android SDK

How to Run Elastic MapReduce Job Using Custom Jar - Amazon EMR Tutorial

2012-04-21T13:18:00.000-07:00

Amazon EMR is a web service using which developers can easily and efficiently process enormous amounts of data. It uses an hosted Hadoop framework running on the web-scale infrastructure of Amazon EC2 and Amazon S3.
Amazon EMR removes most of the cumbersome details of Hadoop, while take care for provisioning of Hadoop, running the job flow, terminating the job flow, moving the data between Amazon EC2 and Amazon S3, and optimizing Hadoop.
In this tutorial, we will first going to developed WordCount java example using MapReduce framework Hadoop and thereafter, we execute our program on Amazon Elastic MapReduce.

Prerequisites

You must have valid AWS account credentials.You should also have a general familiarity with using the Eclipse IDE before you begin. The reader can also use any other IDE of their choice.

Step 1 – Develop MapReduce WordCount Java Program

In this section, we will first going to develop WordCount application. A WordCount program will determine how many times different words appear in a set of files.

1. In Eclipse (or whatever the IDE you are using), Create simple Java Project with name "WordCount".

2. Create a java class name Map and override the map method as follow,

public class Map extends Mapper {
 private final static IntWritable one = new IntWritable(1);
 private Text word = new Text();

 @Override
 public void map(LongWritable key, Text value, Context context)
   throws IOException, InterruptedException {
  String line = value.toString();
  StringTokenizer tokenizer = new StringTokenizer(line);
  while (tokenizer.hasMoreTokens()) {
   word.set(tokenizer.nextToken());
   context.write(word, one);
  }
 }
}

3.Create a java class name Reduce and override the reduce method as below,

public class Reduce extends Reducer {
 @Override
 protected void reduce(
   Text key,
   java.lang.Iterable values,
   org.apache.hadoop.mapreduce.Reducer.Context context)
   throws IOException, InterruptedException {
  int sum = 0;
  for (IntWritable value : values) {
   sum += value.get();
  }
  context.write(key, new IntWritable(sum));
 }
}

4. Create a java class name WordCount and defined the main method as below,

public static void main(String[] args) throws Exception {
  Configuration conf = new Configuration();

  Job job = new Job(conf, "wordcount");
  job.setJarByClass(WordCount.class);

  job.setOutputKeyClass(Text.class);
  job.setOutputValueClass(IntWritable.class);

  job.setMapperClass(Map.class);
  job.setReducerClass(Reduce.class);

  job.setInputFormatClass(TextInputFormat.class);
  job.setOutputFormatClass(TextOutputFormat.class);

  FileInputFormat.addInputPath(job, new Path(args[0]));
  FileOutputFormat.setOutputPath(job, new Path(args[1]));

  job.waitForCompletion(true);
}

5. Export the WordCount program in a jar using eclipse and save it to some location on disk. Make sure that you have provided the Main Class (WordCount.jar) during extracting the jar file as shown below.

ur jar is ready!!

Step 2 – Upload the WordCount JAR and Input Files to Amazon S3

Now we are going to upload the WordCount jar to Amazon S3. First, go to the following URL: https://console.aws.amazon.com/s3/home Next, click “Create Bucket”, give your bucket a name, and click the “Create” button. Select your new S3 bucket in the left-hand pane. Upload the WordCount JAR and sample input file for counting the words.

Step 3 – Running an Elastic MapReduce job

Now that the JAR is uploaded into S3, all we need to do is to create a new Job flow. let's execute the below steps. (I encourage reader to check out the following link for details regarding each step, How to Create a Job Flow Using a Custom JAR )

1. Sign in to the AWS Management Console and open the Amazon Elastic MapReduce console at https://console.aws.amazon.com/elasticmapreduce/
2. Click Create New Job Flow.
3. In the DEFINE JOB FLOW page, enter the following details,

a. Job Flow Name = WordCountJob
b. Select Run your own application
c. Select Custom JAR in the drop-down list
d. Click Continue
4. In the SPECIFY PARAMETERS page, enter values in the boxes using the following table as a guide, and then click Continue.
JAR Location = bucketName/jarFileLocation
JAR Arguments =
s3n://bucketName/inputFileLocation
s3n://bucketName/outputpath

Please note that the output path must be unique each time we execute the job. The Hadoop always create folder with same name specify here.

After executing job, just wait and monitor your job that runs through the Hadoop flow. You can also look for errors by using the Debug button. The job should be complete within 10 to 15 minutes (can also depend on the size of input). After completing job, You can view results in the S3 Browser panel. You can also download the files from S3 and can analyze the outcome of the job.

Amazon Elastic MapReduce Resources

Amazon Elastic MapReduce Documentation,http://aws.amazon.com/documentation/elasticmapreduce/
Amazon Elastic MapReduce Getting Started Guide,http://docs.amazonwebservices.com/ElasticMapReduce/latest/GettingStartedGuide/
Amazon Elastic MapReduce Developer Guide,http://docs.amazonwebservices.com/ElasticMapReduce/latest/DeveloperGuide/
Apache Hadoop,http://hadoop.apache.org/

Free Open Source CRM and Helpdesk Software

2011-03-22T14:41:00.000-07:00

Last week, I was surfing on web to search for an free open source CRM and help desk solution. This post will share the experience and recommend some free open source CRM and Help Desk solution.

Help desk and CRM software's are always essential for any company to provide best customer support. This tools not only helps companies in increasing the customer satisfaction but also customer retention as well. In this post, we'll examine and recommend some free and open source CRM and Help desk solution.

SugarCRM and vtiger

In my opinion, vtiger is the best option as free CRM and helpdesk software. It will work both as an Help desk and CRM.

Comparing SugarCRM and vtiger, both are providing the following major functionalities,

SugarCRM	Marketing	Sales	Support	Activities	Collaboration	Reports
Vtiger	Marketing	Sales	Support	Quick Create	Tools	Analytics

There are many different sub actions defined within these categories which include Accounts, Contracts, Leads, Documents etc. Therefore, after getting some picture of CRM, the overall interface of vtiger seems to be good for me now.

There are also many positive feedbacks available for vtiger on the web. You can find the links in 'more information' section.

There is also community version available for SugarCRM [6] however, it does not contain reporting feature. We might able to add some plug-ins for that [5] but it might need to explore more regarding how much work would need for this.

Kayako and SugarCRM

These are both awesome and renowned tools, however they are commercial and not free.Also for registered charities and open-source projects, Kayako Fusion, Kayako Resolve and Kayako Engage licenses are available free of cost.

Kayako Download licenses for Kayako Fusion, Kayako Resolve and Kayako Engage are available free of charge to registered charities and open-source projects. Free, perpetual licenses with unlimited users and no strings attached. Finally; some viable, business-class, free help desk software!

Other CRM and helpdesk option

Since vtiger will fulfill the requirement for both help desk and CRM feature, therefore you might not require any free separate help desk software. However, if you still would like to explore, I will highly recommend the below two tools.

Trellis Desk, http://www.accord5.com/trellis
osTicket, http://osticket.com/

Both software are available free and source code can also be downloadable. The source code is in PHP.

I find Trellis Desk awesome as its interface is good and it also provide good functionalities for help desk management systems.

Other tools include (not in PHP)

RT: Request Tracker, http://www.bestpractical.com/rt/
CiviCRM, http://civicrm.org/
Liberum Help Desk, http://www.liberum.org/Default.aspx

References and More Information

1. vtiger demo,http://demo.vtiger.com/
2. vtiger download, http://www.vtiger.com/index.php?option=com_content&task=view&id=30&Itemid=57
3. Vtiger CRM 5.0.3 - Installation Manual for Windows
http://wiki.vtiger.com/index.php/Vtiger_CRM_5.0.3__Installation_Manual_for_Windows#System_Requirements
4. SugarCRM VS Vtiger

http://stackoverflow.com/questions/3271656/sugarcrm-or-vtiger
http://stackoverflow.com/questions/98018/php-open-source-crm
http://ostatic.com/question/how-does-vtiger-stack-up-against-sugarcrm
http://www.siteground.com/sugarcrm_vtiger.htm
5. Sugar CRM reporting plugin, http://stackoverflow.com/questions/3271656/sugarcrm-or-vtiger
6. Sugar Editions comparison, http://www.sugarcrm.com/crm/products/editions.html
7. osTicket download, http://osticket.com/downloads.php
8. osTicket forum, http://osticket.com/forums/
9. osTicket demo, http://www.ostickethacks.com/demo/demo_info.php
10. Trellis Desk download, http://www.accord5.com/trellis/download
11. Trellis Desk demo, http://www.accord5.com/trellis/demo
12. Trellis Desk forum, http://forums.accord5.com/
13. Trellis Desk Single Sign on Integration,
http://forums.accord5.com/link-user-table-to-cubecart-user-table
14. Kayako editions comparision, http://www.kayako.com/signup/
15. Kayako free for Charity organization, http://www.kayako.com/free-help-desk-software/

Getter Setter: To use or not to use

2010-10-18T11:49:00.000-07:00

Why do we keep instance variables private? We don’t want other classes to depend on them. Moreover it gives the flexibility to change a variable’s type or implementation on a whim or an impulse. Why, then programmers automatically add getters and setters to their objects, exposing their private variables as if they were public?

Accessor methods

Accessors (also known as getters and setters) are methods that let you read and write the value of an instance variable of an object.

public class AccessorExample {
private String attribute;

public String getAttribute() {
return attribute;
}

public void setAttribute(String attribute) {
this.attribute = attribute;
}
}

Why Accessors?

There are actually many good reasons to consider using accessors rather than directly exposing fields of a class

Getter and Setter make API more stable. For instance, consider a field public in a class which is accessed by other classes. Now later on, you want to add any extra logic while getting and setting the variable. This will impact the existing client that uses the API. So any changes to this public field will require change to each class that refers it. On the contrary, with accessor methods, one can easily add some logic like cache some data, lazily initialize it later. Moreover, one can fire a property changed event if the new value is different from the previous value. All this will be seamless to the class that gets value using accessor method.

Should I have Accessor Methods for all my fields?

Fields can be declared public for package-private or private nested class. Exposing fields in these classes produces less visual clutter compare to accessor-method approach, both in the class definition and in the client code that uses it.

If a class is package-private or is a private nested class, there is nothing inherently wrong with exposing its data fields—assuming they do an adequate job of describing the abstraction provided by the class.

Such code is restricted to the package where the class is declared, while the client code is tied to class internal representation. We can change it without modifying any code outside that package. Moreover, in the case of a private nested class, the scope of the change is further restricted to the enclosing class.

Another example of a design that uses public fields is JavaSpace entry objects. Ken Arnold described the process they went through to decide to make those fields public instead of private with get and set methods here

Now this sometimes makes people uncomfortable because they've been told not to have public fields; that public fields are bad. And often, people interpret those things religiously. But we're not a very religious bunch. Rules have reasons. And the reason for the private data rule doesn't apply in this particular case. It is a rare exception to the rule. I also tell people not to put public fields in their objects, but exceptions exist. This is an exception to the rule, because it is simpler and safer to just say it is a field. We sat back and asked: Why is the rule thus? Does it apply? In this case it doesn't.

Private fields + Public accessors == encapsulation

Consider the example below

public class A {
public int a;
}

Usually this is considered bad coding practice as it violates encapsulation. The alternate approach is

public class A {
private int a;

public void setA(int a) {
this.a =a;
}

public int getA() {
return this.a;
}
}

It is argued that this encapsulate the attribute. Now is this really encapsulation?

Fact is, Getters/setters have nothing to do with encapsulation. Here the data isn't more hidden or encapsulated than it was in a public field. Other objects still have intimate knowledge of the internals of the class. Changes made to the class might ripple out and enforce changes in dependent classes. Getter and setter in this way are generally break encapsulation. A truly well-encapsulated class has no setters and preferably no getters either. Rather than asking a class for some data and then compute something with it, the class should be responsible to compute something with its data and then return the result.

Consider an example below,

public class Screens {
private Map screens = new HashMap();

public Map getScreens() {
return screens;
}

public void setScreens(Map screens) {
this.screens = screens;
}
// remaining code here
}

If we need to get a particular screen, we do code like below,

Screen s = (Screen)screens.get(screenId);

There are things worth noticing here....

The client needs to get an Object from the Map and casting it to the right type. Moreover, the worst is that any client of the Map has the power to clear it which may not be the case we usually want.

Alternative implementation of the same logic is:

public class Screens {
private Map screens = new HashMap();

public Screen getById(String id) {
return (Screen) screens.get(id);
}
// remaining code here
}

Here the Map instance and the interface at the boundary (Map) are hidden.

Getters and Setters are highly Overused

Creating private fields and then using the IDE to automatically generate getters and setters
for all these fields is almost as bad as using public fields.

One reason for the overuse is that in an IDE it’s just now a matter of few clicks to create these accessors. The completely meaningless getter/setter code is at times longer than the real logic in a class and you will read these functions many times even if you don't want to.

All fields should be kept private, but with setters only when they make sense which makes object Immutable. Adding an unnecessary getter reveals internal structure, which is an opportunity for increased coupling. To avoid this, every time before adding the accessor, we should analyze if we can encapsulate the behavior instead.

Let’s take another example,

public class Money {
private double amount;

public double getAmount() {
return amount;
}

public void setAmount(double amount) {
this.amount = amount;
}

//client
Money pocketMoney = new Money();
pocketMoney.setAmount(15d);
double amount = pocketMoney.getAmount();  // we know its double
pocketMoney.setAmount(amount + 10d);
}

With the above logic, later on, if we assume that double is not a right type to use and should use BigDecimal instead, then the existing client that uses this class also breaks.

Let’s restructure the above example,

public class Money {
private BigDecimal amount;

public Money(String amount) {
this.amount = new BigDecimal(amount);
}

public void add(Money toAdd) {
amount = amount.add(toAdd.amount);
}

// client
Money balance1 = new Money("10.0");
Money balance2 = new Money("6.0");
balance1.add(balance2);

}

Now instead of asking for a value, the class has responsibility to increase its own value. With this approach, the change request for any other datatype in future requires no change in the client code. Here not only the data is encapsulated but also the data which is stored, or even the fact that it exist at all.

Conclusions

Use of accessors to restrict direct access to field variable is preferred over the use of public fields, however, making getters and setter for each and every field is overkill. It also depends on the situation though, sometimes you just want a dumb data object. Accessors should be added for field where they're really required. A class should expose larger behavior which happens to use its state, rather than a repository of state to be manipulated by other classes.

Java 7 Automatic Resource Management

2010-08-29T10:54:00.000-07:00

One of the features in Java 7 is Automatic Resource Management. The idea was presented by Josh Bloch. The IO resources in Java need to close manually like FileInputStream, java.io.InputStream, OutputStream, Reader, Writer etc. The idea with this proposal is that it should not be the responsibility of the developer for disposing out these resources much like automatic garbage collection concept.

We usually write this kind of code for IO resources as below.

FileInputStream input = null;            
try {              
    input = new FileInputStream(configResource);               
    wfConfiguration = wfConfiguration.parseInputStream(input);           
} catch (IOException ioe) {               
      throw new RuntimeException(ioe);           
} finally {               
      if (input != null) {                   
           try {                       
             input.close();                   
           } catch (IOException ioe2) {                       
             throw new RuntimeException(ioe2);                   
           }               
      }           
}

The same code can be written in Java 7 as

FileInputStream input = null;            
try (input = new FileInputStream(configResource)) {         
      wfConfiguration = wfConfiguration.parseInputStream(input);     
} catch (IOException ioe) {               
      throw new RuntimeException(ioe);       
}

Hope you like the new syntax.

Project Coin: Updated ARM Spec

Java pass by reference or pass by value?

2010-07-23T04:04:00.000-07:00

Does Java pass by reference or pass by value?

In Java everything is passed by value. Sometime this is confusing but the point to understand is that in Java, when we pass an parameter to the method, a copy of the parameter is made.

If the argument is the primitive type, then a copy of the value of the primitive is passed. If the argument being passed is an object reference, then a copy of the value of the reference is passed. i.e., the object reference is passed by value.

Consider the example below,

public static void main(String[] args) {
   A a = new A();
   A b = new A();
   a.attribute = 5;
   b.attribute = 7;
   System.out.println(a.attribute);
   System.out.println(b.attribute);
   changeAttribute(a,b);
   System.out.println(a.attribute);
   System.out.println(b.attribute);
}

public static void changeAttribute(A a, A b) {
   a = b;
   System.out.println(a.attribute);
}

Since Java is pass by value, the caller still does not see the change, even after calling the method.

In short, Java is pass by value for all data types. Non-primitive type variables are references to objects. They are not the objects themselves. Because variables are not the objects themselves, the objects never passed to a method; only a reference to the object is passed.

Find the Java Bugs with FindBugs

2010-06-26T00:54:00.000-07:00

This post is regarding the static analysis tool that finds defects in Java programs. Static analysis tools can find real bugs and real issues in the code. We can effectively incorporate static analysis into our software development process.

FindBugs
FindBugs is an open source static analysis tool that analyzes Java class files, looking for programming defects. The analysis engine reports nearly 300 different bug patterns. Each bug pattern is grouped into a category (e.g., correctness, bad practice, performance and internationalization), and each report of a bug pattern is assigned a priority, high, medium or low.

Let’s start with some of the selected bug categories with the examples.

Correctness
Comparing incompatable types for equality

Consider the following code,


if ((!value.equals(null)) && (!value.equals(""))) {
      Map spaces =
         (Map) vm.get(SpaceConstants.AVAILABLESPACEMAP);
}

One would expect that the condition would true, when value is not null and is not empty. However, value.equals(null) according to the contract of the equals() method, would always return false.

Consider the another similar example,


if ((bean.getNoteRate() != null) &&
           !bean.getNoteRate().equals("") &&
           (bean.getNoteRate() > 0)) {
     item.setNoteRate(bean.getNoteRate());
}

We might expect that the condition would true, when noteRate is not null, not empty and is greater than 0. However, the condition would never be true.

The reason is that bean.getNoteRate().equals("") would always return false regardless of being equal value. According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.

Null pointer dereference

Consider the following code,


if ((list == null) && (list.size() == 0)) {
     return null;
}

This will lead to a NullPointerException when the code is executed when list is null.

Suspicious reference comparison

Consider the following code,


if (bean.getPaymentAmount() != null
    && bean.getPaymentAmount() != 
       currBean.getPrincipalPaid()) {
          // code to execute
}

This code compares two reference values (Double paymentAmount) using the != operator, where the correct way to compare instances of this type is generally with the equals() method. It is possible to create distinct instances that are equal but do not compare as == since they are different objects.

Doomed test for equality to NaN

Consider the following code,


if ((newValue == Double.NaN) || (newValue < 0d)) {
            // the code to execute
}

This code checks to see if a floating point value is equal to the special Not A Number value. However, because of the special semantics of NaN, no value is equal to Nan, including NaN. Thus, x == Double.NaN always evaluates to false. To check to see if a value contained in x is the special Not A Number value, use Double.isNaN(x) (or Float.isNaN(x) if x is floating point precision).

Also see How can you compare NaN values? .

Method whose return value should not ignore
string is immutable object. So ignoring the return value of the method would consider as bug.

String name = "Muhammad";
name.toUpper();
if (name.equals("MUHAMMAD"))

Performance

Method invokes inefficient Boolean constructor;use Boolean.valueOf(...) instead

Consider the following code,


if ((record.getAmount() != null)
    && !record.getAmount().equals(
        new Boolean(bean.isCapitalizing()))) {
            // code to execute
}

Creating new instances of java.lang.Boolean wastes memory, since Boolean objects are immutable and there are only two useful values of this type. Use the Boolean.valueOf() method (or Java 1.5 autoboxing) to create Boolean objects instead.

Inefficient use of keySet iterator instead of entrySet iterator
Consider the following code,


Iterator iter = balances.keySet().iterator();
        while (iter.hasNext()) {
            // code to execute
}

This method accesses the value of a Map entry, using a key that was retrieved from a keySet iterator. It is more efficient to use an iterator on the entrySet of the map, to avoid the Map.get(key) lookup.

Method invokes inefficient Number constructor; use static valueOf instead

Consider the following code,


Integer number1 = new Integer(123);
Integer number2 = Integer.valueOf(123);

System.out.println("number1 =  " + number1);
System.out.println("number2 =  " + number2);

Using new Integer(int) is guaranteed to always result in a new object whereas Integer.valueOf(int) allows caching of values to be done by the class library, or JVM. Using of cached values avoids object allocation and the code will be faster.

Also see: http://faq.javaranch.com/java/JavaIntermediateFaq#integerAutoBoxing

Method concatenates strings using + in a loop


for (int x = 0; x < exceptions.size(); x++) {
    errorMessage += getStackTrace(
         exceptions.get(x) + "\n");
}

In each iteration, the String is converted to a StringBuffer/StringBuilder, appended to, and converted back to a String. This can lead to a cost quadratic in the number of iterations, as the growing string is recopied in each iteration.

Better performance can be obtained by using a StringBuilder explicitly.

Dodgy

Code that is confusing, anomalous, or written in a way that leads itself to errors. Examples include dead local stores, switch fall through, unconfirmed casts, and redundant null check of value known to be null.

instanceof will always return true

The instanceof test will always return true (unless the value being tested is null)

NodeList nodeList = root.getElementsByTagName("node");

int nodeListLength = nodeList.getLength();

for (int i = 0; i < nodeListLength; i++) {
   Node node = nodeList.item(i);
   if (node instanceof Node && 
       node.getParentNode() == root) {
       //do code
   }
}

Test for floating point equality

Consider the following code,

private double value = 0d;

if (value > diff) {     
     // code to excute
} else if (value == diff) {     
    // code to excute
}

The above code compares two floating point values for equality. Because floating point calculations may involve rounding, calculated float and double values may not be accurate. For values that must be precise, such as monetary values, BigDecimal would be more appropriate.

See Floating-Point Operations

Also see Effective Java 2nd Ed, Item 48:Avoid float and double if exact answers are required

Integral division result cast to double or float

Consider the code,

int x = 2;
int y = 5;

// Wrong: yields result 0.0
double value1 =  x / y;

This code casts the result of an integral division operation to double or float. Doing division on integers truncates the result to the integer value closest to zero. The fact that the result was cast to double suggests that this precision should have been retained. We should cast one or both of the operands to double before performing the division like

// Right: yields result 0.4
double value2 =  x / (double) y;

References:

Download the latest version of FindBugs.

Visit the blog.

Using the FindBugs Ant task.

Using the FindBugs Eclipse plugin.

PMD

Phantom References in Java

2010-05-13T23:16:00.000-07:00

Memory management is done automatically in Java. The programmer doesn't need to worry about reference objects that have been released. One downside to this approach is that the programmer cannot know when a particular object will be collected. Moreover, the programmer has no control over memory management. However, the java.lang.ref package defines classes that provide a limited degree of interaction with the garbage collector. The concrete classes SoftReference, WeakReference and PhantomReference are subclasses of Reference that interact with the garbage collector in different ways. In this article we will discuss the functionality and behavior of the PhantomReference classes and see how it can be used.

Problem with Finalization

To perform some postmortem cleanup on objects that garbage collector consider as unreachable, one can use finalization. This feature can be utilized to reclaim native resources associated with an object. However, finalizers have many problems associated.

Firstly, we can’t foresee the call of finalize(). Since the Garbage Collection is unpredictable, the calling of finalize() cannot be predicted. There is no guarantee that the object will be garbage collected. The object might never become eligible for GC because it could be reachable through the entire lifetime of the JVM. It is also possible that no garbage collection actually runs from the time the object became eligible and before JVM stops.

Secondly, Finalization can slowdown an application. Managing objects with a finalize() method takes more resources from the JVM than normal objects.

As per doc,

You should also use finalization only when it is absolutely necessary. Finalization is a nondeterministic -- and sometimes unpredictable -- process. The less you rely on it, the smaller the impact it will have on the JVM and your application

In Effective Java, 2nd ed., Joshua Bloch says,

there is a severe performance penalty for using finalizers... So what should you do instead of writing a finalizer for a class whose objects encapsulate resources that require termination, such as files or threads? Just provide an explicit termination method, and require clients of the class to invoke this method on each instance when it is no longer needed.

In short, Finalize() isn't used often, and also there is no much reason to use it. If we have a class with methods like close() or cleanup() and that should be called once user done with the object then placing these methods call in finalize() can be used as a safety measure, but not necessary.

Phantom Reference
phantom reachable, phantomly reachable

An object is phantom reachable if it is neither strongly nor softly nor weakly reachable and has been finalized and there is a path from the roots to it that contains at least one phantom reference.

The PhantomReference constructor accepts two arguments:

referent - the object the new phantom reference will refer to
q - the reference is registered with the given queue.

The argument q represents the instance of the ReferenceQueue class. If the garbage collector determines that the referent of a phantom reference is phantom reachable, then the PhantomReference will be added to this ReferenceQueue. You can then retrieve the PhantomReference by using the remove() methods of the ReferenceQueue class.

Consider the following example,


ReferenceQueue q = new ReferenceQueue();
PhantomReference pr = new PhantomReference(object, referenceQueue);

// Later on another point
Reference r = q.remove();

// Now, clear up any thing you want

PhantomReference, when to use?
Phantom Reference can be used in situations, where sometime using finalize() is not sensible thing to do.This reference type differs from the other types defined in java.lang.ref Package because it isn't meant to be used to access the object, but as a signal that the object has already been finalized, and the garbage collector is ready to reclaim its memory.

As per API doc,

Phantom reference objects, which are enqueued after the collector determines that their referents may otherwise be reclaimed. Phantom references are most often used for scheduling pre-mortem cleanup actions in a more flexible way than is possible with the Java finalization mechanism.

People usually attempt to use finalize() method to perform postmortem cleanup on objects which usually not advisable. As mentioned earlier, Finalizers have an impact on the performance of the garbage collector since Objects with finalizers are slow to garbage collect.

Phantom references are safe way to know an object has been removed from memory. For instance, consider an application that deals with large images. Suppose that we want to load a big image in to memory when large image is already in memory which is ready for garbage collected. In such case, we want to wait until the old image is collected before loading a new one. Here, the phantom reference is flexible and safely option to choose. The reference of the old image will be enqueued in the ReferenceQueue once the old image object is finalized. After receiving that reference, we can load the new image in to memory.

Similarly we can use Phantom References to implement a Connection Pool. We can easily gain control over the number of open connections, and can block until one becomes available.

Reference Objects and Garbage Collection

Soft Reference can be garbage collected after there are no strong references to the referent. However, it typically retained until memory is low. All softly reachable objects will be reclaimed before an OutOfMemoryException is thrown. Therefore, it can be used to implement caches of objects that can be recreated if needed.

Weak Reference can be garbage collected when there are no strong or soft references to the referent. However, unlike Soft Reference, they are garbage collected on a gc even when memory is abundant. They often can be used for “canonical mappings” where each object has a unique identifier (one-to-one), and in collections of “listeners”

On the other hand, Phantom Reference, can be garbage collected once there are no strong, soft or weak references to the referent. When object is phantomly reachable, it means the object is already finalized but not yet reclaimed, so the GC enqueues it in a ReferenceQueue for post-finalization processing.

As per Java Doc,

Unlike soft and weak references, phantom references are not automatically cleared by the garbage collector as they are enqueued. An object that is reachable via phantom references will remain so until all such references are cleared or themselves become unreachable.

A PhantomReference is not automatically cleared when it is enqueued, so when we remove a PhantomReference from a ReferenceQueue, we must call its clear() method or allow the PhantomReference object itself to be garbage-collected.

Summary

In short, we should avoid finalize() as much as possible. There is no guarantee if the finalize() method will be called promptly following garbage collection, or even it will be called. If the finalize method runs for a long time, it can delay execution of finalize methods of other objects. Instead of relying on finalize(), we can use reference types define in java.lang.ref package.

Beside java.lang.ref package, Google collection library also provide some alternatives. For example, FinalizablePhantomReference extends java.lang.ref.PhantomReference, deals with processing the ReferenceQueue and call back a convenient method finalizeReferent(). So if we want to do some cleanup operation when an object is claimed by the garbage collector (GC) then we just need to override the finalizeReferent() method.

Resources

Garbage Collection
PhantomReference
The java.lang.ref Package (Java in a Nutshell)
Understanding Weak References

Playing with Executor - The Executor framework

2010-03-14T13:24:00.000-07:00

Transform sequential loop into a parallel

If the iterations of the loop are independent and we don’t need to wait for all of them to complete before proceeding, we can use an Executor to transform a sequential loop into a parallel one as shown below.


Public void SequentialLoop(List elements) {

  for (Element e : elements)

      process(e);

}


public void processLoopInParallel(Executor exec, List elements) {

  for (final Element e : elements)

      exec.execute(new Runnable() {

          public void run() { process(e); }

      });

}

The second loop will return more quickly, since all the task are queued to the Executor, rather than waiting for them all to complete.

If you want to submit a set of tasks and you want to retrieve the results as they become available, you can use a CompletionService


void solve(Executor e, Collection> solvers)

     throws InterruptedException, ExecutionException {

       CompletionService ecs

           = new ExecutorCompletionService(e);

       for (Callable s : solvers)

           ecs.submit(s);

       //retrieve completed task results and use them  

       int n = solvers.size();

       for (int i = 0; i < n; ++i) {

           Result r = ecs.take().get();

           if (r != null)

               use(r);

       }

   }

The advantage of using CompletionService is that it always returns the first completed result. In this way, we ensure that we are not waiting for tasks to complete and those uncompleted tasks are running in the background

If you want to submit a set of tasks and wait for them all to complete, you can use ExecutorService.invokeAll

XSLT Processing with JDK 1.6 and Xalan 2_7_1

2010-03-07T11:09:00.000-08:00

This small post is regarding the changes that is require, if we want to upgarde xalan-java version to 2.7.1 to work compatible with JDK1.6.

Xalan-Java is an XSLT processor for transforming XML documents into HTML, text, or other XML document types.

The issues that need to fix while upgrade XSL to work with JDK 1.6 and Xalan 2.7.1 will be discussed here and in this post we will look in to sample examples that help us to create XSL’s to work compatible with these new version.

Please note that the problems identified here work well with JDK 1.5. Therefore, these changes require only, if we want our XSL to parse successfully with JDK 1.6.

xsl:import

This element must appear as the first child node of xsl:stylesheet or xsl:transform. It should not appear in the end or middle of the stylesheet. Otherwise it throws exception

“Error! xsl:import is not allowed in this position in the stylesheet!”

xsl:template

xsl:template must either have name or match attribute. If the name attribute is omitted then there must be a match attribute.

For example, the code

--

throw exceptions

“Fatal Error! java.lang.RuntimeException: ElemTemplateElement error: xsl:template requires either a name or a match attribute.”

The below code will execute successfully.

--

xsl:value-of

xsl:value-of cannot be enclosed under xsl:text.

For example, the code

will throw exception

“Error! xsl:value-of is not allowed in this position in the stylesheet!”

The code can directly used to extract the value to output stream.

Use StringBuffer/StringBuilder in XSL

Use StringBuffer/StringBuilder in XSL
XSL Code such as

throw exception

java.lang.IllegalArgumentException: argument type mismatch and

java.lang.NullPointerException

The reason is that the
org.apache.xalan.extensions.MethodResolver picks a method whose argument types are not converted properly. This was noticed in the new versions of JVM due to the order at which they return all methods available for a given class and the issue is still not resolved yet.
Further information can be refer to

http://issues.apache.org/jira/browse/XALANJ-2374
http://issues.apache.org/jira/browse/XALANJ-2315

I have replaced StringBuilder with Map to correctly transform the XSL.

XSL DTMNodeIterator

Consider the following XSL.




   
      , CASE WHEN . 
                                
       IS NULL THEN                           
   
   
      ,
      .
   

                                      

  
         select="java:containsKey($processedMap, $temp_core_alias_value)"/>
      
         Value exist in Map =

At this point, we might expect java:containsKey($processedMap,$temp_core_alias_value) to return true and the output of the above as “Value exist in Map = Test Value” But when transform using Xalan-Java 2.7.1, the Map return false and therefore no output appear.

The reason is that the evaluating expression for the temp_core_alias_value variable would return
org.apache.xml.dtm.ref.DTMNodeIterator@e020c9 and therefore, the contains method of the Map would always return false regardless of the key present.

We can transform DTMNodeIterator to normal String form by concatenate an empty string with temp_core_alias_value variable like the following

Adding this line right before put in to the Map would result in the normal expected output.

Java Remote Debugging

2010-02-25T02:29:00.000-08:00

Start the application and tell the JVM that it will be debugged remotely
For this, add the following options to the JVM args 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

Ant 1.8 with Enhancements and Bug fixes

2010-02-15T23:03:00.000-08:00

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

http://ant.apache.org/bindownload.cgi

Release notes

http://java.dzone.com/news/ant-18-scanning-leaves-171

Java HashCode

2010-02-05T20:20:00.000-08:00

Every Java object has two very important methods i.e. hashCode() and an 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

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 should 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 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,

Objects that are equal but return different hashCodes
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 hashCode() method return 49 for an object, then it gets stored into the bucket 49 in the HashMap.
Later when you try to check whether that collection contains element or not by invoking 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 its 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 in to 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 campare only the elements of 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 such that you always return a fix value, for example like this:

//bad performance
@Override
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 an good guidelines for generating an 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
element
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;
----

@Override
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 to choose this 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 user to explore the topic further by checking out other resources.
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 implementing hashCode() method. Usually developers struggle hard with implementing hashCode() method and this class aims to simplify the process.
Here is how you would implement a hashCode algorithm for our above class

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

@Override
public int hashCode() {
return new HashCodeBuilder(83, 7)
.append(field1)
.append(field2)
.toHashCode();
}
}

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 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 produces the same value for a particular object every time when it is called. If you have a scenario like the object produces one hashCode() value when it is put() in to 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) {
this.name = name;
this.age = age;
}

public String getName() {
return name;
}

public void setName(String name) {
this.name = name;
}

public int getAge() {
return age;
}

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

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

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

public static void main(String[] args) {
Employee e = new Employee("muhammad", 24);
Map m = new HashMap(); m.put(e, "Muhammad Ali Khojaye");  // getting output System.out.println(m.get(e));  e.name = "abid";  // it fails to get System.out.println(m.get(e));  e.name = "amirrana";  // it fails again System.out.println(m.get(new Employee("muhammad", 24))); } }

So you can see in the above examples that how we are getting some unpredictable results.
You can easily fix the above by overriding the hashCode() using either Joshu Recipe or using HashCodeBuilder class.
Here is an example,
Joshu Recommendation

@Override
public int hashCode() {
int result = 17;
result = 37*result + name.hashCode();
result = 37*result + age;
return result;
}

Using HashCodeBuilder

@Override
public int hashCode() {
return new HashCodeBuilder(83, 7)
.append(name)
.append(age)
.toHashCode();
}

Another Example of Mutable Field as Key

Let consider the example

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;
}

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

@Override
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 set = new HashSet();
HashTest obj = new HashTest(6622458, 626304);
set.add(obj);                 
System.out.println(set.contains(obj));     
obj.setMutableField(3867602);        
System.out.println(set.contains(obj));
}
}

After changing mutableField, the computed hashCode 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.
Implement the hashCode() using our first technique i.e. return a constant value but you must aware that it would kills all those advantage of bucket mechanism.
If you need mutable fields included in the hashCode method then you can calculate and store the hash value when the object is created and whenever you update mutable field, you must first remove it from the collection(set/map) and then add it back to the collection after updating it.

References and More Information

Are Marker Interfaces Dead?

2010-02-04T22:51:00.000-08:00

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 consider 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.

Marker Interface

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.

Some well-known examples are

java.io.Serializable - 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

Interface and Marker Interfaces

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, all of its subclasses inherit them as well. Since you cannot unimplement 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.

Sun has also reported it as Bug which can refer at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4098033

Are Marker Interfaces end?

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 convincing reason to use such interfaces.

Consider the example below,

@interface
HasTag {
}

@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 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 type which can result in the very real benefit of compile-time type checking.