Pages

Sunday, October 30, 2011

Inject in toInstance binding

With Guice it is extremely easy to add to injector self-constructed beans. But what was not very intuitive for me is that various inject annotations in these beans will have their influence on the state of the bean. Here is very simple illustration to this fact:

package com.sopovs.moradanen;

import javax.inject.Inject;

import com.google.inject.Binder;
import com.google.inject.Guice;
import com.google.inject.Injector;
import com.google.inject.Module;

public class ToInstanceTest {
    public static void main(String[] args) {
        Injector injector = Guice.createInjector(new Module() {
            @Override
            public void configure(Binder binder) {
                binder.bind(String.class).toInstance("hello");
                binder.bind(Foo.class).toInstance(new Foo());
            }
        });
        Foo foo = injector.getInstance(Foo.class);
        System.out.println(foo.value);
    }

    private static class Foo {
        @Inject
        String value;
    }
}
The output of this java program is "hello". At first I was really surprised.

Saturday, October 29, 2011

Synchronized vs atomic

In a very good book Java Concurrency in Practice one of the first example is about generating sequence of unique numbers. To ways of making it thread-safe are mentioned - using synchronized method and using internally atomic object. Here is another little benchmark, this time - comparing these approaches. The result can be seen from this chart:

And here is the code, that I used to make data for it:

Thursday, October 13, 2011

Synchronization on instance vs static method

Simple the difference is that synchronizing on instance method is like writing synchronized (this) and synchronizing on static method is like writing synchronized (FooBar.class).
If you want not so simple explanation, here it is:

ConcurrentModificationException in the nutshell


package com.sopovs.moradanen;

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

public class ConcurrentModificationExceptionTest {

    public static void main(String[] args) {
        List<String> list = new ArrayList(Arrays.asList("first"));
        for (String el : list) {
            list.add("second");
        }
    }
}
Results in


Exception in thread "main" java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:819)
at java.util.ArrayList$Itr.next(ArrayList.java:791)
at com.sopovs.moradanen.ConcurrentModificationExceptionTest.main(ConcurrentModificationExceptionTest.java:11)


Update: This may look strange, though...

ArrayList<String> list = new ArrayList<String>(Arrays.asList("foo", "bar"));
for (String el : list) {
    //Capacity will not be increased, but iterator will fail...
    list.ensureCapacity(1);
}

Saturday, October 8, 2011

ForkJoin factorial calculation

Several months ago I wrote a multithreaded factorial method.  It was very simple from the point of view of the underlying technology, but not so trivial from the point of view of synchronizing threads. It used simple start() and join() methods that are available since the Java 1.0 And than I thought that with all the power of java I can improve it. So i used the ThreadPoolExecutor - a piece of technology from the Java 5 and really improved - here is my post about multithreaded factorial using TreadPoolExecutor.

But Java 5 is a bit old now. And this year the Java 7 has been released! So here is the new version - using the new ForkJoin Framework available in it. Actually when I started writing this simple piece of code is didn'nt think that the result can be like that. I thought that all the power of my 4-core processor was already utilized by the variant with the ThreadPoolExecutor and considered this new method only as an exercise on the new API. I previewed that new version may be simpler as this is one of the stated goals of ForkJoin Framework and it is. But the actual performance increase was absolutely unforeseen by me.

So no more jabber, here are the results:

21 seconds for ForkJoin
27 seconds for ThreadPoolExecutor

Here is the code:


    private static BigInteger factFjPool(int input, int numThreads)
            throws InterruptedException, ExecutionException {
        ForkJoinPool forkJoinPool = new ForkJoinPool(numThreads);
        ForkJoinTask<BigInteger> future = forkJoinPool.submit(new FactorialRecursiveTask(1, input + 1));
        return future.get();
    }

    private static class FactorialRecursiveTask extends RecursiveTask<BigInteger> {
        private static final long serialVersionUID = 1L;

        private static final int THRESHOLD = 1000;

        private final int lo, hi;

        public FactorialRecursiveTask(int lo, int hi) {
            this.lo = lo;
            this.hi = hi;
        }

        @Override
        protected BigInteger compute() {
            if (hi - lo < THRESHOLD) {
                BigInteger result = BigInteger.valueOf(lo);
                for (int i = lo + 1; i < hi; i++) {
                    result = result.multiply(BigInteger.valueOf(i));
                }
                return result;
            } else {
                int mid = (lo + hi) >>> 1;

                FactorialRecursiveTask f1 = new FactorialRecursiveTask(lo, mid);
                f1.fork();
                FactorialRecursiveTask f2 = new FactorialRecursiveTask(mid, hi);
                return f2.compute().multiply(f1.join());
            }
        }
    }

