My Journey as a Developer

Java 9 - Try with Resource enhancements

2017-11-18T13:30:00.000-08:00

Try With Resource

Introduced with Java 7, a try-with-resource provided a cleaner way to perform cleanup operations on resources. This was a very useful feature where you need not explicitly do a cleanup of resources (which implements an AutoClosable interface) but it was done automatically for us. This is critical in applications where we are dealing with resources such as Database, I/O Streams where not cleaning up the resources will be costly.

One limitation of pre-Java 9 try-with-resource was that it can perform cleanup operations only if the Resource was instantiated inside the try block.

For example (pseudo code):

// This will cleanup Resource

try(Resource myResource = new Resource()) {

     resource.doSomething();

}

// The below will not work in pre-Java 9 but works in Java 9

Resource resource = new Resource();

try(resource) {

     resource.doSomething();

}

Will the above feature be useful or complicate things depends on how this is used. Since the resource can be created elsewhere and passed on to this method or given via Dependency Injection, closing this can create more problems (as it lives outside the try block). So, this feature has to be used with Care.

Have a look at another interesting feature of Java 9 - Private methods in interfaces.

Java 9 - Private methods in Interface

2017-11-18T12:58:00.001-08:00

Prior to Java 8, Java Interfaces can contain method signatures but without any implementation.

In Java 8, default methods were introduced where we can add new methods and a default implementation for the same. Though it was originally intended to allow people to add new interface methods without requiring all implementations to change (by providing a default implementation), we are using default methods in many different ways which may or may not be how it was originally intended to be used. If you have multiple default method implementations in an interface, we may end up having duplicate code due to lack of private methods.

Some options available to do this

Another default method with common logic.
An external class containing Utility methods.

Both cases expose the implementation details to outside classes which otherwise supposed to be a private to default methods.

In Java 9, we can now create private methods in an interface which are to be used by default methods.

So, if we have default methods in an interface and need to share a particular logic, a private interface method would allow us to do so without exposing that private method and all its implementation details via the interface (or a Utility class).

Have a look at an interesting enhancement in Java 9 - Try-with-resource enahancement

Journey from CORBA to GraphQL

2017-11-09T11:17:00.002-08:00

During my initial days as Software Engineer, my first exposure to client-server application was with a Java based server and a DotNet based client which used CORBA for remote communication.

RMI which is kind of predecessor of CORBA provided Java Only interfaces where as our application needed DotNet (and Java too) which CORBA provided (had implantation in multiple languages).

Problem statement : We wanted a client server application where client can be either in Java or DotNet and server being Java.

CORBA which could solve the above problem was used and it served well during its initial days.

CORBA had some benefits (multi language support) but it lacked in few areas such as performance, clear specification and lack of complete symmetry in some field mapping. This RMI vs CORBA article provides good information and comparison on this topic.

When looking for options to replace CORBA, two options looked really attractive - REST service with JSON or API’s provided using ProtoBuf (from Google). Both were relatively new during that period and was gaining traction for their own reasons. Though we could not do much using Protocol Buffers, it is still quite popular with implementations where performance is of higher prominence. This blog has nice information on ProtoBuf.

One more area I had a brief exposure to was SOAP based services. Schema, WSDL, tools to generate clients, contract between server and client applications - it has all good things that are needed for a client-server application. But dealing with XML based data and strong contract between client and server were some factors which made SOAP less attractive. SOAP and REST is discussed in this blog.

RESTful it was then, a very simple, HTTP based, JSON for data transfer over network and a stateless system. Looked very interesting to build our system which both java and DotNet clients can use. Converting all our entities into resources and having relationships as links providing a smooth navigation looked easily achievable. From then, I started working with different systems (due change in companies and products I worked on) where REST based services were used in different forms - some tried to be purest form, some with diverting from REST principles to have some functionalities stuffed in. Nevertheless usage of REST grew very fast and with evolution of SOA and micro services, fueled its growth further. I have used and still using REST in the services being developed where it is serving its purpose quite well.

Then came OData.

REST was good, but we wanted something more. A query type API's which gives client flexibility to add various querying capability into their service calls. Though OData does not completely adhere to original REST principles, it tried to balance contract between client-server (by providing $metadata) and fluent API's as in REST (Entity Models). OData was originally developed by Microsoft (2007) and many big players started contributing to specifications and standards. When I started working with SDL, a Java implementation of OData framework was developed for the use of our services implementation which was later open sourced.

All was well with REST & OData except that we started having a new problem.

Problem statement: REST or OData based services makes complex client application to become chatty and also results in underfetching or over fetching of data. We want some genric way of providing API which can reduce number of calls to service and clients can ask for what they want.

Then came GraphQL.

GraphQL was developed by Facebook for internal usage and later made publicly available (2015). On very first instance, it addressed two important problems we were facing - reduce chattiness and prevent under-fetching or over-fetching of data (get only what you need). GraphQL (often confused with Graph Databases but has nothing to do with it) is a query language for API's and also provides resolving layer or ways to provide data for the query.

REST or OData provided few of the features of GraphQL already, but GraphQL provides more elegant way of doing this. GraphQL mostly moves towards developing API's giving importance to what client need without the need for having a contract. During our initial evaluation of GraphQL, we identified potential benefits it can provide our clients. Moreover the rapid growth on the community around GraphQL makes is really interesting.

GraphQL fits well in todays application development requirement of ability to provide API's regardless of the client being used - Browser, Mobile, Tablet, etc. As an API provider, we need not worry about the type of client calling our API, but just expose types (schema) which our API will provide. Its the client implementation which queries the server to provide the data which is required and the GraphQL service provides only the data being requested. There are many articles around getting started with GraphQL and for Java, we have How to GraphQL which is great place to start with.

Overall it was an interesting journey from CORBA to GraphQL, the later being the one which looks like has a long way to go.

LinkedList<> over ArrayList<>?

2014-07-16T07:12:00.001-07:00

