Monday, 22 August 2011

Templating with JSF 2.0 Facelets

“Templating with JSF 2.0 Facelets,” offers a concise explanation of how to use Facelets, which in JavaServer Faces (JSF) 2.0, has replaced JavaServer Pages (JSP) as the default view declaration language (VDL). With Facelets, developers no longer need to configure a view handler as they once did in JSF 1.2.

“Facelets is a templating framework similar to Tiles. The advantage of Facelets over Tiles is that JSF UIComponents are pre-integrated with Facelets, and Facelets does not require a Facelets configuration file, unlike Tiles, which requires a Tiles configuration file.
JSF Validators and Converters may be added to Facelets. Facelets provides a complete expression language (EL) and JavaServer Pages Standard Tag Library (JSTL) support. Templating, re-use, and ease of development are some of the advantages of using Facelets in a Web application.

Read more from the following link:

Happy Templating with facelets.

Thursday, 11 August 2011

Bangalore Metro To Launch NFC Enabled Debit-Cum Travel Card

Even before the Bangalore’s Namma Metro officially commences services, State Bank of India has announced NFC (Near Field Communication) enabled debit cards, that will double up as travel smart cards, enabling commuters to pay for their journeys with a simple tap, reports The New Indian Express. The debit cards, which the bank will start issuing today onwards, will have a built-in e-purse to store a pre-paid amount. According to SBI Deputy MD (corporate strategy and new businesses), C Narasimhan, the e-purse can be topped at the nearest ATM or through mobile banking or internet banking, in addition to cash topups. The card can be used just like a normal debit card for ATM cash withdrawals and merchant transactions.
The Bangalore Metro Rail Corporation claims that the debit-cum travel card is the first of its kind in the world. The card will be initially offered to SBI customers, and will be later extended to customers of other banks as more tie-ups are inked. We do not know if there will be a reward system or a discount on fare, for customers using the card.
This might be the first time when NFC has been used with a debit card in India, however it’s not the first time that a Bank and Metro Railway service have partnered for a co-branded travel card. Citibank also offers a Delhi Metro Credit Card, that acts as a travel smart card, albeit through a different chip. It also enables commuters to load the smart card with cash at selected stations, charging the amount to the card by way of a swipe.  In addition to a 10% discount on fare, the card also offers rewards points, which can be redeemed for free travel.
Mobile Payments?
This also implies that the Bangalore Metro’s commuter check-in terminals will be NFC enabled, which means that it will be able to accept payments from other NFC enabled devices, including mobile phones, if BMRC inks a deal with a mobile service/mobile payments provider. P.S – The Japanese have been using their phones as travel smart cards, since ages.

Tuesday, 9 August 2011

Developers Frustrated By Android Market Payment Issues!!!

We’ve heard our share of app store woes in recent weeks, but here’s one that’s unfortunately still in progress. A number of Android app developers have been claiming on the Android Market support forum that the amount of money they’re being paid doesn’t match up with the number of apps they have actually sold.
The problem began on July 26, when a beleaguered dev posted the following:
something I noticed the last 2 days: the list of orders in the payout doesn’t match the list of charged orders. And I don’t mean that I miss one or two orders… no I’m getting payed out for less than the half of all orders!
From what the developers were able to piece together, the thread that connected their uncounted purchases was that they were all made through the Android Market’s web store. Customers’ credit cards were apparently charged and marked as shipped through Google Checkout, but with no corresponding payout to the developers.
Much discussion ensued during the next nine days, until Google finally made their official response:
Thanks for posting and for your patience. We’re aware of the issue, and we’re working on fixing it. Once the fix goes out (soon!), orders should be moved to the correct state, which will enable disbursement amounts to be recovered. So if your July activity payouts were underpaid, you will be notified, and your September 1 payout will contain the missing amounts.
According to Google, there is no official ETA for a fix, but they have been proactive in contacting the affected developers by email notifying them of the situation.
While we have every confidence that Google will eventually make things right, a little transparency could have gone a long way here, especially considering how valuable independent developers are to the success of the platform. The devs affected have been more than patient, but it never hurts to call attention to ground-level problems like this just to keep big companies like Google honest. It’s also possible there are more out there who haven’t heard from Google at all, and are simply baffled by their low receipts (you might want to check yours, just in case). Help should be on the way; be sure to voice your support concerns officially with Google and hopefully things will be resolved soon.

