Dadidadida

SHA-1 and MD5: Mac vs Java

2009-11-03T09:40:00.000-08:00

echo -n "" | openssl dgst -sha1
=> da39a3ee5e6b4b0d3255bfef95601890afd80709

echo -n "" | md5
=> d41d8cd98f00b204e9800998ecf8427e

public class FooCrypt {
    public static void main(String[] args) throws Exception {
        MessageDigest sha1 = MessageDigest.getInstance("SHA-1");
        System.out.println("sha-1: " + bytesToHex(sha1.digest("".getBytes("UTF-8"))));
        MessageDigest md5 = MessageDigest.getInstance("MD5");
        System.out.println("md5: " + bytesToHex(md5.digest("".getBytes("UTF-8"))));
    }

    public static String bytesToHex(byte[] bs) {
        StringBuilder ret = new StringBuilder(bs.length);
        for (int i = 0; i < bs.length; i++) {
            String hex = Integer.toHexString(0x0100 + (bs[i] & 0x00FF)).substring(1);
            ret.append((hex.length() < 2 ? "0" : "")).append(hex);
        }
        return ret.toString();
    }
}

=> 
sha-1: da39a3ee5e6b4b0d3255bfef95601890afd80709
md5: d41d8cd98f00b204e9800998ecf8427e

Experimenting with Oracle DBMS_LOCK

2009-10-25T16:56:00.000-07:00

First, grant privilege to play with it. For example,

Login as user SYS with SYSDBA role, then

  grant all on dbms_lock to public;

How to try it out in SQL Developer ?

set serveroutput on;

declare
  v_result integer;
begin
  v_result := DBMS_LOCK.REQUEST(123, 6, 0, true);
  
  dbms_output.put_line(
           case 
              when v_result=0 then 'Success'
              when v_result=1 then 'Timeout'
              when v_result=2 then 'Deadlock'
              when v_result=3 then 'Parameter Error'
              when v_result=4 then 'Already owned'
              when v_result=5 then 'Illegal Lock Handle'
           end);
end;

How to do it in JDBC ?

  Connection conn = ...
  CallableStatement stmt = conn.prepareCall("{call ? := DBMS_LOCK.REQUEST(?, 6, 0, true)}");
  stmt.registerOutParameter(1, Types.INTEGER);
  stmt.setBigDecimal(2, new BigDecimal(123));
  stmt.execute();
  int result = stmt.getInt(1);
  System.out.println("result: " + result);

What comes next ?

2009-10-26T18:15:00.000-07:00

3
1 3
1 1 1 3
3 1 1 3
1 3 2 1 1 3
1 1 1 3 1 2 2 1 1 3
3 1 1 3 1 1 2 2 2 1 1 3
1 3 2 1 1 3 2 1 3 2 2 1 1 3

S3/SimpleDB Limitations

2009-09-07T18:10:00.000-07:00

S3 Limits - max 100 buckets per account, unlimited number of objects per bucket with object size < 5GB

SimpleDB Limits - max 10 GB per domain, max 100 domains per account, max 1KB attribute value, max 256 attributes per item

OpenSsl/Keytool Cheat Sheet

2007-06-18T15:31:00.000-07:00

# Convert an RSA public key from PEM to DER
openssl rsa -inform PEM -in test-public-key.pem -outform DER -out test-public-key.der -pubin

# Convert a X509 certificate from PEM to DER
openssl x509 -in test-x509-cert.pem -inform PEM -out test-x509-cert.der -outform DER

# Print a X509 certificate
openssl x509 -text -in test-public-cert.pem

# Import a certificate to JKS
jdk1.6.0/bin/keytool -storepass changeit -keystore truststore.jks -importcert -alias mycert -file mycert.der -trustcacerts

# http://www.agentbob.info/agentbob/79.html
# Read the javadoc in ImportKey.java for details of converting it to a keystore

# Convert a private key from PEM to DER
openssl pkcs8 -topk8 -nocrypt -in private-key.pem -out private-key.der -outform der

# Convert cert from PEM to DER
openssl x509 -in cert.pem -out cert.der -outform der

# Convert private key and cert to keystore
java -cp . ImportKey private-key.der cert.der