LinkedList and ArrayList are two different implementations of the List interface of Java Collections Framework. LinkedList is implemented based on doubly-linked list where as ArrayList implements it with a dynamically resizing array.

These implementations differ in algorithmic runtime as shown below

For ArrayList

Accessing Data : get(int index) - Constant time O(1) - Reading is faster which is main advantage of using ArrayList
Adding new elements :
- End of list - add(E element) - If it fits into existing size of the list O(1). If the array is full and needs resize O(n) which is worst case
- Add at a particular index (in between) - add(int index, E element) - This requires re indexing of all the elements after insertion position and hence in general O(n-index) and worst case will be O(n)
- ListIterator.add(Element e) - Since we will adding at a position, it is same as adding an element at a index
Remove an element:
- remove(int index) - As with adding elements at a particular index, removing (if not last element) requires re indexing all the elements after the element which is removed. So, in general it is O(n-index) and worst case is O(n).
- remove(Element e) - It is same as removing at an index.
- Iterator.remove() - Same as removing at an index.

For LinkedList

Accessing Data : get(int index) - O(n) - Reading is slower compared to ArrayList since we need to sequentially move towards the specified index to get the data.
Adding new elements :
- add(E element) - constant time O(1) only if you happen to have a pointer to the location where you are inserting (index). Else O(n-index)
- add(int index, E element) - O(n-index) and worst case is O(n)
- ListIterator.add(E element) is O(1) - mainly because you are already at the index of the element after which element will be added. This is the main advantage of Linked Liked over ArrayList.
Remove an element:
- remove(int index) - O(n) as we need to traverse to index and remove it. But we need not re index since only the pointers will be adjusted.
- Iterator.remove() - O(1) same as ListIterator.add(E element). Again this is one of the main advantage over ArrayList.

As a conclusion,

LinkedList allows for constant-time insertions or removals using iterators, but only sequential access of elements. In other words, you can walk the list forwards or backwards, but finding a position in the list takes time proportional to the size of the list.

ArrayList, on the other hand, allow fast random read access, so you can grab any element in constant time. But adding or removing from anywhere but the end requires shifting all the latter elements over, either to make an opening or fill the gap. Also, if you add more elements than the capacity of the underlying array, a new array (1.5 times the size) is allocated, and the old array is copied to the new one, so adding to an ArrayList is O(n) in the worst case but constant on average.

And one more important point to note here that memory requirements for LinkedList is more than ArrayList since it has to store the information about next and previous pointers. So, when we are looking at memory angle, we need to take this into consideration.

Choice of Data structure depends on specific use case and how we need to handle the add/remove and read operations on the data structure. During design, need to list all the possible uses of the data structure and finalize on optimized data structure to be used.

Is Java “pass-by-reference” or “pass-by-value”?

2014-07-12T21:02:00.000-07:00

Java is always pass-by-value. !!!!

However there is a difficulty in understanding this or more over a confusion when we are dealing with method calls involving Java Objects.

Java Specification says that everything in Java is pass-by-value and there is nothing called "pass-by-reference" in Java. To understand more about this, we can start with Java Object and reference understanding. Say we have a class called Employee

public class Employee

{

private int id;

private int age;

private String name;

// Getters-Setters ...

}

Now we will create an object instance of Employee as below

Employee myEmp = new Employee();

Here myEmp is not "Employee" but a handle to point to an instance of "Employee" object somewhere sitting in memory.

We have a method call handleEmployee as below which needs Employee object

public void handleEmployee(Employee emp)

{

// Do Something with employee

}

When we call the above method as below

Employee myEmp = new Employee();

handleEmployee(myEmp);

What essentially happens here is that, we are passing a copy of the handle (myEmp) which was used to access Employee object to the calling method.

Why java pass-by-value ?

Because, we as passing a copy of a reference variable - myEmp, to handleEmployee method ( as emp).

This gives the method handle to get to Employee object but it cannot change myEmp reference itself.

public void handleEmployee(Employee emp)

{

// Do Something with employee

emp = null;

}

When we make emp = null, then it just nullifies the copy so that it will no longer refer Employee object. But the original myEmp is still unaffected.

So, as a conclusion, Java is always "pass by value" whether we are passing primitives ( int, char, long, etc) or an object.

Unit Testing - Test Private methods using JUnit

2014-07-12T07:11:00.004-07:00

Unit testing is a very critical and crucial part of any development activity. Simple but sound unit test cases can save many hours of debugging time for a developer which indeed improves the code quality. For a Java developer, Junit is one of the old and preferred way of fortifying his code.

During unit testing, we often need to test a class completely which includes testing individual private methods for proper bug free execution which covers all corner case. Below is description on how we can test a private method using JUnit.


Class targetClass = MyClassWithPrivateMethod.class;
Object[] myMethodArgsClasses = new Object[]
              {MethodArgType1.class,MethodArgType2.class,...}
Method method = targetClass.getDeclaredMethod(methodName,
                 myMethodArgsClasses);
method.setAccessible(true);
method.invoke(targetObject, argObjects);
// More testing goes here

Static class in Java

2013-12-16T02:46:00.001-08:00

June 16, 2013

Can a class be static in Java ?
The answer is YES, we can have static class in java. In java, we have static instance variables as well as static methods and also static block. Classes can also be made static in Java.
Java allows us to define a class within another class. Such a class is called a nested class. The class which enclosed nested class is known as Outer class. In java, we can’t make Top level class static.Only nested classes can be static.
What are the differences between static and non-static nested classes?
Following are major differences between static nested class and non-static nested class. Non-static nested class is also called Inner Class.
1) Nested static class doesn’t need reference of Outer class, but Non-static nested class or Inner class requires Outer class reference.
2) Inner class(or non-static nested class) can access both static and non-static members of Outer class. A static class cannot access non-static members of the Outer class. It can access only static members of Outer class.
3) An instance of Inner class cannot be created without an instance of outer class and an Inner class can reference data and methods defined in Outer class in which it nests, so we don’t need to pass reference of an object to the constructor of the Inner class. For this reason Inner classes can make program simple and concise.

