Dipta P Banerjee

You can find a list here. But the most popular and well used is Hibernate. You can use it directly or using Spring Data JPA

There are lots of books for the same and I am not sure which one is/are the best. This is not the direct answers of your question but I will prefer to go through the online free courses by Coursera. I have personally taken those courses and they are great.

I guess you referring to Apache HTTPClient. In apache HTTP client you can create multipart entity body using the MultipartRequestEntity class. Please refer to JavaDoc, it also contains a sample usage

I never tried to install it silently, but you can give it a try with the /s option with the installer. Please refer to http://www.oracle.com/technetwork/java/javase/silent-136552.html for the details

Not sure about the exact reason for not installing JRE to your target machines since installing JRE in a machine is quite common and user will accept that without any concerns if he has trust on your application. Most (or all) the applications written in Java expects that the target machine should have JRE.

In extreme case if you want to run the application in a machine which does not have JRE installed, I guess you have to use script based installer, which will first check the existence JRE, if not present then install the same and then will configure your package (if require).

There are some installers available (example IzPack) but I guess those installer will itself required JRE to be installed. You can look for any script based installer or write your own

Richard Reese wrote:Dipta,

I don’t address this topic in the book but the following article may help: http://www.drdobbs.com/jvm/tail-call-optimization-and-java/240167044

Thanks Richard, specially pointing to the article.

You are adding the values before converting it to LIFO. Add it after converted it to Lifo to the d1 reference. For example:

Deque<String> d= new ArrayDeque<String>(); Queue<String> d1=Collections.asLifoQueue(d); d1.add("X");d1.add("Y");d1.add("Z"); System.out.println(d1.peek()); String s=d1.remove(); //It will remove Z System.out.println(s);

I am not aware of the OCEWSD question formats,

But if you consider to gain knowledge about REST implementation my suggestion is not to go with the detailed underlying implementation with few exceptions, such as how the underlying platform is handling the XML/JSON mapping to Objects. For example Jersey uses Jackson library to for object marshalling and unmarshalling in case the HTTP payload is of type JSON. You should be aware of this as in some cases this information is useful to design the bean classes.

Though it is completely my personal opinion, but going through the details of the REST standard will be more helpful than going through the details if the underlying implementation of the existing framework as you are not supposed to re-invent the wheel; only if you have plan to develop a new more efficient REST APIs than the existing one.

Some of the compilers were able to optimise the tail recursion calls, for example Scala does. But till Java 7 tail recursion calls are not optimised by the Java compiler. Will Java 8 compiler is going to generate optimised byte codes for tail recursion?

I did some R&D on Scala and Java 7 compiler and posted my thoughts at Tech.pro

ragi singh wrote:Does that mean , when a class is instantiated the methods are instantiated too ? This is a new concept to me

No, you have to implement a derived class from that abstract class, implement the abstract method on that derived class and then instantiate your derived class (not the super abstract class)

One of the basic reasons may be as follows:

Abstract class has some un-implemented (abstract) methods which is required to be implemented in the derived class. So if we instantiate an abstract class without implementing the abstract method then it will cause run time errors. So we can not (JDK restricts us) instantiate an abstract class directly without instantiating the abstract method.

Though it may possible that abstract class may not have any un-implemented (abstract) method, in that case the reason of making the class abstract may be to restrict the developer from instantiating the class based on the design decision of the application