@Override specification changes in Java 6

Between Java 5 and Java 6 changes to the specification of @Override have been made. In Java 6 it is possible to add the @Override annotation to methods that implement methods of an interface which is not allowed in Java 5.

I noticed the difference when a friend told me that he had to remove all the @Override annotations to make his Java 6 project compile with Java 5.

The interesting thing is that there is no documentation about this change. The API specification of @Override is exactly the same in both Java versions. I found out that this was forgotten by Sun developers. Peter, a former developer at Sun, calls it the @Override Snafu.

Ten years of “mobility”

Nearly ten years ago I bought my first mobile phone. I will take this anyversary as a reason to write a small sumary about all the phones I had within the last decade.

samsungAugust 1998 – Samsung SGH
My first mobile phone. I bought this one with a prepayd card called B-Free from Mobilkom Austria. In this time there were not many phones around and most of them were Nokia (the better ones) or Alcatel (the cheap ones). My Samsung was special and I liked it a lot. It was very “american” because of its flip and the telescope antenna. It was a good companion while I had to do my military service.

nokia6150April 1999 – Nokia 6150
With buying the Nokia 6150 I signed my first mobile phone contract with A1 Mobilkom Austria. The 6150 was THE state of the art Nokia phone. It had a very long lasting battery and cool new features like T9 for text messages. I was very sad when it died because it fell into the pool while it was in my bermuda short in the summer of 1999.

nokia6110September 1999 – Nokia 6110
Because my Nokia 6150 had gone so young and unexpected I had no money to afford a new one and so I assembled a working Nokia 6110 out of two damaged 6110 and my wet 6150. I heard a about a new revolutionary phone from Nokia coming out in late 1999 and so I decided to wait for it.

nokia7110January 2000 – Nokia 7110
I did a lot for getting this phone: searching web sites, forums and shops, phoning around, writing mails. Finally I found a vendor only some kilometers away. I jumped into my car and bought the phone for 7500 Austrian Schilling (which was quite a lot of money for a student like me). The phone was worth it: The cool slider that snapped open when clicking the button on the back of the phone, the big display, the WAP browser …

nokia6210August 2001 – Nokia 6210
My 7110 was getting old and my service provider A1 made me a nice offer – so I switched to this one. I was a lot smaller and it had no antenna so the form factor was a lot better. The display was a bit smaller and there were no new features – at least none I remember.

nokia7650November 2002 – Nokia 7650
Compared to my last phone, the 6210, this one was a huge step into the future. It was the first Nokia phone with a built in camera and Symbian OS. I remember installing a lot of applications on it and using it as phone and PDA. I sold my Sony Clie. The phone was able to run Doom and a lot other games. The only disadvantage this phone had was the short battery lifetime.

p800May 2003 – SonyEricsson P800
After being convinced of the Symbian OS this phone was the clear successor of the 7650 for me. It was equipped with a touch screen, a removable flip, a camera and huge 208 x 320 pixel screen. It even was able to load a MemoryStick Duo for storing music, pictures and even videos. It was the first phone I had that was able to play not only polyphone ringtones but real music from mp3 files. There was no mobile phone on the market at that time that could do more. The P800 was my ultimate swiss army knife for a long time. I could do all the PIM tasks and even send and receive emails.

p910September 2004 – SonyEricsson P910
I was very happy with my P800 but got a good chance to switch to its successor model the P910 so I did it after using the P800 for over 15 months (quite a long time if you consider the rest of my list). The P910 was a big improvement of the P800 in terms of operating system and hardware. It had just a few features but it was manufactured a lot better.

bb7290February 2005 – BlackBerry 7290
I remember the day my company gave me my first BlackBerry very well. At first I did not want to exchange my P910 for this strange looking calculator. I tried a long time to get the BlackBerry connect software running on my P910 but it was not possible. After some frustrating weeks I gave the 7290 a try – and started to love the BlackBerry. It just worked. I soon realized the advantage of not having to synchronize your device every day – because it is in sync. Reading and writing emails on a BlackBerry could not be better. The 7290 was the ultimate productivity tool.

bb8700October 2006 – BlackBerry 8700
With the 8700 the BlackBerry experience even got better. The device was a lot faster than the 7290 and a lot of third party applications started to spread. It looked a lot less like a business tool and the usability was improved a bit. What still amazes me about the BlackBerry is how perfect the system works. If my administrator would not change the enterprise solution system that often I would have no troubles with the device.

