Java 7 does not work on some older Linux platforms:

A good hint is

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6538311


Just search for the part with system-config-securitylevel.

I started to use CX.COM, which is a new online storage like Dropbox.




You can have a FREE account which gives you 10 GB of FREE storage which is twice as much as on Dropbox. The disadvantage: the background synchronization seems to be slower than Dropbox, but I can life with that. I don't care if it takes 2 or 2.5 days...

I use such free online services (there are many more than mentioned here) for transferring my files between several computers, and for backup of certain, incredibly important files.

I can recommend both :-)

My opinion about 'The Clean Coder'

There are already several reviews of Robert C. Martin's book 'The Clean Coder' out there, but I couldn't resist to write my own comments / thoughts about that book.

It is a very important book for software developers, even if it does not contain any new ideas at all.

The important point is that Mr. Martin emphasizes "professional" software development, and he wants us to behave and sell ourselves as professionals. That's quite OK for me, I like that, but I don't need to read a complete book for figuring this out:-)


Mr. Martin touches several topics about so-called professional software development like testing, estimating, collaborating, and so on.

A typical chapter consists of some stories of Mr. Martin's own experience as a programmer. Those stories usually show what went wrong, so that one can learn from them. After having read so many bad stories I started to wonder, if Mr. Martin ever had a successful software project, but let's assume so...

Then there are some instructions for developers what to do and what not.


If you are a not so much experienced software developer:

• Read it, learn it, try it, code it, quote it.

If you are an experienced software developer:

• This book  probably does not help you, it does not contain anything new, just old stuff, extended by unnecessary personal stories by Mr. Martin.

A ridiculously poor (aka uninformative) appendix mentions some 'tools' like continuous integration software.

Some hints for calculations with floating point numbers

This is an old posting from 2009 which I am publishing again.

Here are some (slightly simplifying) hints or rules for the usage of BigDecimal.

1. Use BigDecimal.valueOf(double) or new BigDecimal(String) to create BigDecimal objects.
   Never use new BigDecimal(double), unless you know what you are doing. Be aware that 0.1 is an infinite decimal number, 0.5 is not, so new BigDecimal(0.5) is fine, but not new BigDecimal(0.1). And if you do not want to think about the difference every time, do not use new BigDecimal(...) at all.
   
2. If you want to compare BigDecimal objects, be aware: equals() compares the value and the scale, that means 1.001 is not equal to 1.00100. Use signum() and compareTo().
   
3. Use setScale to round the BigDecimal value.
   
4. Use a Context for rounding.
   
5. Be aware that setScale or a division may throw an ArithmeticException, so always use a RoundingMode or a RoundingContext.
   

package testdrive;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertFalse;
import static org.junit.Assert.assertTrue;

import java.math.BigDecimal;

import org.junit.Test;



public class DoubleCalcTest
{

    @Test
    public void addDouble()
    {
        /**
         * This is actually a very old example which shows that calculations with double values can lead to unexpected
         * results.
         */
        double a = 0.1;
        double sum = 0;
        for ( int i = 0; i < 10; i++ )
        {
            sum += a;
        }
        // sum should be 1, but it isn't
        assertTrue( sum != 1 );
        /**
         * There is no exact binary representation for 0.1, so repeated calculations with 0.1 will probably have wrong
         * results.
         */
    }



    @Test
    public void createBigDecimalCorrectly()
    {
        /**
         * This shows the usage of the static valueOf method. In such a way, a BigDecimal object can be created from a
         * double value. Another possibility is the constructor with the String which is shown here just for fun. I would
         * recommend to always use the static valueOf method.
         */
        BigDecimal a = BigDecimal.valueOf( 0.1 );
        BigDecimal sum = new BigDecimal( "0" ); // Just to show this possibility.
        // OR: BigDecimal sum = BigDecimal.ZERO;

        for ( int i = 0; i < 10; i++ )
        {
            sum = sum.add( a );
        }
        BigDecimal expected = BigDecimal.valueOf( 1.0 );

        /**
         * If the two BigDecimal objects may have different scale, then use signum() and compareTo().
         */
        assertTrue( expected.signum() == sum.signum() );
        assertTrue( expected.compareTo( sum ) == 0 ); // == 0 means, they are equal.
    }



    @Test
    public void createBigDecimalInAWrongWay()
    {
        /**
         * Never use the constructor with double values, unless the binary representation of the double values is what you
         * want. So actually it is better to use the constructor with a String or the static value of method.

         * This example shows the problem with the constructor which has a double as parameter.
         */
        BigDecimal a = new BigDecimal( 0.1 );
        BigDecimal sum = new BigDecimal( 0.0 );
        for ( int i = 0; i < 10; i++ )
        {
            sum = sum.add( a );
        }
        BigDecimal expected = new BigDecimal( 1.0 );

        /**
         * The value of the expected variable (i.e. 1.0) is not the same as the value of the sum variable. The reason is
         * that there is no exact representation of 0.1 in the binary system, so the BigDecimal does not represent 0.1 but
         * something similar.
         */
        assertFalse( expected.equals( sum ) );

        /**
         * If the two BigDecimal objects may have different scale, then use signum() and compareTo().
         */
        assertTrue( expected.signum() == sum.signum() );
        assertTrue( expected.compareTo( sum ) != 0 ); // != 0 means, they are different.

        /**
         * A hint to JUnit:

         * 

         * If you use JUnit, then be aware that assertEquals does use the Number.longValue() method to compare BigDecimal
         * objects, so the result is often wrong. So please use the assertTrue or assertFalse methods.
         */
        assertEquals( expected, sum );
    }

}