Testing Websites

I will be updating this post with links and content I find and use for testing the websites.

• To test the websites on different browsers go to http://browsershots.org/ 
• This link has the best 15 tools to test the websites
  http://www.contrivedigital.com/our-blog/15-tools-for-testing-your-website-on-multiple-browsers/

Javadoc Tutorial

Javadoc Tutorial

Introduction

• Javadoc is a tool that generates html documentation (similar to the reference pages at java.sun.com) from Javadoc comments in the code.  In this tutorial we will go over how to write basic Javadoc comments and how to use features of Javadoc to generate html documentation.

Javadoc Comments

• Javadoc recognizes special comments  /** .... */ which are highlighted blue by default in Eclipse (regular comments // and /* ... */ are highlighted green).
• Javadoc allows you to attach descriptions to classes, constructors, fields, interfaces and methods in the generated html documentation by placing Javadoc comments directly before their declaration statements.  
• Here's an example using Javadoc comments to describe a class, a field and a constructor:
      

  /** Class Description of MyClass */
  public class MyClass
  {
   /** Field Description of myIntField */
   public int myIntField;

   /** Constructor Description of MyClass() */
   public MyClass()
   {
    // Do something ...
   }
  }

Javadoc Tags

• Tags are keywords recognized by Javadoc which define the type of information that follows.
• Tags come after the description (separated by a new line).
• Here are some common pre-defined tags:
  • @author [author name] - identifies author(s) of a class or interface.
  • @version [version] - version info of a class or interface.
  • @param [argument name] [argument description] - describes an argument of method or constructor.
  • @return [description of return] - describes data returned by method (unnecessary for constructors and void methods).
  • @exception [exception thrown] [exception description] - describes exception thrown by method.
  • @throws [exception thrown] [exception description] - same as @exception.
• Here's an example with tags:
  

  /** Description of MyClass 
   *
   * @author John Doe
   * @author Jane Doe
   * @version 6.0z Build 9000 Jan 3, 1970.
   */
  public class MyClass
  {
   /** Description of myIntField */
   public int myIntField;

   /** Description of MyClass() 
    * 
    * @throws MyException   Description of myException
    */
   public MyClass() throws myException
   {
    // Blah Blah Blah...
   }
   

   /** Description of myMethod(int a, String b)
    * 
    * @param a   Description of a
    * @param b   Description of b
    * @return   Description of c
    */
   public Object myMethod(int a, String b)
   {
    Object c;
    // Blah Blah Blah...
    return c;
   }
  }

Javadoc Compilation

• To generate the html documentation, run Javadoc followed by the list of source files, which the documentation is to be generated for, in the command prompt (i.e. Javadoc [files]).
• Javadoc also provides additional options which can be entered as switches following the Javadoc command (i.e. Javadoc [options] [files]).
• Here are some basic Javadoc options:
  • -author - generated documentation will include a author section
  • -classpath [path] - specifies path to search for referenced .class files.
  • -classpathlist [path];[path];...;[path] - specifies a list locations (separated by ";") to search for referenced .class files.
  • -d [path] - specifies where generated documentation will be saved.
  • -private - generated documentation will include private fields and methods (only public and protected ones are included by default).
  • -sourcepath [path] - specifies path to search for .java files to generate documentation form.
  • -sourcepathlist [path];[path];...;[path] - specifies a list locations (separated by ";") to search for .java files to generate documentation form.
  • -version - generated documentation will include a version section
• Some examples
  • Basic example that generates and saves documentation to the current directory (c:\MyWork) from A.java and B.java in current directory and all .java files in c:\OtherWork\.
    • c:\MyWork> Javadoc A.java B.java c:\OtherWork\*.java 
  • More complex example with the generated documentation showing version information and private members from all .java files in c:\MySource\ and c:\YourSource\ which references files in c:\MyLib and saves it to c:\MyDoc.
    •  c:\> Javadoc -version -private -d c:\MyDoc -sourcepathlist c:\MySource;c:\YourSource\ -classpath c:\MyLib

Javadoc In Eclipse 3.0

• Eclipse can generate Javadoc comments for classes and methods.
  1. Place the cursor in the text of class of method declaration.
  2. Right Click->Source->Add Javadoc Comment.
  3. Javadoc comments with appropriate tags are generated, but you still have to write the descriptions.
• Eclipse can also compile Javadocs for projects/packages/classes in the workspace.
  • Set location of Javadoc command and export your project/package/class as a Javadoc:
    1. File->Export.
    2. Select Javadoc and enter the path of Javadoc.exe, i.e. [Path of J2SE 1.5 SDK]\bin\javadoc.exe (e.g. c:\j2sdk1.5.0\bin\javadoc.exe).
    3. Also choose your export destination and click Next.
    4. In the Generate Javadoc Window, select the project/package(s)/class(es) you want to compile Javadocs for, select the visibility, and enter the path of the destination folder.
    5. Click Finish.

Javadoc References

• Javadoc is a powerful tool with many more features, for more information check out the following links:
  • Sun's Javadoc Homepage: http://java.sun.com/j2se/javadoc/index.html
  • How to write Javadoc comments: http://java.sun.com/j2se/javadoc/writingdoccomments/index.html
  • How to use the Javadoc command: http://java.sun.com/j2se/1.5/docs/tooldocs/windows/javadoc.html

Source: http://students.cs.byu.edu/~cs240ta/fall2012/tutorials/javadoctutorial.html

Flerry And Flex - Work well together

After trying out a simple exercise with Flerry and Flex Air I am confident that we could get away with Java Swing completely and use Adobe flex as the front end for desktop application development.

I have replaced a few of my utility programs from Java Swing into Flex and they work very well.

For those who are new to Flerry , please follow the links to find out more..

http://code.google.com/p/flerry/

Video Tutorials:
https://vimeo.com/13850127
https://vimeo.com/13850127

A few simple setup instructions to get it going.

1. First create a Java project in Eclipse
2. Rename the src folder to src-java using refactoring tool. This is required to differentiate flex and java code.
3. Add your Java classes and packages.
4. Go to Flash perspective and Add the project type "Flex project "
5. Since it will be a Desktop application, convert it to Air application using the Add project type on the properties of the project. 
6. Change the output of Java from bin to bin-debug/classes.
7. Un comment the line {supportedProfiles} from {project}-app.xml file and just leave the "extendeddesktop" in it. 
8. That should be it, download a demo project code from google.

java.lang.illegalargumentexception comparison method violates its general contract, Flex

java.lang.illegalargumentexception comparison method violates its general contract, flex.

This is a bug of the flex sdk mxmlc compiler running with JVM 1.6 or 1.7

Solution:
Adding the following argument to your eclipse.ini should resolve this issue:
-Djava.util.Arrays.useLegacyMergeSort=true 

Design patterns usage in Java SE and Java EE

Creational patterns

Abstract factory (recognizeable by creational methods returning an abstract/interface type)

java.util.Calendar#getInstance()
java.util.Arrays#asList()
java.util.ResourceBundle#getBundle()
java.net.URL#openConnection()
java.sql.DriverManager#getConnection()
java.sql.Connection#createStatement()
java.sql.Statement#executeQuery()
java.text.NumberFormat#getInstance()
java.lang.management.ManagementFactory (all getXXX() methods)
java.nio.charset.Charset#forName()
javax.xml.parsers.DocumentBuilderFactory#newInstance()
javax.xml.transform.TransformerFactory#newInstance()
javax.xml.xpath.XPathFactory#newInstance()
java.net.URLStreamHandlerFactory#createURLStreamHandler(String) (Returns singleton object per protocol)
______________________________________________________

Builder (recognizeable by creational methods returning the instance itself)

java.lang.StringBuilder#append() (unsynchronized)
java.lang.StringBuffer#append() (synchronized)
java.nio.ByteBuffer#put() (also on CharBuffer, ShortBuffer, IntBuffer, LongBuffer, FloatBuffer and DoubleBuffer)
javax.swing.GroupLayout.Group#addComponent()
All implementations of java.lang.Appendable 
______________________________________________________

Factory method (recognizeable by creational methods returning a concrete type)

java.lang.Object#toString() (overrideable in all subclasses)
java.lang.Class#newInstance()
java.lang.Integer#valueOf(String) (also on Boolean, Byte, Character, Short, Long, Float and Double) 
java.lang.Class#forName()
java.lang.reflect.Array#newInstance()
java.lang.reflect.Constructor#newInstance() 
______________________________________________________

Prototype (recognizeable by creational methods returning a different instance of itself with the same properties)

java.lang.Object#clone() (the class has to implement java.lang.Cloneable) 
______________________________________________________

Singleton (recognizeable by creational methods returning the same instance (usually of itself) everytime)

java.lang.Runtime#getRuntime()
java.awt.Desktop#getDesktop() 
______________________________________________________

Structural patterns

Adapter (recognizeable by creational methods taking an instance of different abstract/interface type and returning an implementation of own/another abstract/interface type which decorates/overrides the given instance)

java.io.InputStreamReader(InputStream) (returns a Reader)
java.io.OutputStreamWriter(OutputStream) (returns a Writer)
javax.xml.bind.annotation.adapters.XmlAdapter#marshal() and #unmarshal() 
______________________________________________________

Bridge (recognizeable by creational methods taking an instance of different abstract/interface type and returning an implementation of own abstract/interface type which delegates/uses the given instance)
None comes to mind yet. A fictive example would be new LinkedHashMap(LinkedHashSet<K>, List<V>) which returns an unmodifiable linked map which doesn't clone the items, but uses them.

The java.util.Collections#newSetFromMap() and singletonXXX() methods however comes close. 
______________________________________________________

Composite (recognizeable by behavioral methods taking an instance of same abstract/interface type into a tree structure)

java.awt.Container#add(Component) (practically all over Swing thus)
javax.faces.component.UIComponent#getChildren() (practically all over JSF UI thus) 
______________________________________________________

Decorator (recognizeable by creational methods taking an instance of same abstract/interface type which adds additional behaviour)

All subclasses of java.io.InputStream, OutputStream, Reader and Writer have a constructor taking an instance of same type.
java.util.Collections, the checkedXXX(), synchronizedXXX() and unmodifiableXXX() methods.
javax.servlet.http.HttpServletRequestWrapper and HttpServletResponseWrapper 
______________________________________________________

Facade (recognizeable by behavioral methods which internally uses instances of different independent abstract/interface types)

javax.faces.context.FacesContext, it internally uses among others the abstract/interface types LifeCycle, ViewHandler, NavigationHandler and many more without that the enduser has to worry about it (which are however overrideable by injection).
javax.faces.context.ExternalContext, which internally uses ServletContext, HttpSession, HttpServletRequest, HttpServletResponse, etc. 
______________________________________________________

Flyweight (recognizeable by creational methods returning a cached instance, a bit the "multiton" idea)

java.lang.Integer#valueOf(int) (also on Boolean, Byte, Character, Short, Long, Float and Double) 
______________________________________________________

Proxy (recognizeable by creational methods which returns an implementation of given abstract/interface type which in turn delegates/uses a different implementation of given abstract/interface type)

java.lang.reflect.Proxy
java.rmi.*, the whole API actually. 
The Wikipedia example is IMHO a bit poor, lazy loading has actually completely nothing to do with the proxy pattern at all.
______________________________________________________

Behavioral patterns

Chain of responsibility (recognizeable by behavioral methods which (indirectly) invokes the same method in another implementation of same abstract/interface type in a queue)

java.util.logging.Logger#log()
javax.servlet.Filter#doFilter() 
______________________________________________________

Command (recognizeable by behavioral methods in an abstract/interface type which invokes a method in an implementation of a different abstract/interface type which has been encapsulated by the command implementation during its creation)

All implementations of java.lang.Runnable
All implementations of javax.swing.Action
______________________________________________________

Interpreter (recognizeable by behavioral methods returning a structurally different instance/type of the given instance/type; note that parsing/formatting is not part of the pattern, determining the pattern and how to apply it is)

java.util.Pattern
java.text.Normalizer
All subclasses of java.text.Format
All subclasses of javax.el.ELResolver 
______________________________________________________

Iterator (recognizeable by behavioral methods sequentially returning instances of a different type from a queue)

All implementations of java.util.Iterator (thus among others also java.util.Scanner!).
All implementations of java.util.Enumeration 
______________________________________________________

Mediator (recognizeable by behavioral methods taking an instance of different abstract/interface type (usually using the command pattern) which delegates/uses the given instance)

java.util.Timer (all scheduleXXX() methods)
java.util.concurrent.Executor#execute()
java.util.concurrent.ExecutorService (the invokeXXX() and submit() methods)
java.util.concurrent.ScheduledExecutorService (all scheduleXXX() methods)
java.lang.reflect.Method#invoke() 
______________________________________________________

Memento (recognizeable by behavioral methods which internally changes the state of the whole instance)

java.util.Date (the setter methods do that, Date is internally represented by a long value) 
All implementations of java.io.Serializable
All implementations of javax.faces.component.StateHolder 
______________________________________________________

Observer (or Publish/Subscribe) (recognizeable by behavioral methods which invokes a method on an instance of another abstract/interface type, depending on own state)

java.util.Observer/java.util.Observable (rarely used in real world though)
All implementations of java.util.EventListener (practically all over Swing thus)
javax.servlet.http.HttpSessionBindingListener
javax.servlet.http.HttpSessionAttributeListener
javax.faces.event.PhaseListener 
______________________________________________________

State (recognizeable by behavioral methods which changes its behaviour depending on the instance's state which can be controlled externally)

javax.faces.lifecycle.LifeCycle#execute() (controlled by FacesServlet, the behaviour is dependent on current phase (state) of JSF lifecycle) 
______________________________________________________

Strategy (recognizeable by behavioral methods in an abstract/interface type which invokes a method in an implementation of a different abstract/interface type which has been passed-in as method argument into the strategy implementation)

java.util.Comparator#compare(), executed by among others Collections#sort().
javax.servlet.http.HttpServlet, the service() and all doXXX() methods take HttpServletRequest and HttpServletResponse and the implementor has to process them (and not to get hold of them as instance variables!).
javax.servlet.Filter#doFilter() 
______________________________________________________

Template method (recognizeable by behavioral methods which already have a "default" behaviour definied by an abstract type)

All non-abstract methods of java.io.InputStream, java.io.OutputStream, java.io.Reader and java.io.Writer.
All non-abstract methods of java.util.AbstractList, java.util.AbstractSet and java.util.AbstractMap.
javax.servlet.http.HttpServlet, all the doXXX() methods by default sends a HTTP 405 "Method Not Allowed" error to the response. You're free to implement none or any of them. 
______________________________________________________

Visitor (recognizeable by two different abstract/interface types which has methods definied which takes each the other abstract/interface type; the one actually calls the method of the other and the other executes the desired strategy on it)

javax.lang.model.element.AnnotationValue and AnnotationValueVisitor
javax.lang.model.element.Element and ElementVisitor
javax.lang.model.type.TypeMirror and TypeVisitor 

_________________________________________________________________
Source copied from: StackOverflow

Android App Development

Error when starting to run your first Android App

"debug certificate expired android packaging problem"

Solution:
1) Simply delete the debug.keystore file located under
C:\Documents and Settings\.android\ on Windows XP, 
or in C:\Users\.android\ on Windows Vista and Windows 7.

WHY VISIT TEMPLES ? (Scientific Reason)

WHY VISIT TEMPLES ? (Scientific Reason)
There are thousands of temples all over India in different size, shape and locations but not all of them are considered to be built the Vedic way. Generally, a temple should be located at a place where earth's magnetic wave path passes through densely. It can be in the outskirts of a town/village or city, or in middle of the dwelling place, or on a hilltop. The essence of visiting a temple is discussed here.

Now, these temples are located strategically at a place where the positive energy is abundantly available from the magnetic and electric wave distributions of north/south pole thrust. The main idol is placed in the core center of the temple, known as "*Garbhagriha*" or *Moolasthanam*. In fact, the temple structure is built after the idol has been placed. This *Moolasthanam* is where earth’s magnetic waves are found to be maximum. We know that there are some copper plates, inscribed with Vedic scripts, buried beneath the Main Idol. What are they really? No, they are not God’s / priests’ flash cards when they forget the *shlokas*. The copper plate absorbs earth’s magnetic waves and radiates it to the surroundings. Thus a person regularly visiting a temple and walking clockwise around the Main Idol receives the beamed magnetic waves and his body absorbs it. This is a very slow process and a regular visit will let him absorb more of this positive energy. Scientifically, it is the positive energy that we all require to have a healthy life.

Further, the Sanctum is closed on three sides. This increases the effect of all energies. The lamp that is lit radiates heat energy and also provides light inside the sanctum to the priests or *poojaris* performing the pooja. The ringing of the bells and the chanting of prayers takes a worshipper into trance, thus not letting his mind waver. When done in groups, this helps people forget personal problems for a while and relieve their stress. The fragrance from the flowers, the burning of camphor give out the chemical energy further aiding in a different good aura. The effect of all these energies is supplemented by the positive energy from the idol, the copper plates and utensils in the *Moolasthan*am / *Garbagraham*. *Theertham*, the “holy” water used during the pooja to wash the idol is not
plain water cleaning the dust off an idol. It is a concoction of Cardamom,*Karpura* (Benzoin), zaffron / saffron, *Tulsi* (Holy Basil), Clove, etc...Washing the idol is to charge the water with the magnetic radiations thus increasing its medicinal values. Three spoons of this holy water is distributed to devotees. Again, this water is mainly a source of magneto-therapy. Besides, the clove essence protects one from tooth decay, the saffron & *Tulsi* leafs protects one from common cold and cough, cardamom and *Pachha Karpuram* (benzoin), act as mouth fresheners. It is proved that *Theertham* is a very good blood purifier, as it is highly energized. Hence it is given as *prasadam* to the devotees. This way, one can claim to remain healthy by regularly visiting the Temples. This is why our elders used to suggest us to offer prayers at the temple so that you will be cured of many ailments. They were not always superstitious. Yes, in a few cases they did go overboard when due to ignorance they hoped many serious diseases could be cured at temples by deities. When people go to a temple for the *Deepaaraadhana*, and when the doors open up, the positive energy gushes out onto the persons who are there. The water that is sprinkled onto the assemblages passes on the energy to all. This also explains why men are not allowed to wear shirts at a few temples and women are requested to wear more ornaments during temple visits. It is through these jewels (metal) that positive energy is absorbed by the women. Also, it is a practice to leave newly purchased jewels at an idol’s feet and then wear them with the idol’s blessings. This act is now justified after reading this article. This act of “seeking divine blessings” before using any new article, like books or pens or automobiles may have stemmed from this through mere observation.

Energy lost in a day’s work is regained through a temple visit and one is refreshed slightly. The positive energy that is spread out in the entire temple and especially around where the main idol is placed, are simply absorbed by one's body and mind. Did you know, every Vaishnava(Vishnu devotees), “must” visit a Vishnu temple twice every day in their location. Our practices are NOT some hard and fast rules framed by 1 man and his followers or God’s words in somebody’s dreams. All the rituals, all the practices are, in reality, well researched, studied and scientifically backed thesis which form the ways of nature to lead a good healthy life.

The scientific and research part of the practices are well camouflaged as “elder’s instructions” or “granny’s teaching’s” which should be obeyed as a mark of respect so as to once again, avoid stress to the mediocre brains.