Heena Agarwal

Karthik Shiraly wrote:In fact, I took this course because other ranchers here had good things to say about it. You might find the previous discussion on it quite informative.

For some reason my posts in that thread seem too discouraging. I think it's not too difficult to complete this course with a full time job if that job and your chores give you a healthy lifestyle.

These days you get two weeks to complete the assignment without penalty and almost about a month to complete it with little penalty. That is really a cool thing. To anybody considering to take up this course, I'd say, go for it.

Amar Saikia wrote:This Algo class again started from 13th June. Probable this time we can pick up from where we left. Is anyone else doing this time?

I am not doing the algorithms' course but I have the videos and I did refer to a few of their videos much later. I want to do this course. And I will as soon as I can...
How is the course coming along for you?

Are you ok with paperback quality? If so, I think you can order 'Java SE8 for the really impatient' online from flipkart.com. Following is the link.

http://www.flipkart.com/java-se-8-really-impatient/p/itmdkhymh5jdkygz?pid=9780321927767&otracker=from-search&srno=t_1&query=java+8+for+the+really+impatient&ref=6a352b1c-06f8-4296-8b58-09666cda7840


I have ordered books from flipkart many times and my books have arrived in time and in good condition.

Edit : I know you said hard cover. But I don't know if there's any Java 8 book that is available in hard cover in any part of the world currently. I only see kindle and paperback editions in the following page.
http://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Dstripbooks&field-keywords=java+8

Is it because of '? extends ' instead of '? super' expression, the compiler wont let me add anything to the list.

Yes.
But it's important to understand why. I suggest you go through the following post also

https://coderanch.com/t/627111/java-programmer-SCJP/certification/difference-List-super-Dog-animals#2869356

and try to understand the question and the responses. I think that might give you more clarity.

No idea what you mean by a rock solid singleton, but reflection attack is possible with your implementation.

import java.lang.reflect.Constructor; import java.lang.reflect.InvocationTargetException; public class LoggerImpl { public static void main(String [] args) { Logger firstLogger = Logger.getInstance(); Logger secondLogger = null; Class<Logger> clazz = Logger.class; Constructor<Logger> cons; try { cons = clazz.getDeclaredConstructor(); cons.setAccessible(true); secondLogger = cons.newInstance(); } catch ( NoSuchMethodException | SecurityException | InstantiationException | IllegalAccessException | IllegalArgumentException | InvocationTargetException e) { e.printStackTrace(); } System.out.println(firstLogger == secondLogger); System.out.println(firstLogger.hashCode()); System.out.println(secondLogger.hashCode()); } }

The output of the above mentioned code is --

false
1741555911
128087567

Tushar Goel wrote:But i want to know why problem is coming with first option and which one is more elegant to use.

Hi Tushar,

I've been trying to work on your problem for my own learning. Following is what I think is the case.

An uncaught exception handler is not really the same thing as any other catch block. A catch block catches an exception and prevents the thread that threw the exception from terminating if the exception is successfully caught, i.e if the catch block does not result in another exception being thrown. An uncaught exception handler on the other hand is just a facility provided by the Thread class to enable the thread to do additional things before it terminates. Those additional things could be anything - like for example, sending an email to an admin, logging, starting a new Thread -- it really depends on your use case.

In case of worker threads like configurations, the worker thread has no idea of what kind of tasks it is going to run. Some tasks can be nicely coded, but the worker thread has no way of knowing that. So if a worker thread is supposed to execute say 10 tasks, and say task number 5 throws an uncaught RuntimeException, it could terminate the worker thread. This is not what you'd want. This is one of the cases where the uncaught exception handlers come in handy. I could have the uncaught exception handler start another worker thread to execute the remaining tasks. But this wouldn't happen just by implementing the Thread.UncaughtExceptionHandler interface and coding the uncaughtException method to just log the exception. Unlike a catch block, an uncaught exception handler does not prevent the original thread from terminating.

The JLS says the following about the UncaughtExceptionHandlers.

JLS wrote:During the process of throwing an exception, the Java Virtual Machine abruptly completes, one by one, any expressions, statements, method and constructor invocations, initializers, and field initialization expressions that have begun but not completed execution in the current thread. This process continues until a handler is found that indicates that it handles that particular exception by naming the class of the exception or a superclass of the class of the exception (§11.2). If no such handler is found, then the exception may be handled by one of a hierarchy of uncaught exception handlers (§11.3) - thus every effort is made to avoid letting an exception go unhandled.

JLS wrote:If no catch clause that can handle an exception can be found, then the current thread (the thread that encountered the exception) is terminated. Before termination, all finally clauses are executed and the uncaught exception is handled according to the following rules:

If the current thread has an uncaught exception handler set, then that handler is executed.

Otherwise, the method uncaughtException is invoked for the ThreadGroup that is the parent of the current thread. If the ThreadGroup and its parent ThreadGroups do not override uncaughtException, then the default handler's uncaughtException method is invoked.