# Change the storepass
keytool -keystore keystore.jks -storepass importkey -storepasswd -new changeit

# Change the alias
keytool -keystore keystore.jks -storepass changeit -changealias -alias importkey -keypass importkey -destalias myhost

# Change the keypass
keytool -keystore keystore.jks -storepass changeit -alias myhost -keypasswd -keypass importkey -new changeit

# List the keystore
keytool -keystore keystore.jks -storepass changeit -list -v

# How to generate a self-signed key pairs using keytool ?
keytool -genkeypair -dname "cn=myname,ou=myunit,o=myorg,c=AU" -alias myalias -keypass changeit -keystore ./my-keystore.jks
-keypass changeit -storepass changeit -validity 9999 -v

### Extracting the certificate (public key) ###

# Export the X509 certificate
keytool -export -alias myalias -keystore my-keystore.jks -storepass changeit -file mycert.der

# Display it
openssl x509 -noout -text -in mycert.der -inform der

# Convert to PEM
openssl x509 -out mycert.pem -outform pem -in mycert.der -inform der

### Extracting the private key ###

#Download, compile & run ExportPriv.

# Export private key into pcks8 format
javac ExportPriv.java
java ExportPriv my-keystore.jks myalias changeit > my-key.pkcs8

# Combine public and private key into pkcs12 format
openssl pkcs12 -export -out my-key.p12 -inkey my-key.pkcs8 -in my-cert.pem

# Convert pkc12 to PEM so it can be displayed
openssl pkcs12 -in pkcs-12-certificate(-and-key-file) -out pem-certificate(-and-key-file)

Covariant Enum Idiom

2009-04-25T10:54:00.000-07:00

Say we want to have a Java Enum that can return different types from the same method by different constants, how could we go about writing it ? How about something like:

/**
 * An enum that can polymorphically return different types of object.
 */
public enum CovariantEnum {
    A { 
        @Override public String getValue() { return "CovariantEnum.A"; } 
    },
    B {
        @Override public Integer getValue() { return 1; }
    },
    // etc.
    ;
    public abstract <T> T getValue();
}

This would actually compile, except there are two problems. First, there are compilation warnings about "return type requires unchecked conversion". Second, it actually doesn't quite work as expected. Client code such as:

// This doesn't work :(
String stringValue = CovariantEnum.A.getValue();

would result in a type mismatch compilation error. Explicit casting the returned value to the target type, such as String in the above example, would work, but that defeats the purpose of building CovariantEnum in the first place.

So how can we get around these limitations ?

Well, first, Java disallows enum declaration to have type parameters. In other words, it is a syntax error to write:

public enum CovariantEnum<T> {
...

But what if we emulate a enum with an abstract class ? This may lead to something like:

/**
 * Basically a "CovariantEnum" that actually works and does not cause any compilation warnings.
 */
public abstract class TypeSafeCovariantEnum<T> {
    public static final TypeSafeCovariantEnum<String> A = new TypeSafeCovariantEnum<String>() { 
        @Override public String getValue() { return "TypeSafeCovariantEnum.A"; } 
    };
    public static final TypeSafeCovariantEnum<Integer> B = new TypeSafeCovariantEnum<Integer>() { 
        @Override public Integer getValue() { return 1; }
    };
    
    private TypeSafeCovariantEnum() {}
    public abstract T getValue();
}

Now compilation has zero warnings, and a client can enjoy using the "literal instances" in TypeSafeCovariantEnum as if it's a covariant enum without any need for explicit casting:

// This works!
String stringValue = TypeSafeCovariantEnum.A.getValue();
Integer integerValue = TypeSafeCovariantEnum.B.getValue();

Of course this is not an actual enum, and it involves a little complexity inside; but it provides 100% type safety, and simplicity to the clients outside :-)

Heap Dump in Java 6

2007-05-21T00:39:00.001-07:00

Just experimenting with the use of jmap and jhat in Java 6. The Object Query Language in jhat that allows the use of javascript closure seems pretty powerful, though also pretty slow.

Practices
# Find out the jvm pid
jps
# Trigger heap dump
jmap -dump:format=b,file=/tmp/java_app-heap.bin <pid>

# Analyzing the heap dump
jhat -J-Xmx326m /tmp/java_app-heap.bin