I've tried to improve the previous version using other amount of threads, since this version obviously uses division into mush smaller sub-tasks, but to no result. Maybe I used wrong BlockingQueue<Runnable>, but this may be regarded as the simplicity of using this API. And definitely ForkJoinFramework is superior here, since not only decision about which Queue to use is not needed but also the division into sub-tasks is much simpler.

As usual the full code for this example may be found on github.

Monday, September 19, 2011

MVP plus UiBinder example

Here you may read official google documentation for putting together MVP pattern promoted by Google for GWT development and UiBinder for xml declarative UI development for GWT. However, the example for download on this page is totally broken.

It took some time from me to fix bugs, do those features and refactorings in the source that were left undone. Here are changes to it that I made:
1. Eclipse configuration was added (.project, .classpath, .settings). GWT 2.4 and 2.4 Google
plugin were used.
2. Proper history support for editing contacts was added (ability to move back and forward
in browser to editing particular contacts, that is absent in both 1st and 2nd original examples
for MVP).
3. Black magic of native HTML for table was replaced with binded FlexTable for ContactsView
4. EditContactsView was implemented with UiBinder as well.
5. EventBus instead of non-recommended to this purpose HandlerManager was used (Such usage of HandlerManager was normal in the previous versions of GWT, but now is deprecated).
6. Code cleanup (several bugs were fixed, unused third domain object Address was removed, etc.)

You may found this fixed version of example on github.
If you are not familiar with git - just download zipped archive or a tarball - what is more appropriate for your OS and import it to Eclipse as an existing project.

Thursday, July 21, 2011

Multithreaded factorial with ThreadPoolExecutor

In the previous post I have written a multithreaded factorial. It was not really good, because last one of the worker threads worked significantly longer than the first one. Fortunately we are leaving in 2011 and Java 1.5 was released so long time ago. The solution is simple - do not create 4 threads of the 4 virtual cores processors. Create really many threads and let the standard concurrent library execute them all. So ok, here is the code for this:

    private static BigInteger factMtExecutor(int input, int numThreads)
            throws InterruptedException, ExecutionException {
        FactCallable[] workers = new FactCallable[100];
        for (int i = 1; i <= 100; i++) {
            int start = i == 1 ? 1 : (input / 100 * (i - 1)) + 1;
            int end = i == 100 ? input : input / 100 * i;
            workers[i - 1] = new FactCallable(start, end);
        }

        ThreadPoolExecutor executor = new ThreadPoolExecutor(numThreads,
                numThreads, 0, TimeUnit.SECONDS,
                new LinkedBlockingQueue<Runnable>());

        List<Future<BigInteger>> futures = executor.invokeAll(Arrays
                .asList(workers));
        BigInteger result = BigInteger.valueOf(1L);
        for (Future<BigInteger> future : futures) {
            result = result.multiply(future.get());
        }

        return result;
    }

    private static class FactCallable implements Callable<BigInteger> {
        private final int from;
        private final int to;

        public FactCallable(int from, int to) {
            this.from = from;
            this.to = to;
        }

        @Override
        public BigInteger call() throws Exception {
            BigInteger result = BigInteger.valueOf(from);
            for (int i = from + 1; i <= to; i++) {
                result = result.multiply(BigInteger.valueOf(i));
            }
            return result;
        }
    }
And the result comparing to the previous version:
35 seconds for simple start/join
25 seconds for ThreadPoolExecutor

And the second time, swapping the order of execution:
29 seconds for ThreadPoolExecutor
38 seconds for simple start/join
Full code for comparison may be found on github.

Sunday, July 3, 2011

Multithreaded factorial

Update: the follow up post gives another version, that lacks the drawback of unequal load on processor cores.

There is a very good blog post about how to write the factorial method in Java (really it is not about righting factorial). However, even in this master peace;-) there is no multi-threaded factorial. So here it is.
There are some problems with it. The most significant is that multiplying all the BigIntegers from 1 to 50000 is much less heavy job for the computer, than multiplying all BigIntegers from 50001 to 100000. So the the amount of work that is done by each worker-thread is not equal. But investigation on how this may be resolved in a common way is much harder problem, than just writing what I am publishing here. Maybe I'll do it in the other post.

