Productive Programming with Groovy

Are you a Java programmer having wrist pain typing a lot (yes, I have!)? Does your mind keep swinging from loving to hating Java? Do you want to become more productive without leaving your world of Java? If so, this presentation is for you. I have been experimenting with Groovy for the last three months and I'm loving it - I am not going back to programming in plan old Java anymore. I'm attaching the full source code (as a .zip file) so that you can try them out on your own. Have fun! 

Productive programming with groovy - an introduction from Ganesh SG

How much do you know about smells in design?

Do you know that there are more than 500 design smells documented in literature or reported by designers? Do you know that all smells could be viewed as violation of underlying design principles? Do you need a ready catalog of design smells that is grounded on research and relevant for practice? 

Interested? Check the results of our research work on design smells and how the results can help you in practice. 

This presentation summarizes research behind our design smells work: 
http://www.slideshare.net/sgganesh/principle-based-classification-of-design-smells

Principle based classification of design smells from Ganesh SG

Our original paper is here: http://www.jot.fm/issues/issue_2013_06/article1.pdf 

This presentation is practical - it follows an example driven approach for design smells: 
http://www.slideshare.net/sgganesh/refactoring-for-design-smells

Refactoring for design smells from Ganesh SG

Hope you enjoy reading them! And yes, please do share your thoughts.

Latest release of the book fixes reported errors in the book!

We took up the task of writing the book in an incredibly tight schedule. We wanted the book to be out as soon as the beta exam becomes the final exam, and we missed that deadline only by a month or so. Given the fact that both of us (Tushar and myself) have a full-time demanding job, hyperactive kids in our respective homes, and short deadlines, we're extremely happy that our book came out to the market as the first book on OCPJP 7 exam preparation. 

With the tight schedule, we couldn't get much time for reviews and rigorous checks, and quite a few mistakes slipped into the production version of the book - that is the major criticism of our book. We are thankful to our readers who were supportive of us as well as reported bugs. Now, all the known mistakes are fixed in the book and the updated version is available in ebook form and Print-On-Demand books; for the print version, for the further reprints, this updated version will be available. We thank the Apress team for helping us in updating the book and making it available for all the resellers. 

Our hearty thanks to the all the readers who were patient with us and helped us by reporting the errors in the errata page for the book in this blog. We've copied the image from the book acknowledgement section of the book (if we have missed anyone in this list, we are sorry for that and please do let us know): 



Note that the book in its current form is quite comprehensive, covers almost all topics in required depth, and uses an example-driven approach which makes the concepts easier to understand. Given the fact that this is the only book (to our knowledge) to *prepare* for OCPJP 7 exam available in the market, we hope that this updated version is very helpful to our readers. 

Revised cost for OCPJP 7 exam

Good news for all OCPJP 7 aspirants. Oracle has brought down the exam cost for OCPJP 7 exam. The revised exam cost (for 1Z0-804) is $245 (thus, you save $55). Here is the link to the Oracle site.

It is applicable for OCPJP upgrade exam i.e. 1Z0-805 too. Check out this link for details.

Cheers :)

Participate in CodeRanch discussion and win a copy of OCPJP7 book!

Forwarding the mail from Java Ranch Moose (slight editing to save space):

---------- Forwarded message ----------
From: Java Ranch Moose <mmoose@javaranch.com>
Date: Tue, Aug 20, 2013 at 9:37 AM
Subject: Book Promo: "Oracle Certified Professional Java SE 7 Programmer Exams" & A Choice of "Agile and PMP Certification" Products
To: Java Ranch Moose <mmoose@javaranch.com>

We are thrilled to have S G Ganesh & Tushar Sharma on the ranch to promote
the book "Oracle Certified Professional Java SE 7 Programmer Exams 1Z0-804
and 1Z0-805: A Comprehensive OCPJP 7 Certification Guide".

The promotion will be held in the Programmer Certification (SCJP/OCPJP)
forum which can be found here:

http://www.coderanch.com/forums/f-24/java-programmer-SCJP

Participate in this week's giveaway by asking S G Ganesh & Tushar Sharma
a question or two and you may win a copy of the book!

The giveaway starts on Tuesday, August 20th 2013.
The drawing will be held on Friday, August 23rd 2013.

For more info or if you're plumb tired of getting this info, visit:
http://www.coderanch.com/how-to/java/BookPromotions

---------- End Forwarded message ----------

Congratulations to all the four winners :-) 
From https://www.coderanch.com/how-to/java/BookPromotionsWinnersPage

August 20

Oracle Certified Professional Java SE 7 Programmer Exams 1Z0-804 and 1Z0-805: A Comprehensive OCPJP 7 Certification Guide

S G Ganesh & Tushar Sharma

Apress

Alam Ameghino, Fakih Karademir, S Gaurav, Mphatheleni Ernest Matidze

Updated exam topics for OCPJP 7

Recently, Oracle has updated the exam topics for OCPJP 7 exam. The intention is to clarify the scope of the exam.

You can download the exam topics from here.

Understanding IllegalThreadStateException, IllegalMonitorStateException and thread states