http://localhost:7000/showInstanceCounts/
http://localhost:7000/oql

#Find out the total size of MyClass instances
select sum(map(heap.objects('foo.bar.MyClass'), 'sizeof(it)'))

# List out all class names matching "foo.bar"
select filter(heap.classes(), "/foo.bar/(it.name)")

# Ditto
select map(filter(heap.classes(), "/foo.bar/(it.name)"),
    function(c) {
      return "<br>"+ c.name;
    })

# List classes that match "foo.bar" with instances > 0
select map(filter(heap.classes(), "/foo.bar/(it.name)"),
    function(c) {
      var len = length(heap.objects(c));
      if (len == 0) return "";
      return "<br>" + c.name + ", instances:" + len;
    })

# List classes that match "foo.bar" with instance sizes > 0
select map(filter(heap.classes(), "/foo.bar/(it.name)"),
    function(c) {
      var totalsize = sum(map(heap.objects(c), 
          function(o) {
              return sizeof(o);
          }
      ));
      if (totalsize == 0) return "";
      return "<br>" + c.name + ", size:" + totalsize;
    })

More info
How to find java memory leaks
Troubleshooting Guide for Java SE 6 with HotSpot VM
HeapDumpOnOutOfMemoryError option in 5.0u7 and 1.4.2_12
Permanent generation analysis with OQL
What's in my Java heap?
Querying Java heap with OQL
JavaOne 2007 BOF on Memory Leaks
BOF9982: The java.lang.OutOfMemoryError: PermGen Space error demystified

Local vs Any address in Cajo

2008-11-30T00:24:00.000-08:00

Looking into the cajo source code, I see the default server side host address used by cajo is the local host address. For example,

host = InetAddress.getLocalHost().getHostAddress();

This seems to work in most cases/platforms, except it breaks with the new Mac that I have. How does it break ? Well the server side binding works with the default (local) address, but the client would fail to connect to 127.0.0.1 or localhost. To make the client connect, I needed to figure out the specific local address (like 192.168.0.3) used for the server side binding, and explicitly specify that for the client.

When I tried to see if this was also the case outside cajo using the plain old ServerSocket(int), surprisingly it worked regardless of whether I specified locahost, 127.0.0.1, or 192.168.0.3.

Digging more into the JDK source code, ServerSocket uses an "any address" rather than a "local address" as the default:

InetAddress.anyLocalAddress();

Sadly, this static method is package private.

Anyhow, since the "any address" seems to work more so than the "local address", it would be nice if cajo can change the default server side address to the "any address", which would make cajo "just work" across more platforms.

Why use beanlib with Hibernate ?

2005-06-25T20:40:00.000-07:00

(This post is about Beanlib 2.x. Please go to the JavaBean Library home page for the latest and greatest.)

Put simply, in cloning a Hibernate entity bean, we want to specify how deep we want to go in the object graph. Is it a 100% deep clone, a skin deep shallow clone, or some other combinations ? How about beans that involve a one-to-many collection ? The answer to this question has a significant impact on both the performance and memory footprint of the cloning process.

The JavaBean Library provides the following options

100% deep clone which will result in eagerly fetching all related entites and populating the values into pure POJO's which therefore will get rid of all CGLIB enhanced instances;

Shallow clone which will result in cloning the top level bean and the immediately contained member fields of Java primitive types, String, Date, etc., but will exclude instances of Collection and application specific types. The excluded member fields will be set to null;

Partial deep clone that extends only to a specified set of classes and a specified set of "collection properties". A collection property can be specified via a class named CollectionPropertyName. This allows an arbitrary portion of the object graph to be deeply cloned;

Provide your own customized "Vetoer" by implementing the BeanPopulatable interface to control the population decision of each bean property;

Provide your own customized BeanPopulatable and/or DetailedBeanPopulatable to completely override the population decision of each bean property.

A new enhancement can be found here.

The class used for the above cloning is named HibernateBeanReplicator. There exists one for Hibernate 2.x and one for Hibernate 3.x.

Warming up a JVM

2008-11-22T07:51:00.000-08:00

