Thursday, February 21, 2013

Few notes about Java clone() method

Did you know you can create new Java instance without constructor? That's right, and this feature is brought to you by the Java clone() method. I personally don't like to use it much because it has many pitfalls, and it feels very broken in many ways. You probably can write better "clone" by using copy constructor or a static copy factory methods.

Anyrate, here is a unit test that highlights few notes I have gathered about Java clone. Look for the "Note" comments below.

package atest;

import org.junit.Test;

import java.util.ArrayList;
import java.util.List;

import static org.hamcrest.Matchers.hasItems;
import static org.hamcrest.Matchers.is;
import static org.junit.Assert.assertThat;

public class CloneTest {
    @Test
    public void testFooClone() throws Exception {
        Foo a = new Foo();
        Foo b = a.clone();

        assertThat(a != b, is(true));
        assertThat(a.constructorCallsCount, is(1));
        assertThat(a.name, is("foo"));
        assertThat(b.constructorCallsCount, is(1)); // Note1: Wow, a new instance without calling constructor!
        assertThat(b.name, is("foo"));

        a.name = "fooX";
        assertThat(a.name, is("fooX"));
        assertThat(b.name, is("foo"));

        Foo2 c = new Foo2();
        c.ids.add("a");
        Foo2 d = c.clone();
        d.ids.add("b");

        c.ids.clear();
        c.ids.add("A");

        assertThat(c != d, is(true));
        assertThat(c.constructorCallsCount, is(2));
        assertThat(c.name, is("foo"));
        assertThat(d.constructorCallsCount, is(2));
        assertThat(d.name, is("foo"));

        assertThat(c.ids, hasItems("A"));
        assertThat(c.ids.size(), is(1));
        assertThat(d.ids, hasItems("a", "b"));
        assertThat(d.ids.size(), is(2));
    }

    /** A simple clone examples with simple type fields. */
    public static class Foo implements Cloneable {
        static int constructorCallsCount = 0;
        String name = "foo";
        public Foo() {
            constructorCallsCount++;
        }
        public Foo clone() {
            // Note2: Catch checked exception here so client or subclass doesn't need to.
            Foo result = null;
            try {
                result = (Foo)super.clone();
            } catch (CloneNotSupportedException e) {
                throw new RuntimeException("Unable to clone.", e);
            }
            return result;
        }
    }

    /** A clone example that needs to fix field afterward super.clone(). */
    public static class Foo2 extends Foo {
        List<String> ids = new ArrayList();
        public Foo2 clone() {
            Foo2 result = (Foo2)super.clone(); // Note3: Some how, super clone will auto return the correct type!
            result.ids = new ArrayList(ids);   // Note4: need to fix non-simple field.
            return result;
        }
    }
}

Monday, February 4, 2013

Learn how to grep by context will give you better result

I learned that grep command supports few options called "context" searching. Basically it can print lines around the matching string! For example, you can use this feature to perform a quick Java threads stack analysis like this (assuming you have a java process PID=12345).


bash> jstack 12345 | grep --color 'State: BLOCKED' -B 1
"A-Bad-Boy-Thread" prio=5 tid=0x00007fcfbc895800 nid=0xcd03 waiting on condition [0x00000001657cb000]
   java.lang.Thread.State: BLOCKED (on object monitor)

See, without the "-B 1" option, which show one line before match, you won't know which name of the tread that's acting up! Now isn't that a gem!

You may also use "-A 5" to see 5 more lines after the match. Or you may use the "-C 5" to see 5 lines before and after the match.

PS: There is nothing wrong with a "BLOCKED" thread in Java, however if you got one that won't go away, then it's a good indicator that something is fishy about that thread in your application; because in a well designed app, threads should be in BLOCKED state as briefly as possible. Read the javadoc on java.lang.Thread.State for more details.

Tuesday, January 29, 2013

Fast shell utilities to report Maven's unit tests results

