Arraylist - Key Factor

Similar to the one below, another common recommendation would be which is better - ArrayList/Vector/Linked List. There are various factors to consider in saying which is better for example, if we consider retrieval of elements from the list - arraylist is faster than linkedlist but when you consider adding an element at a particular position say '0' then linked list is faster. Lets not go into details now. But overall, in a general scenario, its always recommended to use Arraylist in place of vector. But Will that really help??

Internally, both the ArrayList and Vector hold onto their contents using an Array. But when any new element is inserted into an ArrayList or a Vector, the object has to expand its internal array in case it is overbound. In that scenario, a Vector defaults by doubling the size of its array, while the ArrayList increases its array size by 50 percent. So, in case the arraylist or vector are not defined with initial capacity, the default size would be again 16characters. And then as new elements are being added, it keeps resizing itself apppropriately and you would end up taking a large performance hit.

So, It's always best to set the object's initial capacity to the largest capacity that your program will need. By carefully setting the capacity, you can avoid paying the penalty needed to resize the internal array later. If you don't know how much data you'll have, but you do know the rate at which it grows, Vector does possess a slight advantage since you can set the increment value.

Use StringBuffer instead of += -- Will this really help??

A very commonly suggested optimization technique for Java is to use a StringBuffer instead of a String when concatenating. Typical reaosn would be that using the + or += operators to concatenate strings causes a new object to be created for each concatenation. On the other hand, the StringBuffer contains an append() method, which allows dynamic string growth without having to create a new String object each time.

But we have a catch here, this can sometimes be observed as ineffecient or not effective as much as it is expected to be. Why? - This can be explained as below.

Take the example

Snip1:: String s1 = "Hello";
s1 = s1 + " XX";

Snip2:: StringBuffer sb = new StringBuffer("Hello");
sb.append("XX");

Now when both the above snips are compiled. In snip1, the compiler is smart enough to recognize when a number of concatenations are going to be executed and automatically creates a StringBuffer. Each concatenation operation is converted to append() calls behind the scenes.
So frankly, manually coding a StringBuffer is unnecessary, unless the following reason is considered.

In order for a StringBuffer to truly optimize concatenation, it must be seeded properly. In other words, it needs to be given an appropriate initial size. This is because the StringBuffer keeps the characters of the string it is maintaining in an array. When append() is called, the StringBuffer checks the size of the character array versus the estimated size of the new string. If the estimated size is larger than the actual array, a new array is created and the old array is copied to the new one. Thus, StringBuffer is not only creating a new object for each concatenation, but it also incurs the overhead of copying all the indexes of the original array.

This can be overhead when using the default constructor. In that case, size defaults to character array of size to a measly 16 characters. The most used scenario in any application coding is SQL String creation. SQL strings assuredly will exceed 16 characters and constantly cause new character array objects to be created. Even using the StringBuffer's constructor that takes in a String only initializes the character array as 16 characters more than the length of the String argument.

Hence, the best way to be sure that the StringBuffer will benefit the performance of your application is to give it a large enough initial seed that it will need to create its character array only once based on your requirement.

SOA Without Governance = No ROI

Below is the link for a Online Conference on SOA Governance - July 17, 2008 .

http://www.soagovcon6.com/index.asp?type_content=home

In this event, The Top SOA Governance vendors have agreed to answer the 5 Tough Questions below. Tried answering those from my thoughts/experiences,

1. Does SOA Governance help me with both IT and business assets?
Yes definitely. SOA is aimed to Change the IT landscape so as to meet the Business Needs in a Agile Way, by delivering Faster Time to Market, Flexibility to Change. Governance Built over the implementation/enabling SOA into the Company would ensure the above principles are met and Assets created/deployed would be adhered to the Architectural Standards and Guidelines. Taking the example of BPM, This would enable Optimization of Business Processes, making them resuable and also retiring any redundant and duplicate processes which are hampering the Growth of the company. Its not that An SOA Road Map defined for the organisation would deliver all the Goodies that are expected out of it. The goverance framework is most important in ensuring all the principles with which the road map is defined are broken down to lower levels from design to implementation to deployment.

Below will answer shortly....

2. How Can SOA Governance help me comply and define SLAs for business, policy?
3. Compare SOA Lifecycle with Software Development Lifecycle. What's the same? What's different?
4. How do I test updates to existing live SOA services?
5. What are the Best Practices for designing & managing long-running transactions?

Welcome.. :-)

Welcome to my tiny sparks of Knowledge. Being a Software Professional and Currently working as Solution Architect, this blog is aimed to pen down my thoughts, ideas, experiences from my day to day Professional Life.