If you knew the actual set of classes that will be lazily loaded into the JVM for execution, wouldn't it be nice if these classes can be eagerly loaded into the JVM upon start-up ? This particularly matters if you are writing web services, where the latency of the first few requests will be significantly impacted.

Pre-loading classes is easy. But how can we find out the precise set of classes to be preloaded ? It turns out there exists a very nice JVM option:

-verbose:class

Also found an interesting technical report: Eager Class Initialization For Java.

File Distribution and Replication via JGroups

2007-12-28T17:58:00.000-08:00

Here is how I used JGroups (2.6.1) to distribute and replicate files retrieved from a feed, so there is no single point of failure:

http://www.nabble.com/Re%3A-Streaming-Message-Transfer---p14510203.html

Here is a reply from Bela Ban basically confirming that the scheme works (via configuring a TCP stack):

http://www.nabble.com/Re%3A-Streaming-Message-Transfer---p14512866.html

The whole thread:

http://www.nabble.com/Streaming-Message-Transfer---td14476343.html

JGroups rocks!

Update on 13Nov08: Or does it ? After using JGroups for about a year now, it seems JGroups can be quite unreliable when the number of nodes in a cluster grow beyond half a dozen of nodes, especially if they span across a WAN. Or maybe it's just me ?

A little Java constructor pattern

2008-11-11T11:43:00.000-08:00

Say we have a class Item:

public class Item {
    final String name;
    final float val;
    final int size;
    
    public Item(String name, int size, float val) {
        this.name = name;
        this.val = val;
        this.size = size;
    }
}

and we'd like to initialize an Item array with some values:

Item[] items = {
    new Item("A", 3, 4),
    new Item("B", 4, 5),
    ...
};

Wouldn't it be nice if we can simplify it to:

Item[] items = {
    Item("A", 3, 4),
    Item("B", 4, 5),
    ...
};

?

Couldn't this be easily done by defining a static factory method with the same name as Item, and then use it via static import ?

public class Item {
    // ... same as above

    // A static factory method for the syntactic sugar
    public static Item Item(String name, int size, float val) {
        return new Item(name, size, val);
    }
}

Usage:

import static Item.Item;
...
Item[] items = {
    Item("A", 3, 4),
    Item("B", 4, 5),
    ...
};

Beanlib on BeanUtils wiki

2008-09-23T16:14:00.000-07:00

It made my day when I proposed to use Beanlib to solve a problem which the Jakarta Commons BeanUtils was not well suited, Beanlib ended up being included in the BeanUtils wiki as a related project :)

Thanks to Niall Pemberton for being open minded.

No more infinitely blocking socket ?

2008-09-22T12:35:00.000-07:00

One common problem Java programmer faces is the direct or indirect use of socket that could block forever. If a socket connect or read operation blocks with an infinite timeout, there is basically nothing that can interrupt the blocking thread besides closing the socket. Not Thread.interrupt(), nor even Thread.stop() would help. Gaining access to the underlying socket could, however, be difficult, considering the socket could be buried deep down inside some third party library, such as a JDBC driver.

Attending the NFJS session, Busy Java Developer's Guide to JDK Hacking by Ted Neward yesterday, a solution came to my mind when Ted demonstrated how easy it was to slip in my own classes ahead of the JDK's. Why not simply extend the existing JDK socket implementation with an additional system property to limit or default the socket timeout to some sensible values ? See an example implementation below. To make this work, simply

Set up a custom socket factory:

Socket.setSocketImplFactory(new SocketImplFactory() {
    @Override
    public SocketImpl createSocketImpl() { return new NicerSocksSocketImpl(); }
});

Slip in the implementation class and configure the socket timeout when starting up the JVM:
```
java -Xbootclasspath/p:"/path/to/custom/jdk/classes" -DSO_TIMEOUT=1000 ...
```

Now if a socket timeout is not specified by the individual application or library, the blocking operation would be limited to a maximum of 1,000ms before throwing up.

No more socket black hole sucking up resources:)

package java.net;
import java.io.IOException;

public class NicerSocksSocketImpl extends SocksSocketImpl {
    private final int defaultSoTimeout; 

    public NicerSocksSocketImpl() { this.defaultSoTimeout = defaultSoTimeout(); }