/* Java program to demonstrate how to implement static and non-static

   classes in a java program. */

class OuterClass{

   private static String msg = "GeeksForGeeks";

   // Static nested class

   public static class NestedStaticClass{

       // Only static members of Outer class is directly accessible in nested

       // static class

       public void printMessage() {

         // Try making 'message' a non-static variable, there will be

         // compiler error 

         System.out.println("Message from nested static class: " + msg);

}

}

    // non-static nested class - also called Inner class

    public class InnerClass{

       // Both static and non-static members of Outer class are accessible in

       // this Inner class

       public void display(){

          System.out.println("Message from non-static nested class: "+ msg);

}

}

}

class Main

{

    // How to create instance of static and non static nested class?

    public static void main(String args[]){

       // create instance of nested Static class

       OuterClass.NestedStaticClass printer = new OuterClass.NestedStaticClass();

       // call non static method of nested static class

       printer.printMessage();  

       // In order to create instance of Inner class we need an Outer class

       // instance. Let us create Outer class instance for creating

       // non-static nested class

       OuterClass outer = new OuterClass();       

       OuterClass.InnerClass inner  = outer.new InnerClass();

       // calling non-static method of Inner class

       inner.display();

       // we can also combine above steps in one step to create instance of

       // Inner class

       OuterClass.InnerClass innerObject = new OuterClass().new InnerClass();

       // similarly we can now call Inner class method

       innerObject.display();

}

}

Output:

Message from nested static class: GeeksForGeeks
Message from non-static nested class: GeeksForGeeks
Message from non-static nested class: GeeksForGeeks

Can we Overload or Override static methods in java ?

2013-12-16T02:45:00.001-08:00

Can we Overload or Override static methods in java ?

Can we overload static methods?
The answer is ‘Yes’. We can have two ore more static methods with same name, but differences in input parameters. For example, consider the following Java program

Can we overload methods that differ only by static keyword?
We cannot overload two methods in Java if they differ only by static keyword (number of parameters and types of parameters is same). See following Java program for example. This behaviour is same in C++ (See point 2 of this).

// filename Test.java

public class Test {

    public static void foo() {

        System.out.println("Test.foo() called ");

}

    public void foo() { // Compiler Error: cannot redefine foo()

        System.out.println("Test.foo(int) called ");

}

    public static void main(String args[]) {

        Test.foo();

}

}

Output: Compiler Error, cannot redefine foo()

Can we Override static methods in java?
We can declare static methods with same signature in subclass, but it is not considered overriding as there won’t be any run-time polymorphism. Hence the answer is ‘No’.
If a derived class defines a static method with same signature as a static method in base class, the method in the derived class hides the method in the base class.

/* Java program to show that if static method is redefined by

   a derived class, then it is not overriding. */

// Superclass

class Base {

    // Static method in base class which will be hidden in subclass

    public static void display() {

        System.out.println("Static or class method from Base");

}

     // Non-static method which will be overridden in derived class

     public void print()  {

         System.out.println("Non-static or Instance method from Base");

}

}

// Subclass

class Derived extends Base {

    // This method hides display() in Base

    public static void display() {

         System.out.println("Static or class method from Derived");

}

    // This method overrides print() in Base

    public void print() {

         System.out.println("Non-static or Instance method from Derived");

}

}

// Driver class

public class Test {

    public static void main(String args[ ])  {

       Base obj1 = new Derived();

       // As per overriding rules this should call to class Derive's static

       // overridden method. Since static method can not be overridden, it

       // calls Base's display()

       obj1.display(); 

       // Here overriding works and Derive's print() is called

       obj1.print();    

}

}

Output:

Static or class method from Base
Non-static or Instance method from Derived

Following are some important points for method overriding and static methods in Java.
1) For class (or static) methods, the method according to the type of reference is called, not according to the abject being referred, which means method call is decided at compile time.

2) For instance (or non-static) methods, the method is called according to the type of object being referred, not according to the type of reference, which means method calls is decided at run time.

3) An instance method cannot override a static method, and a static method cannot hide an instance method. For example, the following program has two compiler errors.

/* Java program to show that if static methods are redefined by

   a derived class, then it is not overriding but hidding. */

// Superclass

class Base {

    // Static method in base class which will be hidden in subclass

    public static void display() {

        System.out.println("Static or class method from Base");

}

     // Non-static method which will be overridden in derived class

     public void print()  {

         System.out.println("Non-static or Instance method from Base");

}

}

// Subclass

class Derived extends Base {

    // Static is removed here (Causes Compiler Error)

    public void display() {

        System.out.println("Non-static method from Derived");

}

    // Static is added here (Causes Compiler Error)

    public static void print() {

        System.out.println("Static method from Derived");

}

}

4) In a subclass (or Derived Class), we can overload the methods inherited from the superclass. Such overloaded methods neither hide nor override the superclass methods — they are new methods, unique to the subclass.

Java Immutable Objects

2013-02-20T05:28:00.001-08:00

What are immutable objects? What are their Advantages? Design a immutable object with Date object as a member attribute.

An object is considered immutable if its state cannot change after it is constructed.

Advantages :
1. Simple and Reliable Code.
2. Useful in concurrent Applications since they cannot change state, they cannot be corrupted by thread interference or present in inconsistent state.
3. Decreased overhead in Garbage Collection.
4. Reduction in code needed to protect objects in concurrent applications.

JDK Examples : String, Integer

public class Mydate {
private final Date date; // Declare the variable as final

public Mydate(Date date) {
this.date = new Date(date.getTime());
}
public getDate() {
return new Date(date.getTime()); // Need to return a copy instead of original object
}

// Note: No Setter method for date
}

Serialisation - readObject and writeObject

2012-09-29T10:39:00.000-07:00

what is the significance of readObject and writeObject method in Serialization ?

These methods are not declared in any class or interface. A class, that implements the Serializableinterface and requires special special handling during the serialization and deserialization process must implement those methods and the serializer/deserializer will try to reflect those methods.