package com.sopovs.moradanen;

import java.math.BigDecimal;
import java.util.concurrent.TimeUnit;

import junit.framework.Assert;

import org.junit.Test;

public class FactorialTest {

    private static final int INPUT = 203457;

    @Test
    public void test() throws InterruptedException {
        BigDecimal fact1, fact2;
        {
            long start = System.nanoTime();
            fact1 = fact(INPUT);
            long end = System.nanoTime();
            System.out.println(TimeUnit.SECONDS.convert(end - start,
                    TimeUnit.NANOSECONDS) + " seconds for 1 thread");
        }
        {
            long start = System.nanoTime();
            fact2 = factMt(INPUT, 4);
            long end = System.nanoTime();
            System.out.println(TimeUnit.SECONDS.convert(end - start,
                    TimeUnit.NANOSECONDS) + " seconds for 4 threads");
        }
        Assert.assertEquals(fact1, fact2);

    }

    private static BigDecimal fact(int input) {
        BigDecimal result = BigDecimal.valueOf(1);
        for (int i = 1; i <= input; i++) {
            result = result.multiply(BigDecimal.valueOf(i));
        }
        return result;
    }

    private static BigDecimal factMt(int input, int numThreads)
            throws InterruptedException {
        BigDecimal result = BigDecimal.valueOf(1);
        Thread[] threads = new Thread[numThreads];
        FactComputer[] workers = new FactComputer[numThreads];
        for (int i = 1; i <= numThreads; i++) {
            int start = i == 1 ? 1 : (input / numThreads * (i - 1)) + 1;
            int end = i == numThreads ? input : input / numThreads * i;
            workers[i - 1] = new FactComputer(start, end);
            threads[i - 1] = new Thread(workers[i - 1]);
        }

        for (int i = 0; i < numThreads; i++) {
            threads[i].start();
        }

        for (int i = 0; i < numThreads; i++) {
            threads[i].join();
        }
        for (int i = 0; i < numThreads; i++) {
            result = result.multiply(workers[i].result);
        }
        return result;
    }

    private static class FactComputer implements Runnable {
        BigDecimal result;
        private final int from;
        private final int to;

        public FactComputer(int from, int to) {
            this.from = from;
            this.to = to;
        }

        public void run() {
            result = BigDecimal.valueOf(from);
            for (int i = from + 1; i <= to; i++) {
                result = result.multiply(BigDecimal.valueOf(i));
            }

        }
    }
}
Here is the result in System.out:
56 seconds for 1 thread
26 seconds for 4 threads
I have written it as the unit test to be sure that at least this simplistic distribution of work between threads has no bugs (I tested it with different values of INPUT). I think it is obvious from this code that I run it on the 4-core processor. Actually on the 2-core but with hyper-threading enabled.

Tuesday, June 14, 2011

Three IoC frameworks with JSR-330 annotations

So this post - is very simple illustration of how to make a dependency-injected application with one of three options:
All of them have slightly different goals, but in some ways all of them can handle beans annotated with the annotations from the JSR-330 (Dependency Injection for Java) standardization effort.

Thursday, June 2, 2011

ContainsAny method from apache commons

There was and there is now such method in Apache Commons Collections to define is there any single intersection between two collections. In the version 2.* it was:


  public static <E> boolean containsAny1(Collection<E> collection, Collection<E> elements) {
    for (E e : elements) {
      if (collection.contains(e)) {
        return true;
      }
    }
    return false;
  }
I have added "1" to the name to distinguish.

And in version 3.* it was optimized and now looks like this:

  public static <E> boolean containsAny2(final Collection<E> coll1, final Collection<E> coll2) {
    if (coll1.size() < coll2.size()) {
      for (Iterator<E> it = coll1.iterator(); it.hasNext();) {
        if (coll2.contains(it.next())) {
          return true;
        }
      }
    } else {
      for (Iterator<E> it = coll2.iterator(); it.hasNext();) {
        if (coll1.contains(it.next())) {
          return true;
        }
      }
    }
    return false;
  }
Here is a benchmark, of whether this optimization was worth doing (omitting methods themselves):

Friday, April 29, 2011

How to change sid of Oracle Express database

No way.

Not symmetric equals after overriding