Let us consider an example. I have a Task class as follows.

package threadandsynchronization; import java.io.BufferedWriter; import java.io.FileWriter; import java.io.IOException; public class Task { private final int i; private final StringBuilder str; Task(int i, StringBuilder string ) { this.i = i; this.str = string; } public int getI() { return this.i; } protected void execute() { System.out.println(Thread.currentThread().getName()); try (BufferedWriter fw = new BufferedWriter (new FileWriter("temp.txt")); ) { fw.write(str.toString()); System.out.println(Thread.currentThread().getName() + " is running task number " + i); if (i==0 || i ==5) { throw new RuntimeException("Some stupid RE"); } } catch (IOException e) { e.printStackTrace(); } /*catch(Throwable e) { e.printStackTrace(); }*/ System.out.println("After catch in the task "+ i); } }

Following is my worker thread's implementation. MyRunner is a Runnable that executes tasks in a list within its run method.

package threadandsynchronization; import java.util.*; import java.util.concurrent.LinkedBlockingQueue; public class MyRunner implements Runnable { private final List<Task> list; private MyRunner(List<Task> list) { this.list = list; for ( int i =0; i<10; i++) { StringBuilder str = new StringBuilder("Number"); str.append(i); list.add(new Task(i, str)); } } MyRunner(List<Task> list, boolean copy) { if (!copy || list == null) { throw new IllegalArgumentException(); } this.list = list; } @Override public void run() { Iterator<Task> iter = list.listIterator(); while(iter.hasNext()) { Task t = iter.next(); iter.remove(); t.execute(); System.out.println(Thread.currentThread().getName() + "is done executing task " + t.getI()); } System.out.println("After all tasks have started"); } public static void main(String[] args) { MyRunner runner = new MyRunner(new ArrayList<Task>()); //MyRunner.UncaughtExceptions uch = runner.new UncaughtExceptions(); Thread t = new Thread(runner); //t.setUncaughtExceptionHandler(uch); t.start(); } /*class UncaughtExceptions implements Thread.UncaughtExceptionHandler { public void uncaughtException(Thread t, Throwable e){ System.out.println("Uncaught Exception received. Recieved error on " + t.getName() + " thread. " + e.getMessage()); MyRunner newRunner = new MyRunner(MyRunner.this.list, true); MyRunner.UncaughtExceptions uch = newRunner.new UncaughtExceptions(); Thread t1 = new Thread(newRunner); t1.setUncaughtExceptionHandler(uch); t1.start(); } }*/ }

If I run the MyRunner class with the commented part as commented, I get the following output.

Thread-0
Thread-0 is running task number 0
Exception in thread "Thread-0" java.lang.RuntimeException: Some stupid RE
at threadandsynchronization.Task.execute(Task.java:28)
at threadandsynchronization.MyRunner.run(MyRunner.java:36)
at java.lang.Thread.run(Unknown Source)

So an exception in the 1st task has terminated my worker and hence tasks 1 till 9 could not run. Obviously if the Task class had a catch-all, my worker thread would not get terminated, but a worker thread does not know if the task is a well planned task. It should prepare for failures in the called code.

Now if I uncomment the UnCaughtExceptionHandler parts, I get the following output.

Thread-0
Thread-0 is running task number 0
Uncaught Exception received. Recieved error on Thread-0 thread. Some stupid RE
Thread-1
Thread-1 is running task number 1
After catch in the task 1
Thread-1is done executing task 1
Thread-1
Thread-1 is running task number 2
After catch in the task 2
Thread-1is done executing task 2
Thread-1
Thread-1 is running task number 3
After catch in the task 3
Thread-1is done executing task 3
Thread-1
Thread-1 is running task number 4
After catch in the task 4
Thread-1is done executing task 4
Thread-1
Thread-1 is running task number 5
Uncaught Exception received. Recieved error on Thread-1 thread. Some stupid RE
Thread-2
Thread-2 is running task number 6
After catch in the task 6
Thread-2is done executing task 6
Thread-2
Thread-2 is running task number 7
After catch in the task 7
Thread-2is done executing task 7
Thread-2
Thread-2 is running task number 8
After catch in the task 8
Thread-2is done executing task 8
Thread-2
Thread-2 is running task number 9
After catch in the task 9
Thread-2is done executing task 9
After all tasks have started

In your first case, you are just logging the exception as a part of the Uncaught exception handler. This will not prevent the thread that is calling the startServer method from terminating.

Obviously you need to analyze why you are getting the StringIndexOutOfBoundException. That is the real problem you need to solve. But to think that an uncaught exception handler that just logs an exception can catch an exception just like a catch block does would be wrong in my opinion.

To answer the question, which of the two things are better, I think that an uncaught exception handler and a catch-all block in the task class are not mutually exclusive. Worker threads execute tasks generally through an abstraction and since tasks are unknown kind of things to worker threads, uncaught exception handlers are good regardless of whether the task has a catch-all block.

I don't know if a catch-all block in the Task class is a good idea. Obviously the catch-all block would make sure the failure condition will not cause the invoking thread to terminate, which is what well planned tasks do. But you don't require a catch-all to catch ( and handle in the correct way ) all the likely failure conditions. Also catch-all's are risky. I mean you never know for how long you are still using the corrupted data till you see a failure later. But that's just one of the things ( significant things ) and it really depends on your implementation and the possibilities with your use case.

[quote]I think it is worth mentioning Martin Odersky scala course at https://www.coursera.org/course/progfun[/quote]

I've heard good reviews of the course. I had enrolled into the course a month back.

They've released the first set of lectures. I might have some time next month, so I'm hoping I'll be able to keep up with the course. I have done the mistake of enrolling into two coursera courses at the same time in the past. Since I'm not going to be repeating that mistake this time, I might as well be able to keep up with the course. :-)

You have 40 audit tables. Purging audit data may take a considerable amount of time. So you might want to have more than a single job that can run in parallel.

Is 15th of every month also the time when the database is not going to be very busy? That might also be a thing to consider.

Yes Jesper, I get what you are saying. His compareTo method isn't consistent with his equals and hashCode methods, which, like you said is the root cause of the problem. :-)

The OP needs to fix that.

Does a TreeSet even use the hashCode and equals methods? I remember my TreeSet implementations would work without them.

I thought a TreeSet only used compareTo/compare method to place objects into the Set.

Edit : But I understand that the contract of compareTo must be kept.

Heena Agarwal wrote:
We all know what the output would be.

Actually, no. We all know what the output could be should be the right thing to say.

Ok, let us create a bad class that doesn't keep the equals and hashCode contract.

class MyBadClass { private int i; MyBadClass(int i) { this.i = i; } public int getI() { return i; } public void setI(int i) { this.i = i; } @Override public int hashCode() { final int prime = 31; int result = 1; result = prime * result + i; return result; } @Override public boolean equals(Object obj) { if (this == obj) return true; if (obj == null) return false; if (getClass() != obj.getClass()) return false; MyBadClass other = (MyBadClass) obj; if (i != other.i) return false; return true; } }

Now let us test this MyBadclass...

public class TestClass { public static void main( String [] args) { MyBadClass obj = new MyBadClass(10); Set<MyBadClass> set = new HashSet<MyBadClass>(); System.out.println(set.add(obj)); obj.setI(20); System.out.println(set.add(obj)); System.out.println(set.size()); } }

We all know what the output would be.

Obviously an object has one hashCode. So we can't test why different hashCodes may not imply different objects by just invoking the hashCode method. Let us not know in advance that we have one object only. Let us put this object in a collection and then use hashCode to see if the hashCode alone can tell us if two objects are different.

I am very sensitive to sounds of any kind while I'm working on something that requires concentration. I'm too easily disturbed.

At my first job, we had a gang of co-workers from another team who loved to come for breaks towards our side of cubicles and they loved to talk about movies/fashion/politics/sports and what not too loudly. We had a very grand cafeteria in the 11th floor but they wouldn't go there. Also we had kind of a decently nice walking space in the campus but they wouldn't go there also. They just loved to disturb us. Once we put up a note on the adjacent wall that said - 'people are working in the adjacent, so please keep the volume down'. But that didn't help much. I used to frequently go to an unoccupied conference room and work from there. Thank God, we had those conference rooms.

And I've realized that I end up editing my posts that say things about my current workplace.

Thanks, Winston. Those are really nice examples. Arrays.asList() was an interesting example of an adapter. I did understand the adapting part of an adapter, it's the enhancing the interface part that I was a little confused about.

I thought that the adapter was supposed to enhance the target interface in a way that those enhancements would be independent functions. So I thought that I was supposed to add a new method to say my EnumerationIterator. Granted I can add that method, but I have really not enhanced the Iterator interface this way cause I can't invoke it if all I know is that EnumeratorIterator is an Iterator.

What I mean is I can't do this for example--
public static void main(String[] args) { Vector<String> vector = new Vector<>(); vector.add("one"); vector.add("two"); Iterator<String> myIt = new EnumerationIterator<> (vector.elements()); while(myIt.hasNext()) { System.out.println(myIt.next()); } myIt.myNewMethod(); // I can't invoke a new method like this cause myIt is an Iterator.

But I can have myIt invoke a method that is declared in the Iterator interface, say the remove method and have my implemented version of remove() method invoke myNewMethod().

I know that an adapter adapts an adaptee to a target interface but I am not really sure how an adapter can enhance a target interface. Perhaps by new features the authors meant the same things as having a new implementation of methods declared by the interface and these new implementations can invoke new features. But I'm not too sure about this.

I understand how a decorator adds additional behavior.