These methods are (and must be) declared private (when implementing your own), proving/indicating that neither method is inherited and overridden or overloaded by the implementation. The trick here is that the JVM automatically checks to see if either method is declared during the corresponding method call. Note that the JVM can call private methods of your class whenever it wants but no other objects can. Thus, the integrity of the class is maintained and the serialization protocol can continue to work as normal.

Arrays.asList()

2012-09-17T00:10:00.001-07:00

Arrays.asList() is efficient because it doesn't need to copy the content of the array. This method returns a List that is a "view" onto the array - a wrapper that makes the array look like a list. When you change an element in the list, the element in the original array is also changed. Note that the list is fixed size - if you try to add elements to the list, you'll get an exception. If you only need read access to the array as if it is a List and you don't want to add or remove elements from the list, then use Arrays.asList().

new ArrayList(Arrays.asList(myArray)) copies the content of the array to a new ArrayList. The copy is ofcourse independent of the array, and you can add, remove etc. elements as you like.

Collections.addAll(myList, myStringArray) is essentially the same as new ArrayList(Arrays.asList(myArray)) .

CORBA Questions

2011-07-02T02:40:00.000-07:00

What is the basic CORBA Architecture?

The CORBA architecture is designed to support the distribution of objects implemented in a variety of programming languages. This is achieved by defining an interface definition language that can be mapped to a number of existing languages. IDL is used to define the services offered by a particular distributed object. CORBA defines a wire protocol for making requests to an object and for the object to respond to the application making the request. The IIOP protocol ensures interoperability between client applications and server based objects. CORBA then extends on this basic set of functionality by defining a set of low level services. These services are required by applications regardless of the exact nature of the applications. These services are defined in CORBA IDL. CORBA vendors preprocess the service IDL and then implement the service with varying degrees of robustness.

Can CORBA application be multi-threaded?

The CORBA specification does not currently address multi-threaded architectures. Provided that the CORBA product is thread safe, threaded CORBA applications can be developed. CORBA clients and servers can both be multi-threaded. Daemon processes provided with CORBA products may be implemented as multi-threaded servers by the CORBA vendor. Different multi-threaded models or multi-threaded architectures may be supported by a particular CORBA product. A particular ORB may provide frameworks to simplify the development of multi-threaded CORBA applications.

Do different CORBA implementations perform at significantly different levels?

Different CORBA implementations can vary significantly in performance. Good implementations should be fairly similar since network performance defines the maximum achievable performance characteristics. Network latency does represent the significant portion of distributed invocation latency.

Does CORBA supports asynchronous communication?

Kind of. At the lowest level CORBA supports two modes of communication: A synchronous request/response which allows an application to make a request to some CORBA object and then wait for a response. A deferred synchronous request/response which allows an application to make a request to some CORBA object. An empty result will be returned immediately to the application. It can then perform other operations and later poll the ORB to see if the result has been made available. At the lowest level, the CORBA deferred synchronous communication does allow a certain degree of asynchronous communication. Polling for responses represents only one form of asynchronous communication. Other more sophisticated asynchronous communication can only be achieved by developing architecture on top of the lowest levels of CORBA.

Are there different threading models that can be used within CORBA servers?

There are several different common architectures that can be used within multi-threaded CORBA servers. A server process needs the ability to process CORBA messages. These messages are processed by one or more threads, as determined by the application architecture. The CORBA specification does not specifically address threading capabilities within CORBA compliant ORBs. An ORB vendor is free to support only single-threaded application or to support multi-threaded applications. If the ORB does support the development of multi-threaded applications, the ORB might only support a subset of the threading models listed below. Significant threading code might still need to be developed to achieve one of the models. For example, the ORB vendor might support a set of application hooks (i.e., interceptors or filters) and allow you to implement threading code with the native OS thread API. On the other hand, the ORB product might provide a built-in feature so no custom thread development needs to be done. The CORBA specification does not address this issue. When you consider different threading models, it is important to consider what kind of concurrency is desired. While it may be advantageous that two or more threads can be concurrent, it may also be disadvantageous. Also, the resources consumed by idle or active threads, and also the resources consumed for thread creation and deletion, need to be considered.

Thread-Per-Request: With this architecture, the CORBA server ensures that each incoming message is processed in its own thread. This means that multiple requests will be processed concurrently. There are concurrency issues. If two or more requests (threads) are using the same object, then some form of concurrency control (locking) is needed. Also, if two or more requests (threads) are from the same client, then perhaps the requests should be serialized instead of allowed executing concurrently.

Thread-Per-Client: With this architecture, the CORBA server ensures that each incoming message from a distinct client is processed in its own thread. This is similar to Thread-Per-Request except multiple requests from the same client are serialized. Requests from distinct clients are concurrent. The way that one client is distinguished from another is an interesting problem. Typically, this is done by looking at the network connection and determining that the clients are the same or different. The server needs the ability to monitor client connections and the inception and termination of these connections (typically at a network level, not an application level).

Thread-Per-Server-Object: With this architecture, the CORBA server ensures that each object in the server gets its own thread of execution. This means that multiple requests will be processed concurrently provided they are using different objects. Multiple requests using the same object are serialized. There are concurrency issues, and some locking strategy is needed. Also, deadlock is very possible. It may be that threading or locking at each object is too fine a grain, and a more appropriate choice is putting the thread/lock boundary around a group of coordinating objects.

For each of the above threading architectures, the required server threads can be either created on demand or recycled through a thread pool. The advantage of creating threads on demand is that an arbitrary number of threads can be supported. A thread is created, used, and then reaped. The Thread-Per-Request model would create/reap a thread for each request; the Thread-Per-Client model would create/reap a thread for each client connection; the Thread-Per-Server-Object model would create/reap a thread for each CORBA object instantiated in the server. Thread creation and reaping has some cost, which may be large or small depending on the operating system thread support.

A thread pool is an alternative to creating threads on demand. In this approach, a fixed number of threads are created and cycled in turn to meet the demand for threads. If the demand for threads exceeds the pool size, then further requests for threads are blocked until one of the existing threads is recycled. This approach has the advantage of capping the server resources.

