Sujeet Kumar Jaiswal

Thanks Mark

Hi,
I am looking at feasibility of using Spring 3.1.0 validation framework to implement validation to all the API's that I have developed. In the service implementation layer, I need to add the validation to each of the service/functions in order to check if the passed params are valid and have correct values. What I found from initial investigation is that Spring's Validator Interface has to be implemented for each POJO's that I have.

- But it may happen that for the given service, as in my case, that during validation one POJO's property value's validity may depend on another passed POJO's property value. So basically, service's POJO param's are valid or not, It can be interdependent.
- Also, one POJO may have different validation logic in different services. May be I can allow one of it's property to be null in one case and not null in another cased for different services.

Is there any way to use Spring Validation framework in this case. If yes, how? If not, Please share if you have any other framework idea which will fit in my case.

Thanks Rob.

When we say that for an Interface the implementing class should follow the contract, how do the interface designer ensures that the implementation class necessarily follows the contract? For e.g. I can implement the java.util.Set interface wrongly by defining the add method to allow duplicates in my implementation class. So looks like the contract is just the specification which is supposed to be followed by the implementor which he may mistakenly/intentionally breach.
Please share your views over this.....

Actually, by default a decimal number is double in java. Hence, 9*3.2 & 5.2-2 will result in a double number which cannot be directly casted to float. Try

float twoD[][] = { {9*3.2f , 5.2f-2 , 7*5},{9*6 , 6-2 , 8*5},{32*6 , 0-2 , 8*5}};

This will work as suffixing 'f' with a decimal number makes it float.

Hence,

float f = 3.2 (compiler error)
float f = 3.2f (compiler happy)

Got it Jim... Just one more small query, its JVM who will grant the lock or the thread scheduler.

HI,
When thread1 tries to access a synchronized method which has been locked by another thread2, then thread1 goes to blocked state from running state. I want to understand in detail how does thread2 goes from blocked to runnable state?

Does this transition happen ONLY once thread2 releases the lock? If yes, then how thread1 comes to know that thread2 has released the lock (Consider this just a simple scenario where we don't have wait & notify mechanism)?

NULL is a special literal of the null type.

1- It can be cast to any reference type, but not to any primitive type such as int or boolean.
2- It is impossible to cast to the null type or declare a variable of this type.

mohitkumar gupta wrote:how can a class change parameter type of a method of interface or this is function overriding[/b]

Well here its case of function overloading in Phone2 and since Electronic has already implemented the method of interface, Phone2 will compile. The fact is that all the interface methods must be implemented by the current class or any of class above in inheritance tree (super) which implements the interface. Once that is done, interface is happy and the class overloading methods has nothing to do with the interface happiness.

Thread running method1 has class lock and Thread running method2 has object lock. They can run concurrently. They will not impact each other's execution.

sksumit kumar wrote:

sksumit kumar wrote:I said since interface is not a part of the inheritance tree structure, the object created would be less bulky.

Actually, when the class implementing the interface is polymorphically assigned to the interface type variable, only interface portion of object is copied to the variable (phenomena called object slicing). Since interface normally has less variables (only constants) as compared to base class, I think it will be light weight.

Comments are invited over this answer.

Rajesh Nagaraju wrote:

Also what happens if method2 is static, how does this affect the access to method1.

When the method2 is static then thread1 will get the class lock but still it will bring no impact on thread2's access to method1.

One major difference is that:

With synchronized methods, the thread will have the lock of 'this' object only. But by using synchronized block we can pass any object as the parameter and lock of that particular object will be given to thread.

Locking means prohibiting multiple threads to execute a synchronized method or a synchronized block at same time. This happens by lending the object lock to the currently running thread. But still that object can be used to invoked any method by different threads.

Locking doesn’t mean that the object cannot be used to invoke a method. As Christophe also said "Non-synchronized methods do not check the lock status"

The object can be used to invoke methods by different threads:

1- If the method called is non-syncronized, it will run.
2- If the method called is synchronized and already a thread is running it, then the calling thread will wait to acquire the object lock.

public void useSyncBlock{

int i=10; --- 1
synchonized(this) --- 2
{

doCritcalOpreation(); ---3

}

system.out.ptintln("out ") --- 4

}


Code outside the synchronized block: label 1 & 4.

When one of the thread is already inside the synchronized block ' label 3' (has acquired the lock of this object), then all other threads will be able to run till 'label 1' and get blocked for the object lock once they reach 'label 2' (Running State -> Blocked State) and hecne they won't be able to run 'label 4'.