I would like to share couple shell utilities that I have collected. These are for fast Maven multi modules reporting from your unit tests results, without having you to run entire Maven site reports, which can take a LONG time to generate if you have a large project! They should work on Linux or Window's Cygwin shell.

# Show failed tests among all the surefire results.
function failedtests() {
    for DIR in $(find . -maxdepth 3 -type d -name "surefire-reports") ; do
        ruby -ne 'puts "#$FILENAME : #$&" if $_ =~ /(Failures: [1-9][0-9]*.*|Errors: [1-9][0-9]*.*)/' $DIR/*.txt
    done
}

# Show the top tests that took the longest time to run from maven surefire reports
function slowtests() {
    FILES=''
    for DIR in $(find . -maxdepth 3 -type d -name "surefire-reports") ; do
        FILES="$FILES $DIR/*.txt"
    done
    head -q -n 4 $FILES \
        | ruby -ne 'gets; print $_.chomp + " "; gets; print gets' \
        | ruby -ane 'printf "%8.03f sec: ", $F[-2].to_f; puts $_' \
        | sort -r \
        | head -10
}

When developing with Maven, you often want to see a summary of failed tests, and you want those surefire TXT file content to see what's going on. The failedtests function will give you a list of all the failed tests filenames in all modules; and then you can cat each one to investigate.

With slowtests function you may quickly see the top 10 most time consuming tests from your project!

Enjoy!


Updated (2013/01/30)

I found out that the head command on MacOSX doesn't have the "-q" option and it always prints the "==> filename <==" lines. How annoying! To work around this, you can use this ruby command replacement instead:
# Replace this
head -q -n 4 $FILES \

# With this
ruby -e 'ARGV.each{ |n| File.open(n) {|f| 4.times{ puts f.readline}} }' $FILES \

It's a tad longer, but it's PORTABLE!

Saturday, January 12, 2013

Apache Tapestry 5 makes Java web development easy

I went through the Apache Tapestry 5 tutorial today and found it surprisingly easy to use. The two most productive features I love are auto class reloading and rich built-in components! I can edit the model/controller/view in a java IDE that auto compiles upon file save, and then reload browser to see immediate changes. I think any Java web framework should have this feature in order to be count as productive. (Yes there is JRebel, but it's commercial, and nothing more simpler than a framework supports it directly. Well to be fair JRebel is much more advance and richer in support your Java classes reloading, however for purpose of web dev, Tapestry seems to provide a sweet spot and boot productivity tremendously.)

I was intrigued enough to continue reading the rest of their documentation for advance usage and architecture design. I love simple and yet productive libraries/framework design principles, and I think Tapestry fits into that category. Their documentation is rich and well organized. I browsed their forums and user communities and they seem to be active and plenty of usage in the field. I also found these jumpstart examples to be extremely helpful.

I am happy that I spent the time in learning this framework. I think it makes web development easy, fast and fun to work with. If you haven't tried it before, or have not tried their latest version 5 lately, I would highly recommend you to give it a try.

Tuesday, January 1, 2013

Java implementation of String#next() successor

I've found the Ruby's String#next() or #succ very useful and productive, specially when generating data for testing. Here is what the Ruby doc says:

succ -> new_str

next -> new_str

Returns the successor to str. The successor is calculated by incrementing characters starting from the rightmost alphanumeric (or the rightmost character > if there are no alphanumerics) in the string. Incrementing a digit always results in another digit, and incrementing a letter results in another letter > of the same case. Incrementing nonalphanumerics uses the underlying character set’s collating sequence.

If the increment generates a “carry,” the character to the left of it is incremented. This process repeats until there is no carry, adding an additional > character if necessary.

"abcd".succ        #=> "abce"
"THX1138".succ     #=> "THX1139"
"<<koala>>".succ   #=> "<<koalb>>"
"1999zzz".succ     #=> "2000aaa"
"ZZZ9999".succ     #=> "AAAA0000"
"***".succ         #=> "**+"

So when I saw Groovy actually has provided a String extension #next() method, I was happy to try it out. But then I was quickly disappointed when the behavior is very different. The Groovy version is very simple and actually not very productive since it simply loop through Character set range in incrementally (including non-printable characters blindly!). The Ruby's version, however, is much more productive since it produce visible characters. For examples:

bash> ruby -e 'puts "Z".next()'
AA
bash> groovy -e 'println("Z".next())'
[

I wish Groovy version would improve in future as it's not very useful at the moment. Just for fun, I wrote a Java implementation version that mimics the Ruby's behavior:

And here is my unit test for sanity check:

Thursday, December 27, 2012

Reading https url from a self-signed cert

Groovy has made fetching data from URL a snap:
println(new URL("http://www.google.com").text)
But have you ever try to get data from an https of an site that's using a self signed certificate? A browser will prompt you a risk warning, but it let you trust it and still continue. But it's much more hassle if we want to fetch the data programmatically. For example, try fetching https://www.pcwebshop.co.uk and you will see that it failed miserably:
Caught: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1762)
    at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:241)
    at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:235)
    at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1206)
    at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:136)
    at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
    at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:958)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1203)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1230)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1214)
    at test.run(test.groovy:2)
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:126)
    at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:209)
    at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:249)
    at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1185)
    ... 8 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    ... 12 more
This is due to Java API won't let you get data if your certs is not in the keystore or "trusted". Now if you have your own testing site and did a self-signed like above, then sure you just want to trust it temporary and simply want to fetch the data. However configuring the Java API to do such simple task is a nightmare.
Today, I found a library that allow you to perform exactly this: https://github.com/kevinsawicki/http-request Trying this out using Groovy is pretty sweet:
@Grab('com.github.kevinsawicki:http-request:3.1')
import com.github.kevinsawicki.http.*
def req = HttpRequest.get("https://www.pcwebshop.co.uk")
req.trustAllCerts()
req.trustAllHosts()
println(req.body())
And Voila! We read the URL context without the pesky exception. This http-request is awesome! Now I wish JDK let you do simple thing like this. This is extremely useful for testing.

Friday, December 21, 2012

A strange case of Java generic and inheritage parameter passing

I came a cross some strange Java code and I would like to share it here. Take a look few of classes I have here:

// file: AFoo.java
package atest.deng;
public abstract class AFoo<T> {
}

// file: Foo.java
package atest.deng;
public class Foo extends AFoo<String> {
}

// file: FooProcessor.java
package atest.deng;
public class FooProcessor<T> {
    public void process(Class<AFoo<?>> cls) {
        System.out.println(cls);
    }
}

// file: FooMain.java
package atest.deng;
public class FooMain {
    public static void main(String[] args) {
        new FooProcessor().process(Foo.class);
    }
}

bash> mvn compile
bash> [INFO] BUILD SUCCESS

I tried this with JDK6 + Maven and it compiles without problem. But try to remove the <T> part from FooProcessor and it will fail to compile!

// file: FooProcessor.java
package atest.deng;
public class FooProcessor {
    public void process(Class<AFoo<?>> cls) {
        System.out.println(cls);
    }
}

bash> mvn clean compile
bash> [ERROR] java-demo\src\main\java test\deng\FooMain.java:[4,26] process(java.lang.Class<atest.deng.AFoo<?>>) in atest.deng.FooProcessor cannot be applied to (java.lang.Class<atest.deng.Foo>)

Without the <T> the code won't compile, and yet we are not even using it in this case. How and why <T> affects the method parameters invocation?

Now, we can improve the FooProcessor in this way so that the presence of <T> doesn't have any affect.

package atest.deng;
public class FooProcessor {
    public void process(Class<? extends AFoo<?>> cls) {
        System.out.println(cls);
    }
}

That's a more proper way to write the generic parameter anyway. But despite a better solution, the puzzle is that the original code compiled under the compiler, but only with the <T> presented, and yet it's not used. Wouldn't you consider this as a Java compiler bug?