    public NicerSocksSocketImpl(String server, int port) {
        super(server, port);
        this.defaultSoTimeout = defaultSoTimeout();
    }

    public NicerSocksSocketImpl(Proxy proxy) {
        super(proxy);
        this.defaultSoTimeout = defaultSoTimeout();
    }
    
    private int defaultSoTimeout() {
        String defaultSoTimeoutStr = System.getProperty("SO_TIMEOUT");
        try {
            return Integer.parseInt(defaultSoTimeoutStr);
        } catch(RuntimeException ex) {
            return 5000;    // default to 5 seconds
        }
    }
    
    @Override
    protected void connect(SocketAddress endpoint, int timeout) throws IOException {
        super.connect(endpoint, timeout == 0 ? defaultSoTimeout : timeout);
    }

    @Override
    protected void connect(String host, int port) throws UnknownHostException, IOException {
        setTimeoutIfNecessary();
        super.connect(host, port);
    }
    
    @Override
    protected void connect(InetAddress address, int port) throws IOException {
        setTimeoutIfNecessary();
        super.connect(address, port);
    }
    
    private void setTimeoutIfNecessary() throws SocketException {
        int timeout = super.getTimeout();
        
        if (timeout == 0)
            super.setOption(SO_TIMEOUT, defaultSoTimeout);
        return;
    }
}

When is NEVER ever ?

2008-09-20T21:29:00.000-07:00

During one of today's NFJS sessions, Transaction Design Patterns by Mark Richards, the audience were asked when it would make sense to specify the transaction attribute NEVER in a real-life application.

My immediate answer to this was that if a method is known to never get involved in a transactional context, then specifying NEVER would allow the application to fail fast. But what would be the practical circumstances where a method should never get involved in a transaction, to the extent of potentially causing an exception in production ? And if there weren't really such circumstances, why not use the SUPPORTS attribute instead ? Asked Richard.

On second thought, maybe we can use the NEVER attribute a lot more often and useful than it now is. Let me explain.

Consider the transaction attribute REQUIRES_NEW, which basically creates a new transaction if one doesn't already exist. But what if there already exists a transaction ? Instead of throwing an exception, like NEVER, it would suspend the current transaction and creates a new one. However, suspending a transaction is both expensive and usually not the intended semantics, as Richard pointed out.

So wouldn't it be nice if there exists a transaction attribute

NEVER_REQUIRES_NEW

that would both guarantee there is no pre-existing transaction when a method is invoked, and then proceed to always create a new transaction ? But there is no such transaction attribute either in JEE 5, nor in Spring.

Here is what I think could achieve the NEVER_REQUIRES_NEW transaction semantics, assuming the service method name is M:

Split method M into M1 and M2, and move the implementation of M to M2;
M1 is a no-op annotated with the transaction attribute NEVER, whereas M2 is annotated with REQUIRES_NEW;
Provide a proxy service that always invokes M1 followed by M2, exposing in turn to the client only a service method M without any transactional annotation;

Now when client invokes M, the proxy would in turn invoke M1 that guarantees there is no pre-existing transaction, and then invoke M2 which would always create a new transaction, effectively resulting in NEVER_REQUIRES_NEW!

Is this yet another Transaction Design Pattern ? The use of NEVER could be forever changed :)

Visiting Every Permutation ?

2008-09-06T23:03:00.000-07:00

Given a set of objects, sometimes it's useful to find out all the permutation of these objects, and perform some action upon each permutation. The order of the permutation generation would preferably be in some natural order such as lexicographic i.e. the order they would appear if they were sorted numerically.

How would you go about writing such utility efficiently in Java ?

One possible answer:

public class Permutation<T> {
    public static interface Visitor<T> {
        /** Visits each permutation of objects. */
        public void visit(T[] entry);
    }
    private final T[] objects;
    private T tmp;
    private final Visitor<T> visitor;
    
    /**
     * @param objects set of n objects
     * @param visitor used to visit each permutation
     */
    public Permutation(T[] objects, Visitor<T> visitor) {
        this.objects = objects.clone();
        this.visitor = visitor;
    }
    
    public void compute() { doCompute(0); }
    
