Wednesday, 29 May 2013

Callable vs Runnable

Callable interface
public interface Callable<V>, where V is the return type of the method call. This interface has a single method ‘call’, which needs to be defined by all the classes which implement this interface. This method takes no arguments and returns a result of type V. This method can throw checked exceptions as well.
Runnable interface
public interface Runnable - this interface is implemented by those classes whose instances are supposed to be executed in a different thread. This interface has only one method ‘run’, which takes no arguments and obviously all the classes implementing this interface need to define this method.
This interface is implemented by the Thread class as well and it’s a common protocol for all the objects who wish to execute in a different thread. It’s one of the ways of creating threads in Java. The other way to create a thread is by sub-classing theThread class. A class implementing Runnable interface can simply pass itself to create a Thread instance and can run thereafter. This eliminates the need of sub-classing the Thread class for the purpose of executing the code in a separate thread.
As long as we don’t wish to override other methods of the Thread class, it may be a better idea to implement the Runnable interface to enable multithreading capabilities to a class than enabling the same by extending the Thread class.
Callable vs Runnable
Though both the interfaces are implemented by the classes who wish to execute in a different thread of execution, but there are few differences between the two interface which are:-
  • A Callable<V> instance returns a result of type V, whereas a Runnableinstance doesn’t
  • A Callable<V> instance may throw checked exceptions, whereas aRunnable instance can’t
The designers of Java felt a need of extending the capabilities of the Runnableinterface, but they didn’t want to affect the uses of the Runnable interface and probably that was the reason why they went for having a separate interface namedCallable in Java 1.5 than changing the already existing Runnable interface which has been a part of Java since Java 1.0.

ASCII Art Java Example

package com.jay;
import java.awt.Font;
import java.awt.Graphics;
import java.awt.Graphics2D;
import java.awt.RenderingHints;
import java.awt.image.BufferedImage;
import javax.imageio.ImageIO;
public class ASCIIArt {
  public static void main(String[] args) throws IOException {
 int width = 100;
 int height = 30;
        //BufferedImage image = File("your path/logo.jpg"));
 BufferedImage image = new BufferedImage(width, height, BufferedImage.TYPE_INT_RGB);
 Graphics g = image.getGraphics();
 g.setFont(new Font("SansSerif", Font.BOLD, 24));
 Graphics2D graphics = (Graphics2D) g;
 graphics.drawString("JAVA", 10, 20);
 //save this image
 //ImageIO.write(image, "png", new File("your path/ascii-art.png"));
 for (int y = 0; y < height; y++) {
  StringBuilder sb = new StringBuilder();
  for (int x = 0; x < width; x++) {
   sb.append(image.getRGB(x, y) == -16777216 ? " " : "$");
  if (sb.toString().trim().isEmpty()) {

Tuesday, 7 May 2013

What does “event bubbling” mean? [In context of CSS]

“Delegation” and “bubbling” are terms that gets thrown round a lot in JavaScript; but what exactly do these terms mean?

Event Bubbling

In JavaScript, events bubble. This means that an event propagates through the ancestors of the element the event fired on. Lets show what this means using the HTML markup below;
        <a href="#">
Lets assume we click the span, which causes a click event to be fired on the span; nothing revolutionary so far. However, the event then propagates (or bubbles) to the parent of the span (the <a>), and a click event is fired on that. This process repeats for the next parent (or ancestor) up to the document element.
You can see this in action here. Click “Hello” and see the events as they get fired.
That’s all event bubbling is; an event fired on an element bubbles through its ancestor chain (i.e. the event is also fired on those elements). It’s important to note that this isn’t a jQuery feature, nor is it something that a developer must turn on; it’s a fundamental part of JavaScript that has always existed.
Ok, that’s a little bit of a lie… sort of.
By default, not all events bubble. For instance submit does not normally bubble, nor does change. However, jQuery masks this in the event handling code using all sorts of voodoo, so it will seem that they do bubble when using jQuery.