Programmer often mistook copy constructors provided by various collection classes, as a mean to clone Collection e.g. List, Set, ArrayList, HashSet or any other implementation. What is worth remembering is that, copy constructor of Collection in Java only provides shallow copy and not deep copy, which means objects stored in both original List and cloned List will be same and point to same memory location in Java heap. One thing, which adds into this misconception is shallow copy of Collections with Immutable Objects. Since Immutable can't be changed, It's Ok even if two collections are pointing to same object. This is exactly the case of String contained in pool, update on one will not affect other. Problem arise, when we use Copy constructor of ArrayList to create a clone of List of Employees, where Employee is not Immutable. In this case, if original collection modifies an employee, that change will also reflect into cloned collection. Similarly if an employee is modified in cloned collection, it will also appeared as modified in original collection. This is not desirable, in almost all cases, clone should be independent of original object. Solution to avoid this problem is deep cloning of collection, which means recursively cloning object, until you reached to primitive or Immutable. In this article, we will take a look at one approach of deep copying Collection classes e.g. ArrayList or HashSet in Java. By the way, If you know difference between shallow copy and deep copy, it would be very easy to understand how deep cloning of collection works.
Tuesday, March 11, 2014
Wednesday, March 5, 2014
MQ Series Interview Questions and Answers are collection of some of the questions asked on various MQ implementation e.g. IBM WebSphere MQ, Active MQ or Sonic MQ from different core Java and Enterprise Java (JEE) interviews. Most of these questions are from websphere MQ as it's the one which is most popular in large organization, especially in finance domain. By the way messaging is a key aspect of any enterprise application and you will always see some form of messaging between different systems in a organization. For example, In finance world, most of the middle office to back office communication happens over messaging middle-ware like TIBCO or MQ Series. Its one of the popular Message Oriented Middleware used in Core Java and Enterprise Java application deployed on IBM WebSphere Server, which means if your organization is using IBM WebSphere as application server, you are likely see WebSphere MQ there. By the way that's not the only one messaging solution available, you have couple of choices depending upon requirement e.g. Tibco Rendezvous for high speed messaging, Tibco EMS for a JMS based messaging, mostly for durable messages and MQ series as well. It's long time I have written any article on messaging after my articles based on Tibco messaging, along with some Tibco Interview Questions e.g. difference between Tibco RV and Tibco EMS. In this messaging article, focus will on MQ Series and in particular WebSphere MQ. These 10 WebSphere MQ interview Question and Answers will certainly help you to prepare better for any Java interview which expect experience on MQ Series.
Monday, March 3, 2014
Sometime knowledge of a specific Java feature can improve code quality, Covariant method overriding is one of such feature. Covariant method overriding was introduced in Java 5, but it seems it lost between other more powerful features of that release. Surprisingly not many Java programmer knows about Covariant overriding, including myself, until I read, one of the best Java book on Collection framework, Java Generics and Collection. Covariant method overriding helps to remove type casting on client side, by allowing you to return subtype of actually return type of overridden method. Covariant overriding can be really useful, while overriding methods which returns object e.g. clone() method. Since clone() return object every client needs to cast on to appropriate subclass, not any more. By using Java 5 covariant overriding, we can directly return subtype instead of object, as we will seen in examples of this article. This feature is not a star feature like Generics or Enum, but it's definitely something worth knowing, given overriding methods are integral part of Java programming. I have discussed a bit about this feature earlier in difference between overriding and overloading article, and here I will show couple of more examples to justify it's usage.