What is the reason to implement a CORBA application with multi-threading?

CORBA server applications may be multi-threaded for several reasons. A particular CORBA object may support an operation whose implementation performs some blocking routine. This may be a disk read or database query. Let us assume that the server application processes all CORBA events within a single main thread. This means that the server will be unable to respond to incoming connection requests or invocation requests while the blocking operation is in progress. Multi-threading can be used to avoid these sorts of situations. The server can be more accessible if multiple threads are allowed to process (an block during) incoming CORBA events.

A single multi-threaded server process supporting many (>25) clients is much more efficient that many (>25) single-threaded server processes each supporting its own client. Running a single application with multiple threads requires less machine resources than running multiple applications. This advantage can be seen even if the operation invocations are of short duration and non-blocking.

CORBA Yes. The words client and server are really only applicable in the context of a remote call. In other words, the client’s process can also receive calls on CORBA objects that it implements and hands out the references to.

What are the reasons to avoid the development of multi-threaded CORBA application?

Building multi-threaded applications requires additional efforts in the area of design, development and testing. Issues like concurrency and synchronization become more critical. Difficult to find software bugs are unfortunately easy to introduce. A specific set of application requirements can often be met without resorting to the use of threaded clients or servers. This is not true with all applications. Some do require multi-threading to achieve their desired level of concurrency, performance or scalability.

Does CORBA define high level application architectures?

No, it is infrastructure. Which is good because the history of high-level, one size fits all, architectures hasn’t been very good, has it?

CORBA provides low level request/response communication. It also provides general services that are implemented on top of request/response communication. The actual architecture used within a given application is not defined by CORBA. CORBA leaves these decisions up the application architect.

What is CORBA good for?

CORBA is useful in many situations. Because of the easy way that CORBA integrates machines from so many vendors, with sizes ranging from mainframes through minis and desktops to hand-helds and embedded systems, it is the middleware of choice for large (and even not-so-large) enterprises. One of its most important, as well most frequent, uses is in servers that must handle large number of clients, at high hit rates, with high reliability. CORBA works behind the scenes in the computer rooms of many of the world's largest websites; ones that you probably use every day. Specializations for scalability and fault-tolerance support these systems. But it's not used just for large applications; specialized versions of CORBA run real-time systems, and small embedded systems.

Does CORBA support distributed reference counting architectures?

CORBA does not directly support distributed reference counting. This was a conscious decision on the part of its designers. While CORBA does not directly support reference counting, it is possible to build reference counting into particular distributed object architecture. This can be done through an explicit session management facility which can be exposed through factories or other remote interfaces. While it is possible to design reference counting into an application, it is the burden of the application designer/developer to ensure that such an approach is implemented correctly.

Can CORBA allow servers to cause client side events or notifications?

CORBA communication is inherently asymmetric. Request messages originate from clients and responses originate from servers. The important thing to realize is that a CORBA server is a CORBA object and a CORBA client is a CORBA stub. A client application might use object references to request remote service, but the client application might also implement CORBA objects and be capable of servicing incoming requests. Along the same lines, a server process that implements CORBA objects might have several object references that it uses to make requests to other CORBA objects. Those CORBA objects might reside in client applications. By implementing a CORBA object within an client application, any process that obtains its object reference can ?notify? it by performing an operation on the client-located object.

Can CORBA application be tuned for better performance?

There are a number of ways to tune CORBA applications for better performance.

Remember that distribution should only be used if a reason to do so exists. Distribution does not make sense for the sake of distribution. If distribution does not serve a purpose then it should be avoided. Avoiding excessive distribution can result in better performance. Care should be taken when introducing distribution into an applications object model.
IDL interfaces can be tuned to minimize network latency. Invoking remote operations requires transmitting data across the network. Network performance is typically optimized by ensuring adequate bandwidth. Once the required bandwidth is achieved raw network performance cannot be increased. One key to tuning an IDL interface is to reduce the number of network transfers that need to occur. Calling an operation that returns 100 bytes might take 5 milliseconds. Calling an operation that returns 200 bytes of data might take around 6 milliseconds. Calling 2 operations that return 100 bytes might take a total of 10 milliseconds. One key to tuning IDL operations is to avoid implementing several get operations and to combine them into a single get operation which returns the appropriate combination of data.

Caching results of remote operations can avoid network overhead associated with calling the same remote methods more than once. Many applications can perform remote operations upon startup rather than during normal usage. Users are often more willing to wait at startup time rather than during application usage.

Many performance problems are associated with serialization and blocking conditions. For example, Let us assume that clients will be making remote operations to a single server. A single clients request causes the server to block for an extended period of time, the entire client community might have to wait. Make sure that multiple distributed operations are not becoming serialized within a single server process. Utilize multiple server processes or threaded servers instead.

Are there important forms of asynchronous communication that are not supported directly by CORBA?

Yeah, but you can fake it pretty easily.

While CORBA does support a deferred synchronous request/response, it does not directly support distributed requests with a callback driven response. A callback driven response allows an application to perform an operation on a distributed object, associate a callback with the response, and continue with other processing. When the server responds, the associated callback is automatically executed within the original caller’s application.

Can you give me high-level technical overview?

CORBA applications are composed of objects, individual units of running software that combine functionality and data, and that frequently (but not always) represent something in the real world. Typically, there are many instances of an object of a single type - for example, an e-commerce website would have many shopping cart object instances, all identical in functionality but differing in that each is assigned to a different customer, and contains data representing the merchandise that its particular customer has selected. For other types, there may be only one instance. When a legacy application, such as an accounting system, is wrapped in code with CORBA interfaces and opened up to clients on the network, there is usually only one instance.

