Wednesday, August 10, 2011

Very useful eclipse shortcuts which I generally use to make my coding fast


It’s always fast if you use keyboard as much as possible. I use many keyboard shortcuts while using eclipse and which makes me quick. Believe me these are really useful. The global shortcuts (Ctrl + F,     Ctrl + C, Ctrl + X, Ctrl + Y, Ctrl + V) everybody is aware of, so I am not explaining those in the list.
1. Ctrl + O – to see methods in a class (you can also use Ctrl + F3)
2. Ctrl + Shift + R – to see resources in your workspace (you can also type only the CAPITAL letters of your camel-case file name)
3. Ctrl + Shift + T – to see types (search only the java files, it also searches in jar files), this shortcut works only in Java/J2EE perspectives
4. Alt + left arrow – to go to previous place you were working.
5. Ctrl + D – to delete a line which causes the next line to move up to fill up the space
6. Alt + Up Arrow – to move a line up without cut-paste, it just crosses the line coming in between
7. Alt + Down Arrow – to move a line down without cut-paste, it just crosses the line coming in between
8. Ctrl + Shift + W – to close all the opened editors.
9. Ctrl + Shift + F6 – to switch between opened editor
10. Ctrl + M – to minimize/maximize a window.
11. Ctrl + Shift + F – formats the selected code otherwise formats the whole class.
12. F3 – to go to the declaration of the method.
13. Ctrl + Shift + Numpad_Divide – Collapse/Un-Collapse all the code and also the opened modules in the explorer
14. Alt + Shift + Q + Q (press Q twice) - to open a view
15. Alt + Shift + X – to run
16. Ctrl + Shift + G – to search references in workspace
17. Ctrl + Shift + K – to see where else a text is being used in the class
18. Ctrl + Space – code assist
19. Ctrl + T – to search for type (implementation in case of interface)
20. Ctrl + Shift + X – make all selected letters in CAPS
21. Ctrl + Shift + Y – make all selected letters in small case.
22. Ctrl + Numpad_Substract – Collapse
23. Ctrl + H – Search
24. Ctrl + Shift + U – search a text in a file (it’s like Ctrl + F showing all the results together)
25. Ctrl + G - declaration in workspace (it’s like google the workspace :) )
26. Alt + Shift + R – to rename all the occurrences of variable/class being renamed.
27. F12 – Activate editor. Suppose you are having a look at console just press F12 and you will reach the editor you were working on.
28. Ctrl + Alt + H – open call hierarchy
29. Ctrl + O + O (press O twice) – to see inherited members
30. Ctrl + Shift + O – Organize imports
31. F4 – open type hierarchy.
32. Ctrl + Shift + G – find text in workspace
33. Alt + Shift + M – extract method
34. Alt + Shift + L – extract local variable
35. Ctrl + B – build all
36. Ctrl + K – to see the next occurrence of the same text in the file. it depends on the settings in the Ctrl + F window. If you have selected wrap search in the FIND window then Ctrl + K will also do wrap search.
37. Ctrl + / – Comment/Uncomment the code
38. Ctrl + Q – go to last edited location
39. Ctrl + Alt + down arrow – copy a line a paste in the next line.
40. Alt + / – word completion
41. Ctrl + Shift + L – last but not the least, this shortcut will open all the shortcuts list you can use in eclipse. You can always open this when you are not that busy and have a look, you may find a shortcut which can actually help in your coding.

Tuesday, July 26, 2011

query to fetch table and column name using COLNO, TBSPACEID and TABLEID (DB2)

Generally using JDBC in Java we get JDBC errors containing COLNO, TBSPACEID and TABLEID information. But most of the times we ignore these things and try to look for bugs in our JAVA code. The statement below proves to be very helpful in fast debugging of exceptions.

SELECT tabname, 
       colname 
FROM   syscat.columns 
WHERE  colno = ? 
       AND tabname = (SELECT tabname 
                      FROM   syscat.tables 
                      WHERE  tbspaceid = ? 
                             AND tableid = ?) 

Small Statement which contains all the english albhabets (practice this to improve your typing skills)


“The quick brown fox jumps over the lazy dog.”
You can also type A to Z but you won’t get the feeling of actual typing then.

Tuesday, July 19, 2011

Freeware/OpenSource Essential Softwares a Software professional should have

1. Notepad++ (improved text editor)
2. WinMerge (a compare tool)
3. jd-gui (a decompiler)
4. FileZilla (FTP client)
5. A zip/unzip tool like 7zip or Alzip
6. Performance testing tool like JMeter.
7. PDF reader like Foxit or Nitro.
8. Open Office
9. MySQL database.
10. Client for MySQL like SqlYog.
11. An open source server like Apache Tomcat.
12. A code editor like eclipse/netbeans.
13. A desktop search utility like AvaFind to search files.
14. Logs viewer like Tail.
15. A screen capture utility like Gadwin PrintScreen.

