Finance: what is OTC (Over the counter)

welcome anyone to try to make the story even clearer. I'm happy with most of it, but the end of it could be a bit clearer.

"Bob makes money by selling and buying chocolate.

It's currently the beginning of October. Because Halloween is coming up at the end of the month, the price of chocolate bars is expensive because lots of people eat chocolate at Halloween and people are buying chocolate to give to trick-or-treaters. Chocolate bars in October currently cost $2.00 each. Bob thinks that after Halloween the price of chocolate bars will fall to $1.00 each because people will have eaten so much chocolate that they don't want to even see chocolate for another month.

Because of this Bob tweets that he is willing to sell 100 chocolate bars at $1.50 each.

Carol sees Bob's tweet and thinks "$1.50 per chocolate bar? Wow, that's a really good deal since chocolate bars cost $2.00 each."

Carol doesn't celebrate Halloween and she doesn't realize that Halloween could have an impact on the price of chocolate, so she sends Bob a direct message on Twitter saying that she will sign an agreement on paper that she will buy the 100 bars of chocolate for $1.50 each in November.

Bob and Carol have both just signed a futures contract, which is basically an agreement to buy or sell something to each other in the future for a price they decided on today.

After Halloween, the price of chocolate bars falls to $1.00 like Bob expected because nobody is buying chocolate bars from the store because they got tons from "trick-or-treating". On November 1st, Bob then buys 100 bars of chocolate from the store for $100 dollars.

Because Carol promised to Bob that she would buy the chocolate when she signed that agreement, she has to buy the 100 bars of chocolate for $1.50 each as she agreed to in the contract. Bob sells 100 bars of chocolate for $150. Since he just bought them for $100, that means that he just made $50 on the futures contract he signed with Carol.

Agreements like the one that Bob and Carol agreed to take place everyday in the futures market. The futures markets are a lot like stock markets except, instead of trading pieces of companies, people are trading commodities like beef, corn, steel, etc.

Some of these people do this because they want to make money like Bob did. Others do this to protect themselves. For example, MacDonald's might buy futures contracts on beef because they think the beef might get expensive in the future and they want to get a good price on beef today.

Whatever the product the people are trading, hundreds of thousands of these trades take place everyday.

Now OTC Derivatives are a lot like the futures contract that Bob negotiated with Carol and that people trade everyday.

Except instead of going to futures market, they instead negotiate directly. This is why it's called "over the counter." Like OTC medicines, there is no one that owns the market regulating how things are traded.

When Bob negotiated directly with Carol via Twitter, he basically made an OTC agreement because Bob and Carol did business with one another directly.

In real markets however, the people who are in the market just to make money speculating on how prices will change will never see the product they are signing an agreement on. Bob and Carol may never see the actual chocolate bars. Maybe Carol doesn't even like chocolate and are just buying the rights to buy chocolate because she thinks that she could have sold the chocolate bars to someone else at the $2.00 price of chocolate before Halloween.

When people are trading the right to buy or sell a product like chocolate, they are basically trading pieces of paper like "I.O.U.s" that can be exchanged for chocolate bars by anyone, but they never see the actual bars of chocolate themselves. When they do this, they are trading derivatives. Those agreements that are worth a certain number of chocolate bars derive their value from the number of chocolate bars that the final bearer, or holder, of the I.O.U.s can get.

Inner Class accessiblity mystery in java.....

Here is an interesting concept which I came across just recently and considered it worth sharing. I was reading about inner classes concepts where in, there is a type of inner class called the local inner class. Local inner classes are those classes which reside within the function of a method belonging to an outer class. The code can be something shown like this.

public class LocalInnerClassTest {
 public void defineInnerClass() {
  class MyLocalInnerClass {
  public void doSomething() {    
   }
  } 
 }
}

Now lets suppose we want to pass a variable in the defineInnerClass() and pass it to the doSomething() for some computation, then according to the specifications on local inner classes methods we must declare the variables as final or else it will result in a compile time error. So the resulting code must be something as follows:

public class LocalInnerClassTest {
 public void defineInnerClass(final int var) {
  class MyLocalInnerClass {
   public void doSomething() {
    System.out.println(var);
}
}
}
}

where var is the variable that must be declared as final to be passed into the doSomething() method of MyLocalInnerClass. Now the mysterious question which I faced was why exactly such a specification has been outlined. Why can’t the inner class simply take the variable as it is and process further.
In order to understand this reason as to why local inner classes can access only final variables, we have to learn how exactly inner classes get translated to the byte code. The moment you come to know this, you can easily see the logic behind making the variables final.
How Are Inner Classes Translated to the Byte Code
Here is the secret. Inner classes as you must have known them from a long time are still mysterious to the JVM. Yes its true. Inner classes have been implemented only to the compiler level. When the classes are compiled which contain inner classes, the byte code which gets generated does not actually implement inner classes as a class within a class. The book on Core Java from makes this statement:

“Inner classes are translated into regular class files with $ (dollar signs) delimiting outer and inner class names and the virtual machine does not have any special knowledge about them”

That means when the above class file from the example is compiled it will generate two class files such as:

1. LocalInnerClassTest.class
2. LocalInnerClassTest$MyLocalInnerClass.class

Unfurling the mystery of final variables:-
If you apply logic to the above theory of inner class at the byte code level, you have the answer to the mystery of having final variables. For explanation purpose, lets take the same example.
First lets say we make a call to the defineInnerClass() by creating an instance of LocalInnerClassTest. At this point, the instance of MyLocalInnerClass is still not present because the JVM treats it as a separate class at the byte code level. So when the call to defineInnerClass() is made the JVM tries to instantiate an object of MyLocalInnerClass.
But here we run into a problem. The function doSomething() accesses the var variable which is passed down from the outer class method. If you can simply apply logic over here, you can see the problem. How should the JVM pass the variable which has been declared in one class file to the method in another class file?
In order to solve this big problem, the JVM acts smart. It makes a requirement for the developer to make the variable passed from the method of an outer class to be declared as final. How would this solve the problem, you may ask? When you declare the variable var as final the compiler does a trick. The trick being, it quietly places a hidden variable with the name val$var inside the 2nd compiled class file.
The variable val$var is assigned the same value which has been assigned to var since now the compiler knows that the value cannot be changed as it has been declared final. This is very clever, since final variable must always be assigned before compilation.
So there you go. Now, when you run the program from within an application the inner class already has the value which has been assigned to var through its inner hidden variable val$var and thus the mystery gets solved. Therefore you have the concept that local inner class methods can have access to only the final variables of the outer class.

Hey, Local Inner Classes can even access Outer Class member variables directly. How?

Ok, now that we have tackled the above mystery, this is more simpler. The below code gets perfectly compiled

public class LocalInnerClassTest {
     private int var2;

     public void defineInnerClass(final int var){
    class MyLocalInnerClass{
   public void doSomething(){
    System.out.println(var+var2);
   }
        }
     }
}

You can notice that the local inner class has direct access to even the private variable var2 of its outer class. The reason behind the accessibility of outer member variables directly inside the local inner classes is that, once again the compiler cleverly places one more hidden variable named as this$0 which is a final instance variable of the outer class type. When the inner class object is instantiated the variable this$0 is given a reference to the outer variable with direct access privileges. Hence you can access the outer class member variables directly from within the inner class. Smart isn’t it?

JDK7 and Java SE7

Most of all are knowing about the Java 7 is planned to release on mid 2011. This JDK will have new feature which all we can categorize in these : Productivity, Performance, Universality, Modularity Integration, Serviceability.

In the Productivity area, we should expect to see new features like simplified Generics, which allows for easier code writing by not having to repeat the generic part both in the declaration of the variable and in the instantiation of the object. There's also the new try syntax for using resources, which allows you to declare temporal resources that need to be closed after the try block is done.

In the performance area, there are several things that come for the new version, which include the Fork/Join Framework, in which you can take a long running process and divide it in several threads, which is done automatically by the framework. Also, they introduced the concept of Lambda expressions, which is Java's way of implementing closures, combined with default methods for Interface declarations to allow for the expressions simplification. They also introduced the concept of reification, value classes and the long awaited properties.

In the universality area, they introduced a new project, DaVinci, which will allow first-class architectural support for languages other than java, like Ruby and Python.

Modularity integration, which they call Project Jigsaw, is probably one of the coolest features to me, and what they're trying to do is take away the classpath "hell" in which you have to define every single jar on the command line, and instead you create modules, and use a special module definition language where you specify the dependencies. New tools are introduced for this, jpkg which creates modules, and jmod, which allows for the management of the modules. When you create a new module, you install it in a local repository. As for the dependencies, you can add external module repositories so that the dependencies are downloaded and installed automatically. They even integrate with Maven, which is great because there are already lots of resources in the different maven repositories. There's also a new package format, jmod, which is supposed to be better for compressing java class files, and they will even support the generation of rpm (one of Linux package formats) natively. This is more a less extensive modularity feature of new Java.

Finally, in the Serviceability area, something called JVM Convergence, in which they want to extend the concept of a jvm make it a black box, which means you will be running a virtual machine that might be composed of one or more real machines in the background.

As for the release schedule, it seems like they are going with plan B. In case you didn't know, Mark Reinhold commented on his blog the current release schedule and how it was unrealistic. Some of the features have been finished, like Project Coin (in part) , InvokeDynamic (dynamic language support) and Fork/Join Framework and some features that aren't finished like Jigsaw (modules) and Lambda (closures). The idea is to release the completed features mid 2011, and move the rest of them to Java 8, to be released (hopefully) Late 2012.

More information about this can be found at the main JDK 7 site.

Iterator vs Enumeration

As all of you know both Iterator and Enumeration are used to traverse Collection objects, in a sequential fashion. Enumeration can be applied to Vector and HashTable. Iterator can be used with most of the Collection objects.

Differences between Iterator & Enumeration:
Enumeration is twice as fast as Iterator and uses very less memory. Enumeration is very basic and fits to basic needs. But Iterator is much safer as compared to Enumeration, b’ coz it always denies other threads to modify the collection object which is being iterated by it. Whenever a second thread tries for that Iterator will throw a ConcurrentModificationException. Iterators that do this are known as fail-fast iterators, as they fail quickly and cleanly.

See what happens to this code segment,

Vector aVector = new Vector();
aVector.add("I");
aVector.add("am");
aVector.add("really");
aVector.add("good");
Enumeration anEnum = aVector.elements();
Iterator anItr = aVector.iterator();
// Traversal using Iterator
while(anItr.hasNext())
{
if ()
// This statement will throw ConcurrentModificationException.
// Means, Iterator won't allow object modification while it is
// getting traversed. Even in the same thread.
aVector.remove(index);

System.out.println(anItr.next());
}
// Traversal using Enumeration
while(anEnum.hasMoreElements())
{
if ()
aVector.remove(index);

System.out.println(anEnum.nextElement());
}
But Iterator provides a safer way to remove elements from the underlying collection during the iteration with well-defined semantics. See the implementation of Iterator. But here the remove() is supported by only those implementations of Collection that supports element removal.

public interface Iterator
{
boolean hasNext();
Object next();
void remove(); // Optional
}
So the above program part can be re-writen as,

while(anItr.hasNext())
{
System.out.println(anItr.next());
if ()
anItr.remove();
// Note:
// Before using anItr.remove(), the Iterator should
// point to any of its elements. The remove() removes the
// element which the Iterator corrently pointing to.
// Otherwise it will throw IllegalStateException

}
Note that Iterator.remove() is the only safe way to modify a collection during iteration. In Enumeration, there is “no safe way” to remove elements from a collection while traversing.

AutoBoxing in java : A boon when used carefully!

I am sure this is a very known mistake that should be avoided, but, it costed me an hour to figure out why the application I am working on was not behaving appropriately. I was looping through a list to find out an object that has to be removed. And, then the index was to be used to remove the object. The Objects in the list had over-ridden the equals and hashcode method,and I could not use the 'indexOf' or 'remove' on the list to find the object and remove it. My mistake was to use Object Integer instead of native int. Well every thing worked fine, but When called remove on the list, the List was trying to remove the integer object instead of object at that integer index! Solution was simple as you al know!! Just an interesting point to be taken down in my diary.

private List stocksSubscribed = new ArrayList();

private void removeStockWithStockName(String symbol) {
Integer removalIndex = 0;
for(Stock stock : stocksSubscribed){
if(symbol.equalsIgnoreCase(stock.getSymbol())){
break;
}
removalIndex++;
}
stocksSubscribed.remove((int)removalIndex);
}

Our men in uniform are fighting the nation's battle. We should not demoralise them

Anybody who has been watching the Kashmir tragedy unfold on live television will know who's the aggressor, who's on the defensive. The mobs are running riot, provoking, attacking and bullying the police and armed forces. The latter are withdrawing into their shells, trying to defend themselves as best as they can. If we still hear about civilian deaths daily, it's not too difficult to imagine why: when the attackers get too close or threatening, the men in uniform fire, and someone, sometimes drops dead. It's not really about a trigger-happy force.

This is not the time to demoralise our men in uniform. They are fighting the nation's battles in extremely adverse conditions. Our politicians keep screwing up continuously, and we then send in the forces to bring back some semblance of order. But the human rights rabble-rousers would like us to believe that our armed forces are little more than criminals. This is completely unacceptable.

There is more rape and murder in lawless Delhi than in Kashmir. But we want to paint the armed forces as the villains of Kashmir. Libertarians need to think about the rights of uniformed Indians as much as civilians.
Let's be clear why the armed forces are there in the first place. Kashmir is where embattled secularism is trying to hold its o...

Expectations and Disappointments...

I have faced a cycle of this always in reference to my relationships with others. People's expectations from me, and their opinion of my expectations from them is so different from what I believe. I have always been a person who will call you or contact you when I truly feel like, not when I feel that it's a courtesy to call. And, I expect the same from you. I expect that people who are close to me will not only "Call" me whenever they require me for their purpose only . I don't remember if I ever myself complaint anybody about being too busy to call [Exceptions are always there ;) ]. I have friends who does and those relationships are/will not so strong[failed] for me.

May be I am too unsuited for what a "social" relationship means today's practical & professional era. I probably cannot change myself, because whenever I tried to, I felt as if I am "faking" to be something which I am not.... But, I do force myself occasionally, because there are some situation where I cannot afford to make others changes, instead of change myself. But it happens occasionally for small span and very hard do ...... :(