For each object type, such as the shopping cart that we just mentioned, you define an interface in OMG IDL. The interface is the syntax part of the contract that the server object offers to the clients that invoke it. Any client that wants to invoke an operation on the object must use this IDL interface to specify the operation it wants to perform, and to marshal the arguments that it sends. When the invocation reaches the target object, the same interface definition is used there to un-marshal the arguments so that the object can perform the requested operation with them. The interface definition is then used to marshal the results for their trip back, and to un-marshal them when they reach their destination.

The IDL interface definition is independent of programming language, but maps to all of the popular programming languages via OMG standards: OMG has standardized mappings from IDL to C, C++, Java, COBOL, Smalltalk, Ada, Lisp, Python, and IDLscript.

For more on OMG IDL, click here.

This separation of interface from implementation, enabled by OMG IDL, is the essence of CORBA - how it enables interoperability, with all of the transparencies we've claimed. The interface to each object is defined very strictly. In contrast, the implementation of an object - its running code, and its data - is hidden from the rest of the system (that is, encapsulated) behind a boundary that the client may not cross. Clients’ access objects only through their advertised interface, invoking only those operations that that the object exposes through its IDL interface, with only those parameters (input and output) that are included in the invocation.

Request flow

Figure 1 shows how everything fits together, at least within a single process: You compile your IDL into client stubs and object skeletons, and write your object (shown on the right) and a client for it (on the left). Stubs and skeletons serve as proxies for clients and servers, respectively. Because IDL defines interfaces so strictly, the stub on the client side has no trouble meshing perfectly with the skeleton on the server side, even if the two are compiled into different programming languages, or even running on different ORBs from different vendors.

In CORBA, every object instance has its own unique object reference, an identifying electronic token. Clients use the object references to direct their invocations, identifying to the ORB the exact instance they want to invoke (Ensuring, for example, that the books you select go into your own shopping cart, and not into your neighbor's.) The client acts as if it's invoking an operation on the object instance, but it's actually invoking on the IDL stub which acts as a proxy. Passing through the stub on the client side, the invocation continues through the ORB (Object Request Broker), and the skeleton on the implementation side, to get to the object where it is executed.

How does CORBA support interoperability?

CORBA’s goal is to address interoperability at various levels. There is a history to this.

In the early versions of CORBA, interoperability between platforms and programming languages was addressed. This included the standardization of IDL and the mapping of IDL to a programming language. While a client and server developed with the same vendor’s ORB could talk to one another, a client and server developed with different vendors? ORBs were not likely to interoperate.

CORBA 2.0 introduced interoperability between different ORB vendors. This resulted from the introduction of a standard wire protocol called General Inter-ORB Protocol (GIOP), and the incarnation for GIOP for the internet, known as Internet Inter-ORB Protocol (IIOP). So CORBA 2.0 compliant ORBs will interoperate. This means a client using ORB vendor A can talk to a server using ORB vendor B.

Interoperability is actually a broader issue than just have ORB vendor A talking to ORB vendor B. Fuller interoperability means that various services interoperate. For example, while a CORBA object can talk to a DCOM object via a protocol bridge, can the CORBA Transaction Service talk to the Microsoft Transaction Service to have a seamless transaction between systems? This broader interoperability at the service level is being addressed now.

What is CORBA? What does it do?

CORBA is the acronym for Common Object Request Broker Architecture, OMG's open, vendor-independent architecture and infrastructure that computer applications use to work together over networks. Using the standard protocol IIOP, a CORBA-based program from any vendor, on almost any computer, operating system, programming language, and network, can interoperate with a CORBA-based program from the same or another vendor, on almost any other computer, operating system, programming language, and network.

Java interview questions (1)

2011-05-29T06:06:00.000-07:00

1. What is the purpose of serialization?

Answer: Serialization is the conversion of an object to a series of bytes, so that the object can be easily saved to persistent storage or streamed across a communication link. The byte stream can then be deserialised – converted into a replica of the original object.

2. What is the difference between JDK and JRE?

Answer: Java Development Kit (JDK) is the most widely used Java Software Development Kit. Java Runtime Environment (JRE) is an implementation of the Java Virtual Machine which executes Java programs.

3. What is the difference between equals() and “==” ?

Answer: Equals is intended to check logical equality and == checks if both references point to same object.

4.When will you use Comparator and Comparable interfaces?

Answer: java.util.Comparator and java.lang.Comparable
java.util.Comparator compares some other class’s instances, while java.lang.Comparable compares itself with another object.

5. What is the wait/notify mechanism?

Answer: This deals with concurrent programming. The wait() and notify() methods are designed to provide a mechanism to allow a thread to be block until a specific condition is met. However, java.util.concurrent should be used instead of wait() and notify() to reduce complexity.

6. What is the difference between checked and unchecked exceptions?

Answer: In general, unchecked exceptions represent defects in the program (bugs), which are normally Runtime exceptions.
Furthermore, checked exceptions represent invalid conditions in areas outside the immediate control of the program.

7. What is the difference between final, finally and finalize?

Answer: “final” is the keyword to declare a constant AND prevents a class from producing subclasses. (Thanks Tom Ellis)
“finally” is a block of code that always executes when the try block is finished, unless System.exit() was called. finalize() is an method that is invoked before an object is discarded by the garbage collector

8. What is the difference between web server and app server?

Answer: A Web server exclusively handles HTTP requests, whereas an application server serves business logic to application programs through any number of protocols.

9. Explain the Struts1/Struts2/MVC application architecture?

Answer: Struts was adopted by the Java developer community as a default web framework for developing web applications
The MVC(Model–view–controller) an application that consist of three distinct parts. The problem domain is represented by the Model. The output to the user is represented by the View. And, the input from the user is represented by Controller.

10. What is the difference between forward and send redirect?

Answer: Both method calls redirect you to new resource/page/servlet. The difference between the two is that sendRedirect always sends a header back to the client/browser, containing the data in which you wanted to be redirected.

11. How does a 3 tier application differ from a 2 tier one?

Answer: Tiers are the physical units of separation or deployment, while layers are the logical units of separation.
Imagine that you’re designing an e-commerce website. A 3 tier architecture would consist of web pages, a web server and a database, with the corresponding 3 layers being the “Presentation”, “Business Logic” and “Database” layers.
If you take the database tier and layer out then your have a 2 tier architecture.

12. How does the version control process works?

Answer: Initiate, pull, branch, merge, commit, push.
(Init) Make your own repository. (Pull) Download an existing repository from a url. (Branch / Merge )Make revisions. Commit then push your modifications.

13. What is the difference between JAR and WAR files?

Answer: JAR files (Java ARchive) allows aggregating many files into one, it is usually used to hold Java classes in a library.
WAR files (Web Application aRchive) stores XML, java classes, and JavaServer pages for Web Application purposes.

14. What is a Left outer join?

Answer: This deals with SQL. Left outer join preserves the unmatched rows from the first (left) table, joining them with a NULL row in the shape of the second (right) table.

15. What is the difference between UNION and UNION ALL?

Answer: This deals with SQL. UNION only selects distinct values, UNION ALL selects all values.

Get the current working directory in Java

2010-08-25T23:32:00.000-07:00

The current working directory is stored in the system property "user.dir". The following example shows how to read this system property from your application:

public class UserDirectoryTest

{     public static void main(String[] args)

    {         System.out.println("Working Directory = " +            System.getProperty("user.dir"));     } }

Cheers,

Vinay

Executable Jars

2010-06-18T01:23:00.000-07:00

Languages like .NET and C++ have historically had the advantage of being OS-friendly, in that simply referencing their name at the command-line (helloWorld.exe) or double-clicking their icon in the GUI shell would launch the application. In Java programming, however, a launcher application — java — bootstraps the JVM into the process, and we have to pass a command-line argument (com.tedneward.Hello) indicating the class whose main() method we want to launch.

These additional steps make it harder to create user-friendly applications in Java. Not only does the end user have to type all of these elements at the command-line, which many end users would rather avoid, but chances are good that he or she will somehow fat-finger it and get an obscure error back.

The solution is to make the JAR file "executable" so that the Java launcher will automatically know which class to launch when executing the JAR file. All we have to do is introduce an entry into the JAR file's manifest (MANIFEST.MF in the JAR's META-INF subdirectory), like so:

Listing 2. Show me the entrypoint!
Main-Class: com.tedneward.jars.Hello

The manifest is just a set of name-value pairs. Because the manifest can sometimes be touchy about carriage returns and whitespace, it's easiest to use Ant to generate it when building the JAR. In Listing 3, I've used the manifest element of the Ant jar task to specify the manifest:

Listing 3. Build me the entrypoint!

All a user has to do to execute the JAR file now is specify its filename on the command-line, via java -jar outapp.jar. In the case of some GUI shells, double-clicking the JAR file works just as well.

Looking for a file in a Folder

2010-05-19T04:11:00.000-07:00

The java.io.FileFilter interface can be used to filter an array of files obtained when looking inside a directory.

An example implementation of FileFilter

class JarFileFilter implements FileFilter
{
public boolean accept(File file)
{
if(file.getName().toLowerCase().endsWith("jar"))
{
return true;
}
return false;
}
}

The above implementation class narrows down the list of files to only jar files.

This filter can be used when looking into a directory using java.io.File.

example snippet:

String myDirectoryLoc = "c:\myjars";
File myFolder = new File(myDirectoryLoc);

if(myFolder.isDirectory())
{
File[] myjars = myFolder.listFiles(new JarFileFilter);

if(myjars != null)
{
for (File f : myjars )
{
System.out.println("file: " + f.getName());
}
}
}

On successful execution you will get only the jar files in the specified folder.

Hope this is useful.

Cheers
Vinay

Loading Properties from a file in class path

2009-08-31T01:54:00.000-07:00

A simple and smart way of loading a properties file which is located some where in the classpath

-------------------------

InputStream in = null;

Properties m_Properties = null;

in = ClassLoader.getSystemClassLoader().getResourceAsStream(fileName);

if (in != null)