    private void doCompute(final int pos) {
        if (pos == objects.length) {
            visitor.visit(objects);
            return;
        }

        doCompute(pos+1);
        
        for (int i=pos+1; i < objects.length; i++) {
            swap(pos, i);
            doCompute(pos+1);
        }
        
        if (pos > 0)
            for (int i=pos+1; i < objects.length; i++)
                swap(i-1, i);
    }
    
    private void swap(int p1, int p2) {
        tmp = objects[p1];
        objects[p1] = objects[p2];
        objects[p2] = tmp;
    }
}

Demo:

Visitor<Character> visitor = new Visitor<Character>() {
    private Set<String> set = new HashSet<String>();

    @Override
    public void visit(Character[] entry) {
        String s = Arrays.toString(entry);
        set.add(s);
        System.out.println(set.size() + ": " + s);
    }
};
String s = "abc";
Character[] ca = new Character[s.length()];

for (int i = s.length() - 1; i > -1; i--)
    ca[i] = s.charAt(i);
new Permutation<Character>(ca, visitor).compute();

Would yield:

1: [a, b, c]
2: [a, c, b]
3: [b, a, c]
4: [b, c, a]
5: [c, a, b]
6: [c, b, a]

Visiting Every Combination ?

2008-09-02T23:22:00.000-07:00

Given a set of objects, sometimes it's useful to find out all the combination of these objects of a given size, and perform some action upon each combination. For example, given a set of letters "abcde", print out all the combination of 4 letters from the set.

How would you go about writing such utility efficiently in Java ?

One possible answer:

public class Combination<T> {
    public static interface Visitor<T> {
        /** Visits each k-combination of objects. */
        public void visit(T[] entry);
    }
    private final T[] objects; // Given set of objects
    private final T[] entry;   // each combination of size k
    private final Visitor<T> visitor;

    /**
     * @param objects set of n objects
     * @param k size of each combination
     * @param visitor used to visit each combination
     */
    public Combination(T[] objects, int k, Visitor<T> visitor) {
        this.objects = objects.clone();
        entry = Arrays.copyOf(this.objects, k);
        this.visitor = visitor;
    }

    public void compute() { doCompute(0, 0); }

    private void doCompute(int pos, int entryPos) {
        if (entryPos == entry.length) {
            visitor.visit(entry);
            return;
        }
        // (entry.length - entryPos) is the remaining size
        for (int i = pos, end = objects.length - (entry.length - entryPos) + 1; i < end; i++) {
            entry[entryPos] = objects[i];
            doCompute(i + 1, entryPos + 1);
        }
    }
}

Demo:

Visitor<Character> visitor = new Visitor<Character>() {
    private Set<String> set = new HashSet<String>();

    @Override
    public void visit(Character[] entry) {
        String s = Arrays.toString(entry);
        set.add(s);
        System.out.println(set.size() + ": " + s);
    }
};
String s = "abcde";
Character[] ca = new Character[s.length()];

for (int i = s.length() - 1; i > -1; i--)
    ca[i] = s.charAt(i);

final int size = 4;
new Combination<Character>(ca, size, visitor).compute();

Would yield:

1: [a, b, c, d]
2: [a, b, c, e]
3: [a, b, d, e]
4: [a, c, d, e]
5: [b, c, d, e]

Root Cause Java Quiz

2008-08-05T12:46:00.000-07:00

Can the following code leads to an endless loop ?

    public static Throwable getRootCause(Throwable t) {
        if (t == null)
            return t;
        Throwable cause = t.getCause();
        
        if (cause == null)
            return t;
        return getRootCause(cause);
    }

Answer:

Don't try this at home ;)

        Exception ex1 = new Exception("ex1");
        Exception ex2 = new Exception("ex2");
        ex1.initCause(ex2);
        ex2.initCause(ex1);
        getRootCause(ex1);

Java Enum Puzzler

2008-07-12T17:59:00.000-07:00

What does the following print ?

public enum FooEnum {
    FOO { @Override public void bar() {} };
    public abstract void bar();
    
    public static void main(String...args) {
        System.out.println(FOO.getClass().isEnum());
    }
}

Answer:

FOO is an enum value in FooEnum. The class of FOO must therefore be an enum, and it should print "true". Right ? If you give it a try, surprisingly it will print "false". Why ?

