Tuesday, November 22, 2011

Installing mercurial on CentOS or RHEL 4

For mercurial/hg you need a relatively new version of python installed. Since that is not available as an rpm let's compile the source.

From http://python.org/download/ download a python source version like http://python.org/ftp/python/2.7.2/Python-2.7.2.tgz

From http://mercurial.selenic.com/release/ download a mercurial source drop like http://mercurial.selenic.com/release/mercurial-1.7.5.tar.gz

Run the following commands as root:
#Install some dependencies
yum install zlib-devel.i386 ncurses-devel.i386 openssl-devel.i386 readline-devel.i386 bzip2-devel.i386

#Extract the python code
tar xvzf Python-2.7.2.tgz
cd Python-2.7.2

# Python will be installed in /opt/python27
make clean; ./configure --prefix=/opt/python27; make; make install
cd ..

# Extract the mercurial code
tar xvzf mercurial-1.7.5.tar.gz
cd mercurial-1.7.5

#Python will be installed in /opt/hg17
make install PYTHON=/opt/python27/bin/python PREFIX=/opt/hg17

#Add new python and mercurial to PATH
export PATH=/opt/python27/bin:/opt/hg17/bin:$PATH

Tuesday, June 14, 2011

Java7 Automatic resource management


One of the useful features in Java7 is the Automatic resource management via the try-with-resources statement.

In the olden days thou would (or atleast were supposed to) code like:
void doSomething() throws IOException {
  OutputStream out = null;
  try {
    out = new FileOutputStream("");
  } finally {
    if (out != null) {

Which is error prone if you do forget to close the resources.

The new way is:

void doSomethingNew() throws IOException {
  try (OutputStream out = new FileOutputStream("")) {

This is syntactically much more pleasing and does the right thing internally.

Going deep:
The try-with syntax works with any AutoCloseable implementation and you can have multiple resources as well.

The compiler will transform the above code into something like:

void doSomethingNew() throws IOException {
  OutputStream out = null;
  Throwable localThrowable1 = null;
  try {
    out = new FileOutputStream("");
  } catch (Throwable localThrowable2) {
    // We keep a reference to which can add a suppressed exception
    localThrowable1 = localThrowable2;
    throw localThrowable2;
  } finally {
    if (out != null) {
      if (localThrowable1 != null) {
        // Already have an exception thrown
        try {
        } catch (Throwable localThrowable3) {
          // Add the suppressed exception during close
      } else {
        // Potentially throw an IOException due to failure when close'ing

The pattern is:

  • If there are no exception - close() in the finally block OR
  • If there are no exception during operation but there is an exception during close() then throw it OR
  • If there is an exception thrown then throw it after closing the resource OR
  • If there is an exception1 thrown then throw it .. and if there is an exception2 closing the resource.. then exception1.addSuppressed(exception2). This is new in theThrowable class

There was a huge effort to get closures into Java7 but none of the solutions was light on syntax/complexity. After the backlash over Generics a smaller but better step has been taken.

For scala see using. You do not need to wait for language changes to make syntactically pleasing APIs because of curry-ing and other fancy stuff.

More References:
ARM spec
Article on ARM

Wednesday, February 23, 2011

Beautiful software

I feel a deep sense of happiness when I use Google products like gmail and chrome. Every now and then they update the applications and things just work. They make things look so simple but they must be super complex in the back. That's great software.

Great software can only be built by great teams. That means everyone from engineers to managers. Give enough freedom to the team to execute. Treat them like people. Understand software.

No software methodology can save you. Let the team define its processes. Let common sense prevail. And then greatness will follow.

Tuesday, January 04, 2011

Where did the class get loaded from?

As with most enterprise apps gone crazy you have a bunch of duplicate jars or some jars at places you don't even know were in the classpath. And once a while you need to know from which jar a particular class file was loaded. To find this out run java with the -verbose:class flag. For each class loaded, the VM will print out the folder or jar where the class was found.

~ $ java -verbose:class HelloWorld
[Loaded HelloWorld from file:/C:/work/cygwin/home/rrevo/]
Hello World
[Loaded java.lang.Shutdown from shared objects file]
[Loaded java.lang.Shutdown$Lock from shared objects file]

Read java options for more info.

PS: It's time to start blogging again.