bb8300June 2007 – BlackBerry 8300
The BlackBerry started to beat the P800 and P910 devices in all areas. With the built in 2 megapixel camera and the multimedia player it is my favorite gadget at the moment. A 4 gigabyte micro SD card provides enough space for music, photos and videos. I got a lot of additional applications installed on it: Google Maps, Instant Messengers, Opera Mini, Games, Password Safe, … I would not even exchange it against an iPhone.

For the moment I am definitively hooked to the BlackBerry. I just can not wait for the next generation and what new features they will introduce.

BigDecimal and JDBC since Java 5.0

In one of my projects I came across an interesting problem with BigDecimal values. The project uses a persistence framework to persist Java objects into an Oracle 9i database with the Oracle JDBC driver 10.2.0.3.0. I could also reproduce this problem with Hibernate on a Microsoft SQL Express 2005 database using the Microsoft JDBC driver 1.2.

The problem was that sometimes when I tried to store objects containing BigDecimal values the following exception was thrown and the object could not be persisted:

[2008-01-02 23:02:36] [main] WARN org.hibernate.util.JDBCExceptionReporter - SQL Error: 8114, SQLState: S0005
[2008-01-02 23:02:36] [main] ERROR org.hibernate.util.JDBCExceptionReporter - Error converting data type nvarchar to decimal.

Converting nvarchar to decimal? I am trying to insert a number into the database and the JDBC driver tells me he is not able to convert a nvarchar (text) to a decimal?

After doing some search I found out that this problem might have something to do with a change made in Java 5.0. I found this blog post and this article writing about similar errors. The implementation of BigDecimal.toString() changed in Java 5.0 and there is a new method toPlainString() doing what toString() did before.

The following code example

System.out.println(new Double(12500000).toString());
final BigDecimal value = new BigDecimal(new Double(12500000).toString());
System.out.println(value.toString());
System.out.println(new BigDecimal(value.toPlainString()).toString());

executed with Java 5.0 results in the following console output:

1.25E7
1.25E+7
12500000

Whereas executed with Java 1.4 it generates another output:

1.25E7
12500000

Some JDBC driver use the toString() method to get the value of a BigDecimal and if it has to many decimal positions you may run into this problem.

In my case the solution was to do all the calculations with BigDecimal values and givenMathContext and RoundingMode instead of creating BigDecimal values out of Double values from calculations.

BigDecimal value = new BigDecimal("100");
BigDeciaml result = value.divide(new BigDecimal("3"), 2,
                      BigDecimal.ROUND_HALF_UP);

instead of

BigDeciaml result = new BigDecimal(100.0 / 3.0);

BigDecimal and JDBC since Java 5.0

java logoIn one of my projects I came across an interesting problem with BigDecimal values. The project uses a persistence framework to persist Java objects into an Oracle 9i database with the Oracle JDBC driver 10.2.0.3.0. I could also reproduce this problem with Hibernate on a Microsoft SQL Express 2005 database using the Microsoft JDBC driver 1.2.

The problem was that sometimes when I tried to store objects containing BigDecimal values the following exception was thrown and the object could not be persisted:

[2008-01-02 23:02:36] [main] WARN org.hibernate.util.JDBCExceptionReporter - SQL Error: 8114, SQLState: S0005
[2008-01-02 23:02:36] [main] ERROR org.hibernate.util.JDBCExceptionReporter - Error converting data type nvarchar to decimal.

Converting nvarchar to decimal? I am trying to insert a number into the database and the JDBC driver tells me he is not able to convert a nvarchar (text) to a decimal?

After doing some search I found out that this problem might have something to do with a change made in Java 5.0. I found this blog post and this article writing about similar errors. The implementation of BigDecimal.toString() changed in Java 5.0 and there is a new method toPlainString() doing what toString() did before.

The following code example

System.out.println(new Double(12500000).toString());
final BigDecimal value = new BigDecimal(new Double(12500000).toString());
System.out.println(value.toString());
System.out.println(new BigDecimal(value.toPlainString()).toString());

executed with Java 5.0 results in the following console output:

1.25E7
1.25E+7
12500000

Whereas executed with Java 1.4 it generates another output:

1.25E7
12500000

Some JDBC driver use the toString() method to get the value of a BigDecimal and if it has to many decimal positions you may run into this problem.

In my case the solution was to do all the calculations with BigDecimal values and given MathContext and RoundingMode instead of creating BigDecimal values out of Double values from calculations.

BigDecimal value = new BigDecimal("100");
BigDeciaml result = value.divide(new BigDecimal("3"), 2,
                      BigDecimal.ROUND_HALF_UP);

instead of

BigDeciaml result = new BigDecimal(100.0 / 3.0);