Peeking into the JDK source code of Class.java,

public boolean isEnum() {
    // An enum must both directly extend java.lang.Enum and have
    // the ENUM bit set; classes for specialized enum constants
    // don't do the former.
    return (this.getModifiers() & ENUM) != 0 && 
            this.getSuperclass() == java.lang.Enum.class;
}

Now if you tried to print out the super class of FOO.class, it would print FooEnum.class, rather than Enum.class. The comparison of the super class of FOO.class against Enum.class would therefore fail in the second condition of the return statement.

To me, this looks like a bug either in the javac compiler, or in the implementation of Class.isEnum().

Why is it probably a bug in the javac compiler ? Well, shouldn't the super class of FOO.class be Enum.class, instead of FooEnum.class ? (Special thanks to Dhanji R. Prasanna for pointing this out.)

Why is it probably a bug in Class.isEnum() ? Well, shouldn't it recursively check all the super classes of FOO.class for Enum.class, instead of just the direct super class ? And why does it need to compare the super class with Enum.class at all, when there is already the checking for the ENUM class modifier ?

What do you think ?

Update on 7/13/2008: Please vote for bug 6710708.

Dumping a JavaBean as name/value pairs ?

2008-07-11T03:11:00.000-07:00

Sometimes it's useful to deeply dump out the properties of a complex JavaBean as name/value pairs, perhaps for debugging purposes, even when none of the toString methods of the classes involved are defined. This is especially the case when the JavaBean classes are written by a third party.

Now how would you go about doing that ?

How about using the Jarkarta commons-lang's ToStringBuilder.reflectionToString method ? It doesn't cut it, as it relies on the toString method of the individual classes involved.

How about XMLEncoder or XStream ? They work pretty nicely. However, by default XStream generates not just the public properties but all other fields as well. In both cases, the generated XML would need to be further transformed into name/value pairs.

Another way I can think of is to take advantage of the latest BeanSourceHandler SPI as a side effect of performing a deep clone via the open-source library Beanlib (beanlib-3.3.0beta18). What do I mean ? Here is an example:

Object bean = ...
// Dump out the entire JavaBean
// when none of the toString methods are defined.
BeanReplicator.newBeanReplicatable(customTransformer()).replicateBean(bean);

private static BeanTransformerSpi customTransformer() {
    BeanTransformerSpi beanTransformer = BeanTransformer.newBeanTransformer();
    return beanTransformer.initBeanSourceHandler(new BeanSourceHandler() {
        public void handleBeanSource(Object fromBean, Method readerMethod, Object propertyValue) {
            System.out.println(
                String.valueOf(fromBean.getClass().getSimpleName() + "."
                + readerMethod.getName() + "=" + propertyValue));
        }
    });
}

Little Java Quiz - File loaded from classpath

2008-07-02T10:32:00.000-07:00

Given:

a file with a given name;
the file is located in the file system;
the file can be loaded via the classpath;

How can the code figure out the physical location (ie absolute path) of the file ?