There is really cool tool FindBugs and recently I found that it can discover (and discovered such a situation in my experience) broken symmetry for equals method when overriding it. So this is just a little example of this bug. (HashCode method is generated and I assume it to be all right).

Thursday, April 7, 2011

Netbeans using checkstyle configuration for formatter

What is cool about Eclipse - is the the huge variety of plugins that are available to improve it functionality. What is cool about Netbeans - is the awesome default set of plugins that is available right after the short installation procedure. For example maven support - it is out there in Netbeans by default, and after copying Eclipse (installation is the simplest possible in this case) in the right folder you should wait a rather long time for installation of m2eclipse and all other plugins that are absolutely necessary for work. This includes even SVN, mercurial and other version control systems support. Except CVSm that is rather outdated and I don't know who else except legacy systems and some weird guys (look at the date!) use it.

Ok, back to maven support. The really cool thing that I have just discovered in Netbeans is that even without installing SQE plugin (as far as I know the best plugin for checkstyle support in Netbeans, and probably for FindBugs and PMD too, but still not so cool as the checkstyle plugin for Eclipse) checkstyle configuration maybe partially used by default.

So, how it works. Looking in the formatter preferences for a maven project I found there the following:
Use Checkstyle Rules For Java Formatting option.
The following Checkstyle rules are recognized and used when the maven-checkstyle-plugin is configured in the project:
I have added links to descriptions of these checks on the official checkstyle site. Another cool thing is the button Generate POM Section. It will create the following piece of default configuration for maven-checkstyle-plugin in the pom.xml of the project
<reporting>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-checkstyle-plugin</artifactId>
        <configuration>
          <configLocation>config/sun_checks.xml</configLocation>
        </configuration>
      </plugin>
    </plugins>
</reporting>

Not so cool thing here is that activating this option is possible only for a single project and not for all projects... It will actually create (if it wasn't created already) the nb-configuration.xml file with this string:
<netbeans.checkstyle.format>true</netbeans.checkstyle.format>
So the formatter preferences are specific to the project and in case you decide to from now and then put a newline before the starting curly brace of the method body you should update tens of your projects... Not very convenient.

Another thing that may cause problems is that with transition to maven3 (and actually this maven version is bundled with the Netbeans 6.9.1) the config for maven-checkstyle-plugin should be placed in build section of the pom.xml, but not in the reporting section, since starting from maven3 configs of reporting do not affect the build process.
But nonetheless the direction of NetBeans is really cool.

Friday, March 25, 2011

Load factor for HashSet with contains operation

Update: This post really contains zero valuable information and is left here merely as a memorial to my stupidity.

In previous post I have measured the performance of HashSet with various load factors and initial capacity on the add operation. But the often case is that the most common operation on the set is checking whether an element contains in the set. So without much comments - another silly bench:

Load factor for HashSet with add operation

Update: This post was written when I was young and stupid. It is a try of investigation of the impact of the load factor on the speed of creation of HashSet without taking into account memory usage or any other characteristics of the resulting set. If you really need some theory behind all this - refer to Wikipedia or any book on the algorithms. And if you need this for some practise I'd suggest to just use excellent Guava library and methods for creating Sets and Maps in particular.

Load factor, initial size... only two parameters that controls the HashSet, but it is not very intuitive how to use them. So here is the small benchmark on adding the elements to HashSet. (The same may be applied to the HashMap I think, since the data structure that is used internally in the HashSet is: private transient HashMap map;).

Collisions of hashcodes - much more real than an md5 collision

So okay, hashcode is int and so there are only 4294967296 distinct hashcodes. It is not a little number, but in modern systems there could be definitely much more objects.

In a very good book by Joshua Bloch I have read that there is a probability that two consequently created objects will have an equal system identity hashcode. Actually from the time of publishing that book major version of Java was released and the situation has improved dramatically. But still 232 is a very little number for objects. And still two consequently created objects may have an equal identity hashcode:
  private static final int SIZE = 500000000;

  public static void main(String[] args) {
    int count = 0;
    for (int i = 0; i < SIZE; i++) {
      if (new Object().hashCode() == new Object().hashCode()) {
        count++;
      }
    }
    System.out.println(count + " of " + SIZE + " consequently created pairs of objects had equal hashcodes");
  }

On my machine that produced the following output:
16 of 500000000 consequently created objects had equal hashcodes