Crave 'd

After being programming with Java for sometimes now, heading on to Python world. So far, it is very interesting too. Psyco!

       I have been wandering through my company blogs and found an interesting article about NoSQL. So, what is NoSQL and what is its usage? If you are not aware then the answer is here.

I am tired of the fact that performance is really a backdrop in Groovy (because of its dynamic nature) after reading through some of the sites that emerged as googling for the topic. I didnt lose my interest in the approved dynamic language for The Java Platform, but suspended my journey until i am done with another robust, some say complex, programming language Scala. HoooHoooo… I guess Scala is giving me a good start, as i am looking for a language that should be in par with performance as Java, as well as reduce all the boiler-plate code and other possible syntaxes etc. of Java. 

….. into the world of Scala, a scalable programming language…..

Hello,

  I had a long will to learn Groovy as it supports scripting behavior and compact syntax and still complying with the JVM standards. Yes, the generation of bytecode from the .groovy script/class files interested me a lot. I also realized that Groovy is the second offical Programming Language for The Java Platform. Well, Groovy is another way to enjoy Java.

But, the fact being noticed while running a simple Fibonacci (10 series) generation program is.. the bytecode generated from Java took avg. 2 milliseconds to run whereas the bytecode generated from Groovy took avg. 55 milliseconds. Is there really such a huge performance issue with Groovy generated bytecode due to its Script/Closure style?

Hmm.. Need to explore more.

Java methods (either static or instance) when modified with the ‘synchronized’ keyword does not allow any second thread to access it/ other synchronized methods (either static or instance) when one thread has obtained a lock on its parent object. But, today i saw a case where second thread actually steals the lock from the thread which is holding the lock in a legal way. 

On further search reveals that when Thread.join is invoked from within a synchronized method, the call results in calling Object.wait which will actually release the lock which the waiting thread owns.