Monday, July 18, 2011

Java : Effective Exception Handling

1. Use checked exceptions when you know that or you can recover  from the exception without any side affects.

2. The best use of exceptions is to translate exception in the calling method to the exception which is more appropriate for it and you should let the cause of the exception flow from the called methods to the calling methods.
                       For this you should have one of the constructors of your Exception classes like

class HigherLevelException extends Exception {
       HigherLevelException(Throwable cause) {
           super(cause);
       }
}

    You can also use the Throwable.initCause method for this if you don't have the constructor like the one above.

3. Don't use the 2nd point too much if the lower level method can get away with the exception. Don't overload the calling methods too much to handle the exceptions thrown by the lower methods.

4. If you are declaring your own exception class you can always include some methods or attributes which can be used to convey more about the exception when it occurs.


5. Try to reuse exceptions (comes generally when you are creating your own API). The most reusabel exceptions are

   IllegalArgumentException, IllegalStateException, NullPointerException, IndexArrayOutOfBounds and some more.

6. Most importantly, use Exceptions only for Exceptional conditions. Don't write your logic which is based on exceptions. For example, don’t do like this

// wrong usage of exception handling
try {
     someObject.someMethod();
} catch (NullPointerException npe)
{
    // other code
}

7. If rather than Exception you can have state testing method before actually using a state-dependent method like checking iterator.hasNext() before executing the iterator.next() method is more appropriate.

8. All of the unchecked throwables you implement should subclass  RuntimeException (directly or indirectly).

9. Use runtime exceptions to indicate programming errors. The great majority of runtime exceptions indicate precondition violations. A precondition violation is simply a failure by the client of an API to adhere to the contract established by the API specification. For example, the contract for array access specifies that the array index must be between zero and the array length minus one. ArrayIndexOutOfBoundsException indicates that this precondition was violated.

10. Always declare checked exceptions individually, and document precisely the conditions under which each one is thrown using the Javadoc @throws tag. Don’t take the shortcut of declaring that a method throws some superclass of multiple exception classes that it can throw. As an extreme example, never declare that a method “throws Exception” or, worse yet, “throws Throwable.”

11.Use the Javadoc @throws tag to document each unchecked exception that a method can throw, but do not use the throws keyword to include unchecked exceptions in the method declaration.  It is important that the programmers using your API be aware of which exceptions are checked and which are unchecked, as their responsibilities differ in these two cases. The documentation    generated by the Javadoc @throws tag in the absence of the method header generated by the throws declaration provides a strong visual clue to help the programmer distinguish checked exceptions from unchecked.

12. If an exception is thrown by many methods in a class for the same reason, it is acceptable to document the exception in the class’s documentation comment rather than documenting it individually for each method. A common example is NullPointerException. It is fine for a class’s documentation comment to say, “All methods in this class throw a NullPointerException if a null object reference is passed in any parameter,” or words to that effect.

13. To capture the failure, the detail message of an exception should contain the values of all parameters and fields that “contributed to the exception. You must write the toString() method of your exception carefully.


14. Failure Atomicity(Object remains in consistence state after a failure)-ways to achieve failure atomicity:


a. A closely related approach to achieving failure atomicity is to order the computation so that any part that may fail takes place before any part that modifies the object.

b. This approach is a natural extension of the previous one when arguments cannot be checked without performing a part of the computation.

c. A third and far less common approach to achieving failure atomicity is to write recovery code that intercepts a failure that occurs in the midst of an operation and causes the object to roll back its state to the point before the operation began. This approach is used mainly for durable (disk-based) data structures.

d. A final approach to achieving failure atomicity is to perform the operation on a temporary copy of the object and to replace the contents of the object with the temporary copy once the operation is complete. This approach occurs naturally when the computation can be performed more quickly  once the data has been stored in a temporary data structure. For example, Collections.sort dumps its input list into an array prior to sorting to reduce the cost of accessing elements in the inner loop of the sort. This is done for performance, but as an added benefit, it ensures that the input list will be untouched if the sort fails.
              As a rule, any generated exception that is part of a method’s specification should leave the object in the same state it was in prior to the method invocation. Where this rule is violated, the API documentation should clearly indicate what state the object will be left in.


15. An empty catch block defeats the purpose of exceptions, which is to force you to handle exceptional conditions. At the very least, the catch block should contain a comment explaining why it is appropriate to ignore the exception.