{

m_Properties = new Properties ();

try {

m_Properties.load (in);

}

catch (IOException e)
{

e.printStackTrace();

}

Eliminating unnecessary log4j setup output

2009-07-08T03:34:00.001-07:00

When using log4j for logging in your application, you may see a lot of log messages added by log4j when startup of the application which are not required. These will add to noise in your log files.

They will look something like

log4j: Retreiving an instance of org.apache.log4j.Logger.
log4j: Setting [Myclass] additivity to [false].
log4j: Level value for Myclass is [DEBUG].
log4j: Desired Level sub-class: [org.apache.log4j.Level]
log4j: Myclass level set to DEBUG
log4j: Class name: [org.apache.log4j.ConsoleAppender]
log4j: Setting property [target] to [System.out].
log4j: Parsing layout of class: "org.apache.log4j.PatternLayout"
log4j: Setting property [conversionPattern] to [%-5p %m%n].

These are the debug information from the logger itself. If you are using the XML config it looks like this:

log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="true"

Turn the debug to false.

Difference between ++x and x++ in Java

2009-07-08T02:28:00.000-07:00

++x is called pre-increment while x++ is called post-increment.

For Example:

-- Code --

int x = 5, y = 5;

System.out.println(++x); // outputs 6
System.out.println(x); // outputs 6

System.out.println(y++); // outputs 5
System.out.println(y); // outputs 6

----------

Check JDK Version used to compile a class

2009-07-08T02:22:00.001-07:00

If you want to check the JDK version used to compile a class, use the below command

javap -verbose MyClass

Where MyClass is the class file you are checking.

Some example values it will return are

Java 1.2 uses major version 46
Java 1.3 uses major version 47
Java 1.4 uses major version 48
Java 5 uses major version 49
Java 6 uses major version 50

Reading a String line by line

2009-07-08T02:17:00.000-07:00

Given a string that isn't too long, What are the ways read it line by line?

Method 1:

BufferedReader reader = new BufferedReader(new StringReader());
reader.readLine();

Method 2:

final String eol = System.getProperty("line.separator");
output = output.substring(output.indexOf(eol + 1));

Method 3:

String[] lines = string.split(System.getProperty("line.separator"));

Method 4:

Scanner scanner = new Scanner(myString);
while (scanner.hasNextLine()) {
String line = scanner.nextLine();
// process the line
}

Ways to implement singleton pattern in Java

2009-05-20T05:52:00.000-07:00

There are many, time tested ways to implement Singleton pattern in Java all having its own advantage and drawbacks.

A simple and less confusing way to implement this is

public class
{
public final static Bar bar = new Bar();
private Bar()
{
// This prevents class instantiation from outside
}
public static Bar getBar()
{
return bar;
}
}

This is cleaner and readable code, but it does not give us an option of lazy initialization.
When you have a very large object or heavy construction code AND also have other accessible static methods or fields that might be used before an instance is needed, then and we need the lazy initialization option.

public class Bar
{
public final static Bar bar ;
private Bar()
{
// This prevents class instantiation from outside
}
public static Bar getBar()
{
synchronized(Bar.class)
{
if(bar == null)
{
bar = new Bar();
}
return bar;
}
}
}

The synchronized block helps to keep this instance creation thread safe.

If we are using Java 5 or above, we can use the additional feature provided by it for Double Checked locking. Without this, other threads are not guaranteed by the JMM ( Java Memory Model) to see the changes to its value.

You can refer this classic article on this subject:

http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

public class Bar
{
public static volatile Bar bar ;

private Bar()
{
// This prevents class instantiation from outside
}

public static Bar getBar()
{
synchronized(Bar.class)
{
if(bar == null)
{
bar = new Bar();
}
return bar;
}
}
}

Note the volatile keyword which does the trick.

Adding
protected Object clone()
{
throw new CloneNotSupportedException();
}

Would make Singletons better !!.

we have to choose the design based on requirement and make use of Singletons very carefully in our applications.

Cheers
Vinay

What to know as a Java Developer?

2009-04-16T07:49:00.000-07:00

For a Software profession, every day there are new things to learn. With constant updating of technologies surrounding our technical and domain expertise, we should have a strong base knowledge around with we have to build our technical skills in line with new developments.

For a java developer, we should build our base knowledge around fundamentals of Java language and be strong in java interfaces, generics, annotations, concurrency etc., It's easy to learn quickly new technologies when you master the fundamentals.

Here is a list of things which (out of many things) a java developer must be aware of.

1. How does JVM work?
2. Improvements on language from major version changes (Generics, Annotations, Enums ...).
3. What are the OOPS concepts and how do they Implemented in Java?
4. Understand design pattern
5. Coding Conventions.
6. Build tool (Ant) or Project Management Tool (Maven).
7. At least basic knowledge of some popular frameworks such as Struts, springs, hibernate.
8. Writing test cases using Junit.
9. Good knowledge of Eclipse ( or any popular IDE ).
10. Knowledge of using log4j.

why not ALWAYS use ArrayLists in Java?

2009-04-04T23:35:00.000-07:00

If you need a collection of primitives, then an array may well be the best tool for the job. Boxing is a comparatively expensive operation. For a collection (not including maps) of primitives that will be used as primitives, I almost always use an array to avoid repeated boxing and unboxing.

I rarely worry about the performance difference between an array and an ArrayList, however. If a List will provide better, cleaner, more maintainable code, then I will always use a List (or Collection or Set, etc, as appropriate, but your question was about ArrayList) unless there is some compelling reason not to. Performance is rarely that compelling reason.

Using Collections almost always results in better code, in part because arrays don't play nice with generics, as Johannes Weiß already pointed out in a comment, but also because of so many other reasons:

Collections have a very rich API and a large variety of implementations that can (in most cases) be trivially swapped in and out for each other
A Collection can be trivially converted to an array, if occasional use of an array version is useful
Many Collections grow more gracefully than an array grows, which can be a performance concern
Collections work very well with generics, arrays fairly badly
As TofuBeer pointed out, array covariance is strange and can act in unexected ways that no object will act in. Collections handle covariance in expected ways.
arrays need to be manually sized to their task, and if an array is not full you need to keep track of that yourself. If an array needs to be resized, you have to do that yourself.

All of this together, I rarely use arrays and only a little more often use an ArrayList. However, I do use Lists very often (or just Collection or Set). My most frequent use of arrays is when the item being stored is a primitive and will be inserted and accessed and used as a primitive. If boxing and unboxing every become so fast that it becomes a trivial consideration, I may revisit this decision, but it is more convenient to work with something, to store it, in the form in which it is always referenced. (That is, 'int' instead of 'Integer'.)

Array or List in Java. Which is faster ?

2009-04-04T23:33:00.000-07:00

The Java way is that you should consider what data abstraction most suits your needs. Remember that in Java a List is an abstract, not a concrete data type. You should declare the strings as a List, and then initialize it using the ArrayList implementation.

List<String> strings = new ArrayList<String>();

This separation of Abstract Data Type and specific implementation is one the key aspects of object oriented programming.

An ArrayList implements the List Abstract Data Type using an array as its underlying implementation. Access speed is virtually identical to an array, with the additional advantages of being able to add and subtract elements to a List (although this is an O(n) operation with an ArrayList) and that if you decide to change the underlying implementation later on you can. For example, if you realize you need synchronized access, you can change the implementation to a Vector without rewriting all your code.

In fact, the ArrayList was specifically designed to replace the low-level array construct in most contexts. If Java was being designed today, it's entirely possible that arrays would have been left out altogether in favor of the ArrayList construct.

Since arrays keep all the data in a contiguous chunk of memory (unlike Lists), would the use of an array to store thousands of strings cause problems ?

In Java, all collections store only references to objects, not the objects themselves. Both arrays and ArrayList will store a few thousand references in a contiguous array, so they are essentially identical. You can consider that a contiguous block of a few thousand 32-bit references will always be readily available on modern hardware. This does not guarantee that you will not run out of memory altogether, of course, just that the contiguous block of memory requirement is not difficult to fufil.