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.
Wednesday, March 5, 2014
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.
Friday, February 28, 2014
We often hear advice that catching Throwable or Error is bad practice and Java developer should avoid catching these, but have you thought Why? If language allows you to catch anything which is instance of java.lang.Throwable, then what is the problem of catching them or their subclass java.lang.Error? If they are bad, shouldn't Java itself has prohibited them from catching? Well this all looks good on theory, but not in real world programming. As I said before in Java Exception best practices post, Ideally you should never catch Throwable or in particular Error. There are several reasons why catching instance of java.lang.Throwable is bad idea, because in order to catch them you have to declare at your method signature e.g. public void doSomething() throws Throwable. When you do this, no body knows what kind of Error this method is going to throw, and until you know what is the problem, how can you resolve that. Main purpose of providing Exception handling mechanism is to handle error situation properly, but you can't a provide a solution which can solve all problems. That's why we have specific Exception classes e.g. FileNotFoundException, IllegalArgumentException, IOException and so on. So if you don't know how to resolve or handle error, there is no point catching Throwable, all it make your code hard to read and comprehend. Remember, each error handling code is driven by business/audit/reporting or quality requirement and catching Throwable just obscure those logics.