(Don't peek if you want to give it a try!)

Answer:

    String filePath = Thread.currentThread()
                            .getContextClassLoader()
                            .getResource(filename)
                            .getFile();

Tomcat 5.5 SSL Programming Puzzle

2008-04-11T00:20:00.000-07:00

Assuming SSL client side authentication is enabled in Tomcat 5.5, how can a webapp go about retrieving the underlying client's X509 certificate of the SSL socket ?

Browsing through the Tomcat source code, such information can be found in the SSL session, which unfortunately seems totally unreachable from the servlet layer.

Well, thanks to reflection, below is one such solution. Do you know of a better one ?

    /** 
     * Returns the requester's X509 SSL certificate(s) of the given request;
     * or null if no such certificate can be determined. 
     */
    static X509Certificate[] getPeerCertificates(HttpServletRequest req) {
        // rip open the tomcat specific request object to retrieve the peer SSL cert(s)
        try 
        {   // Dig out the org.apache.catalina.connector.Request object
            Field f = req.getClass().getDeclaredField("request");
            f.setAccessible(true);
            Object catalinaConnectorRequest = f.get(req);
            
            // Dig out the org.apache.coyote.Request object
            // by invoking org.apache.catalina.connector.Request.getCoyoteRequest()
            Method getCoyoteRequestMethod = catalinaConnectorRequest.getClass().getMethod("getCoyoteRequest");
            Object coyoteRequest = getCoyoteRequestMethod.invoke(catalinaConnectorRequest);

            // Dig out the proper class loader
            Class coyoteRequestClass = coyoteRequest.getClass();
            ClassLoader classLoader = coyoteRequestClass.getClassLoader();
            
            // Dig out the ActionCode class loaded by the approprate class loader
            Class actionCodeClass = classLoader.loadClass("org.apache.coyote.ActionCode");
            
            // Refer to the ActionCode.ACTION_REQ_SSL_CERTIFICATE
            Field actionReqSslCertField = actionCodeClass.getDeclaredField("ACTION_REQ_SSL_CERTIFICATE");
            Object actionReqSslCert = actionReqSslCertField.get(null);
            
            // Invoke org.apache.coyote.Request.action(ActionCode.ACTION_REQ_SSL_CERTIFICATE, null)
            Method actionMethod = coyoteRequestClass.getMethod("action", actionReqSslCert.getClass(), Object.class);
            actionMethod.invoke(coyoteRequest, actionReqSslCert, null);
            
            // Dig out the SSLSupport class loaded by the approprate class loader
            Class sslSupportClass = classLoader.loadClass("org.apache.tomcat.util.net.SSLSupport");
            
            // Refer to the SSLSupport.CERTIFICATE_KEY
            Field sslSupportCertKeyField = sslSupportClass.getDeclaredField("CERTIFICATE_KEY");
            Object sslSupportCertKey = sslSupportCertKeyField.get(null);
            
            // Invoke org.apache.coyote.Request.getAttribute(SSLSupport.CERTIFICATE_KEY)
            Method getAttributeMethod = coyoteRequest.getClass()
                                                     .getMethod("getAttribute", sslSupportCertKey.getClass());
            return (X509Certificate[])getAttributeMethod.invoke(coyoteRequest, sslSupportCertKey);
        } catch(Throwable t) {
        }
        return null;
    }

It turns out there is a much simpler way to solve this problem. According to the spec (section SRV.4.7), if there is an SSL certificate associated with the request, it must be exposed by the servlet container to the servlet programmer as an array of objects of type java.security.cert.X509Certificate and accessible via a ServletRequest attribute of javax.servlet.request.X509Certificate.

Thanks to Mark Thomas for pointing this out.

On Frugality

2008-04-03T10:00:00.000-07:00

Be contra-variant in what you take, but covariant in what you give. In other words, take less and give more.

Tuning JVM with ICMS

2008-01-30T21:18:00.000-08:00

Some readings:

http://www.sun.com/bigadmin/content/submitted/cms_gc_logs.html
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html
http://java.sun.com/docs/hotspot/gc1.4.2/example.html
http://blogs.sun.com/jonthecollector/entry/when_the_sum_of_the

http://java.sun.com/j2se/1.5.0/docs/guide/vm/gc-ergonomics.html
http://performance.netbeans.org/howto/jvmswitches/index.html
http://java.sun.com/javase/6/docs/technotes/guides/vm/cms-6.html

http://java.sun.com/performance/reference/whitepapers/tuning.html
http://blogs.sun.com/watt/resource/jvm-options-list.html

Some JMX Quizzes

2008-02-15T15:43:00.000-08:00

Where can you find out all those Platform MBean Object Names ?
How would you connect via JMX with username and password programmatically ?

Some possible answers:

Where can you find out all those Platform MBean Object Names ?

java.lang.management.ManagementFactory

How would you connect via JMX with username and password programmatically ?

    Map<String,String[]> env = new HashMap<String,String[]>();
    env.put(JMXConnector.CREDENTIALS, new String[]{"username", "password"});
    final String url = "service:jmx:rmi://" + host + "/jndi/rmi://" + host + ":" + port + "/jmxrmi";
    JMXServiceURL jmxServiceUrl = new JMXServiceURL(url);
    JMXConnector conn = JMXConnectorFactory.connect(jmxServiceUrl, env);
    MBeanServerConnection mbsc = conn.getMBeanServerConnection();
    ...