Hope google will pay for that with interest to all developers those who affected. ;)

Monday, 8 August 2011

What will Java 7 mean for you?

After a long time... Oracle released Java 7 on July 28, 2011. This is nearly 5 years after the release of Java 6 in December 2006. The release received a lot of bad press, both because it is very meager on features, and because it shipped with a severe bug. Nevertheless, once the most serious bugs have been fixed, you might think about starting to use Java 7. What will this mean?

New language features

Java 7 has a few new language features. Sadly, the most exciting ones have been postponed until Java 8. The following 3 features may show up in your pretty quickly, though:

try ( BufferedReader reader = new BufferedReader(new FileReader(...))) {
  String line = reader.readLine();
This is the try-with-resources or Automatic Resource Management block. If you declare a variable in the try() statement, Java automatically calls close on it, like you would in a finally block. This is a small improvement, but nice. You can use try-with-resources on your own object by implementing the new interface java.lang.AutoCloseable.

try {
} catch (InstantiationException|IllegalAccessException|InvocationTargetException|NoSuchMethodException e) {
    throw new RuntimeException("I really don't care", e);
This is the multi-catch statement. It’s useful because of the load of checked exceptions on the sanity of your average Java-developer. It’s nice, but hardly revolutionary. It makes me really wish we got rid of checked exceptions, though.

Map<> ordersPerCustomer = new HashMap<customer ,List<Order>>();
This is type inference for Generic Instance Creation. Saves a few keystrokes without removing any type safety. Again, a nice, but very small improvement.
There are a few more language features, but I expect they will see very little use.

JVM changes

The Java virtual machine gets a new instruction: invokedynamic. Using invokedynamic, the JVM can invoke a method on an object without having to know on which class or interface the method is declared. If it walks like a duck and talks like a duck…
Invokedynamic will be very helpful for implementors of dynamic languages in the JVM, so it’s great. But the average developer will never encounter it in the wild.

Library changes

Looking at the release notes for Java 7, you may first suspect that there are some interesting library changes here. However, when examining the list more thoroughly, I couldn’t find a single change that I expect I will actually use. The library changes are mostly low-level, behind the scenes fixes of small problems.


So there it is: try-with-resources, multi-catch and a very limited type inference. Hopefully, Java 8 will be released as planned in late 2012 with all the stuff we’ve been waiting for. If so, I expect most shops will skip Java 7. But if Java 8 follows the pattern of delays from Java 7, these slim pickings may be all the crumbs the Java community gets for another five years.

Sunday, 7 August 2011

Embedded Java - A Fresh Look at Embedded with Greg Bollella, Chief Architect.

Great news for Java lovers!!!
Java Technology is going to use in the embedded space.

“Now, embedded developers can download, install, and begin creating Java programs on typical embedded hardware in minutes.”Greg Bollella
(Chief Architect, Embedded Java, Oracle)

The Java language and runtime platform are pervasive in the embedded space. Today, Java technology is already present in 5 billion SIMs and Smart Cards, 3 billion mobile handsets, 80 million TV devices, including every Blu-ray player shipped, and many other embedded solutions from printers and bank machines to e-book readers and cars.

Java SE for Embedded
Java SE is commonly known as the platform that runs on desktops and servers. It offers a high-performance virtual machine, full high-performance graphics support, deployment infrastructure, and a rich set of features and libraries. Java SE for Embedded has been optimized for mid-range to high-end embedded systems.
  • Devices having 32MB (without graphics) or more for Java can use Oracle's Java SE for Embedded

Java ME for Embedded
Oracle Java Micro Edition Embedded Client is based on Connected Device Configuration (CDC), a subset of the Java SE platform and draws from the origins of the Java platform, which was originally designed for embedded devices.  While scaled down to fit the limitations of resource-constrained devices and optimized for low to mid-range embedded-systems, Oracle Java ME Embedded Client provides most of the Java language and runtime features developers know and are accustomed to with Java SE.
  • Devices having 8MB (without graphics) or more for Java can use Oracle's Java ME for Embedded


Thursday, 4 August 2011

Never check in code in EOD !!!

Be cool and do cool !!!

We learn many things as we become more experienced. There are some lesson which are not been written in any book, we learn from our own experience. Each one of the developer has his/her own methods,tools and practices which he/she develops and used as he progresses in life, and no two developer has same set of these. You can assume that each of the developer has an environment created by him/her in by learing/unlearning from his/her past experience. Here I am going to tell one simple practice that helps a lot. It says that:  “Never Check In the code by End of Day(EoD)”.

This is very siple yet powerful process which could stop a lot of bugs.Normally, What happens is that we delay all code check in task till, we are ready to return from office. So, at last we realize that we have to check in and we do it hurrily witout giving proper attention. This results in defect. Code check in is an important process and it should be done carefully. Whatever hard work we had done, if we miss to this process carefully its worth nothing. So, never check in the code by EOD until its necessary and urgent, always try to check in before first half of the day. Another advantage of checkin in the code in first half is that if any there is any error(say compiled) we get enough time to fix those and check in the code. Now it is upto you how you will manage your code...

Happy source code check-in....

EPC Cloud: Simplifying the Internet of Things Thanks to Web Patterns: Cloud Computing & REST (Part 1/3)

EPC Cloud: Simplifying the Internet of Things Thanks to Web Patterns: Cloud Computing & REST (Part 1/3)

Factory Method pattern in java

The factory method pattern is an object-oriented design pattern to implement the concept of factories. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. The creation of an object often requires complex processes not appropriate to include within a composing object. The object’s creation may lead to a significant duplication of code, may require information not accessible to the composing object, may not provide a sufficient level of abstraction, or may otherwise not be part of the composing object’s concerns. The factory method design pattern handles these problems by defining a separate method for creating the objects, which subclasses can then override to specify the derived type of product that will be created.

Factory pattern comes into creational design pattern category, the main objective of the creational pattern is to instantiate an object and in Factory Pattern an interface is responsible for creating the object but the sub classes decides which class to instantiate. It is like the interface instantiate the appropriate sub-class depending upon the data passed. Here in this article we will understand how we can create an Factory Pattern in Java
The essence of the Factory method Pattern is to “Define an interface for creating an object, but let the subclasses decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses

Use the factory pattern when:
  1.   The creation of the object precludes reuse without significantly duplicating code.
  2.  The creation of the object requires access to information or resources not appropriate to contain within the composing object.
  3.  The lifetime management of created objects needs to be centralised to ensure consistent behavior.
package javainsider.pattern.factory;
public abstract class PrintSomething {
public abstract void printTech();
Now we will have the concrete implementations of the printSomething class, JavaTech and J2eeTech, each providing a much simplified implementation for the printTech() method.
package javainsider.pattern.factory;
public class JavaTech extends printSomething {
public void printTech()
System.out.println(“this is java technology”);
We will having one more class for j2eeTech for j2ee technology.
package javainsider.pattern.factory;
public class J2eeTech extends PrintSomething {
public void printTech()
System.out.println(“this is j2ee technology”);
Now let us come to the core implementation, the Factory class itself. The PrintFactory class has one static method called showPrint() which the clients can invoke to get the printSomething object. Note the return type of the method, it is neither JavaTech nor J2eeTech, but the super type of the both, i.e, printSomething. Whether the return type of method is JavaTech or J2eeTech is decided based on the input operating system.
package javainsider.pattern.factory;
public class PrintFactory {
public static PrintSomething showPrint(String os){
if (os.equals(“Java”))
return new JavaTech();
else if (os.equals(“J2ee”))
return new J2eeTech();
return null
In this we can makes use of the above PrintFactory class. The client is un-aware of the fact there is multiple implementations of the printSomething class. It accesses the printTech() operation through a single unified type printSomething.
package javainsider.pattern.factory;
public class FactoryClient {
public static void main(String[] args) {
PrintSomething psJava =PrintFactory.showPrint(“Java”);
PrintSomething psJ2ee = PrintFactory.showPrint(“j2ee”);