JBoss Seam Best Practice and Samples
The most relevant “best practices” are in the seam examples themselves, that are bundled with seam. The wiki is a good example of a well written Seam app. It also has examples of other real-world best practice usage, such as caching, named queries, and even tests.
However, if you are looking for more real documentation, the seam framework website has links to a number of best practices in their KnowledgeBase:
http://sfwk.org/Documentation/KnowledgeBase
I have personally used these docs to do things like slimming down a JBoss server for production and reducing its overall footprint.
Curiously, there isn’t much on writing tests (a major “best practice” in my opinion) on this page. 
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.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:
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.
What will Java 7 mean for you?
New language features
try ( BufferedReader reader = new BufferedReader(new FileReader(...))) { String line = reader.readLine(); process(line);}
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 { clazz.getConstructor(List.class).newInstance(list);} catch (InstantiationException|IllegalAccessException|InvocationTargetException|NoSuchMethodException e) { throw new RuntimeException("I really don't care", e);}
Map<> ordersPerCustomer = new HashMap>();
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.
Conclusions
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 check-in….
Interface Vs. Abstract class
Abstract classes
Abstract class is class which contain one or more abstract methods, which is implemented by sub classes. An abstract class can contain no abstract methods but also containe mehtod with body. Abstract classes are useful in a situation when some general methods should be implemented and specialization behavior should be implemented by subclasses.Abstract class can contain private as well as protected members.
When to use Abstract Class-If we have a base class where all the classes will perform the same function, then we can define that in our Abstract class. If you plan on updating this base class throughout the life of your program, it is best to allow that base class to be an abstract class. Because you can make a change to it and all of the inheriting classes will now have this new functionality.
Interface
Interface is extremely useful when you don’t want a big hierarchical type framework. As interfaces are implicitly abstract, they cannot be directly instantiated except when instantiated by a class which implements the said interface. The class must implement all of the methods described in the interface, or be an abstract class. An Interface can only have public members. A class implementing an interface must implement all of the methods defined in the interface, while a class extending an abstract class need not implement any of the methods defined in the abstract class.Maintainability–if you want to add a new feature (method) in its contract, then you must implement those method in all of the classes which implement that interface. However, in the case of an abstract class, the method can be simply implemented in the abstract class and the same can be called by its subclass.Interfaces are slow as it requires extra indirection to to find corresponding method in in the actual class.
When To use interface – Interfaces are useful when you do not want classes to inherit from unrelated classes just to get the required functionality.It is used where there of chances adding new method in future. Interfaces are more used to set standards. interface gave merely a specification,nothing implemented for any standalone project which can be changed at will its more design flexible and it can be utilized to model multiple inheritance.
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:
- The creation of the object precludes reuse without significantly duplicating code.
- The creation of the object requires access to information or resources not appropriate to contain within the composing object.
- The lifetime management of created objects needs to be centralised to ensure consistent behavior.
PrintSomething.java
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.
JavaTech.java
package javainsider.pattern.factory;
public class JavaTech extends printSomething {
@Override
public void printTech()
{
System.out.println(“this is java technology”);
}
We will having one more class for j2eeTech for j2ee technology.
J2eeTech.java
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.
PrintFactory.java
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.
FactoryClient.java
package javainsider.pattern.factory;
public class FactoryClient {
public static void main(String[] args) {
PrintSomething psJava =PrintFactory.showPrint(“Java”);
psJava.printTech();
PrintSomething psJ2ee = PrintFactory.showPrint(“j2ee”);
psJ2ee.printTech();
}
Welcome To Java Technical Blog
Welcome to Java Technical Blog.
This blog is completely for people those who came from java j2ee background . All about Java Technology, Java related Technology and frameworks.
I will cover the following topic’s as follows:
- Java & J2EE Technology Discussion.
- Java with RFID Technology.
- Java with Near Field Communication(NFC).
- Java J2EE frameworks like Spring, Hibernate, Struts, JSF, JBoss Seam, JBoss Richfaces and many more.
Thank you visiting to my Java Technical blog.
With Best Regards,
RUDRA NARAYAN GARNAIK
www.garnaik.com : My Entertainment Blog.
http://java.garnaik.com – My Java FAQ blog.