There was a question on IllegalMonitorStateException and thread states in CodeRanch (http://www.coderanch.com/t/616837/java-programmer-SCJP/certification/state). Since it is a general topic of interest to most OCPJP7 aspirants, I'm posting the expanded version of the answer I gave as blog entry here.  

Basic thread states 

A thread has various states during its lifetime. Three basic thread states to understand are – new, runnable and terminated. We will discuss more thread states a bit later. 

A program can access the state of the thread using Thread.State enumeration. The Thread class has the getState() instance method which returns the current state of the thread. Here is an example: 
class BasicThreadStates extends Thread {  
    public static void main(String []s) throws Exception {  
        Thread t = new Thread(new BasicThreadStates());  
        System.out.println("Just after creating thread; \n" +   
                "   The thread state is: " + t.getState());   
        t.start();  
        System.out.println("Just after calling t.start(); \n" +   
                "   The thread state is: " + t.getState());  
        t.join();   
        System.out.println("Just after main calling t.join(); \n" +   
                "   The thread state is: " + t.getState());  
    }  
}  

This program prints: 

Just after creating thread;   
    The thread state is: NEW  
Just after calling t.start();   
    The thread state is: RUNNABLE  
Just after main calling t.join();   

    The thread state is: TERMINATED  

Just after the creation of the thread and just before calling the start() method on that thread, the thread is in the new state. After calling the start() method, the thread is ready to run or is in the running state (which we cannot determine); so it is in runnable state. From the main() method, we are calling t.join(). The main() method waits for the thread t to die. So once the statement t.join() successfully gets executed by main() thread, it means that the thread t has died or terminated. So, the thread is in the terminated state now. 

A word of advice: be careful about accessing the thread states using the getState() method. Why? By the time you acquire information on a thread state and print it, the state could have changed! I know the last statements could be confusing. To understand the problem with getting thread state information using the getState() method, consider the previous example. In one sample run of the same program, it printed the following: 
Just after creating thread;   
        The thread state is: NEW  
Just after calling t.start();   
        The thread state is: TERMINATED  
Just after main calling t.join();   

        The thread state is: TERMINATED  

Note the red italicized part of the output, the statement after printing “Just after calling t.start();”. In the initial output, we got the thread state (as expected) as RUNNABLE state. However, in another execution of the same program without any change, it printed the state as TERMINATED. Why? In this case, the thread is dead before we could get a chance to check it and print its status! [Note that we have not implemented the run() method in the BasicThreadStates class, so the default implementation of the run() method does nothing, and terminates quickly.] 

More thread states 

A thread can also be in blocked, waiting, timed_waiting states—which we’ll discuss now. I've attached a figure with this post which shows how and when the state transitions typically happen for these six states. You can use Thread.State enumeration which has the list of possible thread states. Here is a simple program that prints the value of the states in this enumeration: 

class ThreadStatesEnumeration {  
    public static void main(String []s) {  
        for(Thread.State state : Thread.State.values()){  
            System.out.println(state);  
        }  
    }  

}  

It prints: 
NEW  
RUNNABLE  
BLOCKED  
WAITING  
TIMED_WAITING  

TERMINATED  

Now let us discuss exceptions. 

IllegalThreadStateException 

Here is a program that throws IllegalThreadStateException

class ThreadStateProblem {

                public static void main(String []s) {

                                Thread thread = new Thread();

                                thread.start();

                                thread.start();

                }

}

The program fails with this stack trace:

Exception in thread "main" java.lang.IllegalThreadStateException

                at java.lang.Thread.start(Unknown Source)

                at ThreadStateProblem.main(ThreadStateProblem.java:6)

Here, we are trying to start a thread that has already started. When we call start(), the thread moves to “new” state. There is no proper state transition from “new” state if we call start() again; so the JVM throws IllegalThreadStateException. 

IllegalMonitorStateException

Here is a program that results in a IllegalMonitorStateException: 

class ThreadStateProblem extends Thread {

                public void run() {

                                try {

                                                wait(1000);

                                }

                                catch(InterruptedException ie) {

                                                // its okay to ignore this exception since we’re not

                                                // interrupting exceptions in this code

                                                ie.printStackTrace();

                                }

                }

               

                public static void main(String []s) {

                                new ThreadStateProblem().start();

                }

}

This program crashes like this:

Exception in thread "Thread-0" java.lang.IllegalMonitorStateException

                at java.lang.Object.wait(Native Method)

                at ThreadStateProblem.run(ThreadStateProblem.java:4)

The wait(int) method (with or without timeout value) should be called only after acquiring a lock: a wait() call adds the thread to the waiting queue of the acquired lock. If we don’t do that, there is no proper transition from the running state to timed_waiting (or waiting state in case timeout value in not given) can happen. So, the program crashes by throwing IllegalMonitorStateException exception.

The correct fix is to acquire the lock before calling wait(). In this case, we can declare the run() method synchronized:

synchronized public void run() {

                try {

                                wait(1000);

                }

                catch(InterruptedException ie) {

                                // its okay to ignore this exception since we’re not

                                // interrupting exceptions in this code

                                ie.printStackTrace();

                }

}

Since the run() method is synchronized, the wait() will add itself to the this object reference lock. Since there is no one calling the notify()/notifyAll() method, after timeout of 1 second (1000 milliseconds) is over, it will return from the run() method. So, the wait(1000); statement behaves almost like sleep(1000) statement; the difference is that calling wait() releases the lock on this object when it waits while sleep() call will not release the lock when it sleeps.

So, the key observation is that: We must call wait and notify/notifyAll only after acquiring the relevant lock. 

Difference between these exceptions 

If you already did not recognize,  IllegalThreadStateException is different from IllegalMonitorStateException. 

Here is the description of IllegalThreadStateException from JavaDoc: "Thrown to indicate that a thread is not in an appropriate state for the requested operation. See, for example, the suspend and resume methods in class Thread." 

Here is the description of IllegalMonitorStateException from JavaDoc: "Thrown to indicate that a thread has attempted to wait on an object's monitor or to notify other threads waiting on an object's monitor without owning the specified monitor." 

In both the cases, we need to be careful about thread states. In case of IllegalThreadStateException, it is about attempted illegal transition in thread states (and is nothing to do with locks). Whereas with IllegalMonitorStateException, it is about holding a lock - it occurs when attempting to call methods such as wait or  notify on an object that does not hold the lock.