Monday, March 25, 2013

What's New In Java 8 : Default Methods (Defender Methods)



We all know that interfaces in Java contain only method declarations and no implementations and any non-abstract class implementing the interface had to provide the implementation. Lets look at an example :

public interface SimpleInterface {
  public void doSomeWork();
}
 
class SimpleInterfaceImpl implements SimpleInterface{
  @Override
  public void doSomeWork() {
    System.out.println("Do Some Work implementation in the class");
  }
 
  public static void main(String[] args) {
    SimpleInterfaceImpl simpObj = new SimpleInterfaceImpl();
    simpObj.doSomeWork();
  }
}
Now what if I add a new method in the SimpleInterface?

public interface SimpleInterface {
  public void doSomeWork();
  public void doSomeOtherWork();
}
and if we try to compile the code we end up with:

$javac .\SimpleInterface.java
.\SimpleInterface.java:18: error: SimpleInterfaceImpl is not abstract and does not 
override abstract method doSomeOtherWork() in SimpleInterface
class SimpleInterfaceImpl implements SimpleInterface{
^
1 error
And this limitation makes it almost impossible to extend/improve the existing interfaces and APIs. The same challenge was faced while enhancing the Collections API in Java 8 to support lambda expressions in the API. To overcome this limitation a new concept is introduced in Java 8 called default methods which is also referred to as Defender Methods or Virtual extension methods.

Default methods are those methods which have some default implementation and helps in evolving the interfaces without breaking the existing code. Lets look at an example:

public interface SimpleInterface {
  public void doSomeWork();
   
  //A default method in the interface created using "default" keyword
  default public void doSomeOtherWork(){
    System.out.println("DoSomeOtherWork implementation in the interface");
  }
}

class SimpleInterfaceImpl implements SimpleInterface{
  @Override
  public void doSomeWork() {
    System.out.println("Do Some Work implementation in the class");
  }
  /*
   * Not required to override to provide an implementation 
   * for doSomeOtherWork.
   */
 
  public static void main(String[] args) {
    SimpleInterfaceImpl simpObj = new SimpleInterfaceImpl();
    simpObj.doSomeWork();
    simpObj.doSomeOtherWork();
  }
}
and the output is:

Do Some Work implementation in the class
DoSomeOtherWork implementation in the interface
This is a very brief introduction to default methods. One can read in depth about default methods here.

References :



Share:

Wednesday, March 20, 2013

Selecting your Java Collections library


Introduction :

Java collections are one of the most commonly used data-structures by all Java professionals. But are you using the right collection class that would best suits your need. Most programmers usually use Vectors, ArrayList, HashMap or the Hashtable. There are many other collection classes available with the JDK that you can use instead of re-inventing logic to suite your needs.

We will be trying to understand the different types of classes and when each Collection class could be used. We wouldn't be looking into the implementation details of any collection, for that please refer the latest Java Collection API docs.

The Core Collection Framework Interfaces :

The core collection frameworks are depicted in the following image.

Java Collection Interfaces

Share:

Monday, March 18, 2013

Openfire : Installation and Configuration Guide




Overview :
Openfire is a powerful instant messaging (IM) and chat server that implements the XMPP protocol. This document will guide you through installing Openfire.

Download :
please visit the Openfire website to download latest Openfire server: http://www.igniterealtime.org/projects/openfire/

Files in the Distribution :
The files in your distribution should be as follows (some sub-directories omitted for brevity):

openfire/
 |- readme.html
 |- license.html
 |- conf/
 |- bin/
 |- jre/
 |- lib/
 |- plugins/
     |- admin/
 |- resources/
     |-database/
     |-security/
 |- documentation/
  • The conf directory is where Openfire stores configuration files.
  • The bin directory contains the server executables. Depending on which distribution you installed, different executables will be available.
  • The jre directory contains a Java 5 runtime that is bundled with the Windows and RPM versions of Openfire.
  • The lib directory contains libraries necessary for running Openfire.
  • The plugins directory contains server plugins. By default, Openfire ships with a web-based admin console plugin.
  • The resources/database directory contains SQL schema files to create new Openfire databases, as well as upgrade scripts for existing installations.
  • The resources/security directory is where Openfire maintains keystores to support SSL connection security.
  • The documentation directory contains server documentation.
Share:

Thursday, March 14, 2013

NoSQL - Offers and Gives Up


Deciding between a NoSQL database or a relational database system is about understanding the trade-offs that led to the creation of NoSQL to begin with. NoSQL systems have advantages over traditional SQL databases because they give up certain RDBMS features in order to gain other performance, scalability and developer usability capabilities.

What NoSQL gives up (this varies by NoSQL engine) :

  • Relationships between entities (like tables) are limited to non-existent. For example, you usually can't join tables or models together in a query. Traditional concepts like data normalization don't really apply. But you still must do proper modeling based on the capabilities of the particular NoSQL system. NoSQL data modeling varies by product and whether you are using a document vs column based NoSQL engine. For example, how you might model your data in MongoDB vs HBase varies because each solution offers significantly different capabilities.
  • Limited ACID transactions. The level of read consistency and atomic write/commit capabilities across one or more tables/entities varies by NoSQL engine.
  • No standard domain language like SQL for expressing ad-hoc queries. Each NoSQL has its own API and some of the NoSQL vendors have limited ad-hoc query capability.
  • Less structured and rigid data model. NoSQL typically forces/gives more responsibility at the application layer for the developer to "do the right thing" when it comes to data relationships and consistency. Think of NoSQL as a schema on read instead of the traditional schema on write.

Share:

Wednesday, March 13, 2013

JavaFX for Android or iOS?


There has been big news recently in the world of JavaFX regarding many more components of JavaFX being open sourced as advertised at JavaOne 2012. In February Open Source Update, Richard Bair compiled a table of JavaFX projects that have been open sourced as of that post's writing (Monday, 11 February 2013). As exciting as all that open sourcing is, there was something even more exciting highlighted below the table: "We’re also going to open source our iOS and Android implementations over the next couple months."

Bair adds some timing and background information to this significant announcement:

  • The first bits and pieces for iOS should be out next week, with the rest of iOS and Android coming out at about the same time as the rest of prism (there is some timing dependency there). Both our ports are based on an as-yet unreleased version of JavaSE Embedded for iOS/Android.

After expressing the expected caveat "I’m not a lawyer", Bair also addresses licensing issues on iOS and points out that "both OpenJFX and OpenJDK are both licensed with the same GPLv2 with Classpath Extension." He further describes his understanding of the licensing situation: "this means that if you take OpenJFX + OpenJDK (minus any binary stubs released under a different license), then you can safely combine this with your application and release your application under your own license as a single application co-bundle." I am sure we'll hear more about the licensing details in the future as this develops.

Being able to develop Android and iOS applications with JavaFX will likely be a game-changer for JavaFX. I echo Bair's concluding sentence: "I am looking forward to seeing what you all will do with this contribution, and hope to be running many Java apps on my phone / iPad in the near future." I look forward to using (and maybe even writing) some JavaFX-based apps on my Droid!

References :
javafx coming soon to android or ios
Share: