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.
Sunday, October 2, 2011
Monday, February 14, 2011
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.
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:
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:
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
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?
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:
- LocalInnerClassTest.class
- LocalInnerClassTest$MyLocalInnerClass.class
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?
Subscribe to:
Posts (Atom)