date format in jsp

This is checeked and working even without compiler warning.

You can do the same thing with Calendar but it is more straightforward and understandable with Date:

   java.util.Date dd = new java.util.Date();
  SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");

  String dateString = sdf.format(dd);

  String yearString = dateString.substring(0,4);

  String monthString = dateString.substring(4);

  int year = new Integer(yearString) + 1;

  dateString = year + monthString;

        System.out.println(dateString);

Select allOpen in new window

2012-07-14

Select allOpen in new window

>>optimisation

I dont get this part. You used sql date (  is not this should be util date ? )  and  milliseconds .  ..how does this optimize ?

java.sql.Date has toString() method which happened to format it just as you need
2012-07-14
If you use java.util.Date() the toString() method will be different and with seconds and so on, that's why CEHJ used java.sql.Date() here

You can use any of those solutions.
Calendar maybe a little bit newer and it is a standard, so
its bugs are not so well known.

The probability that you encounter bugs with leap years is much less than bugs  from hundred other sources,
and the advantage of java.util.Date is that it is much more intuitive, whereas
with Calendar you need to go to API to check how to write it, no matter how many times you use it.
At least for me it is this way.

>>I dont get this part. You used sql date (  is not this should be util date ? )  and  milliseconds .  ..how does this optimize ?

The optimisation is

a. avoiding the use of DateFormat (known to be slow - so much so that other apis have been written to do it)
b. writing less code ;)

>>You used sql date

Since its toString method gives you the format you need

I dont have a leap year constraint.  the idea was to find a date  advance than current date. ...it need not have to be exactly 1 year though ( with leap year).

Thanks for the information.

?

Please post the code that you are now going to use, cofactor, for the benefit of future visitors to this question

In my opinion, cofactor should have accepted http:#36188279   as the solution.  
I guess he was happy with the String manipulation posted by for_yan.  Personally, I would have accepted CEHJ's http:#36189661. But, the customer is always right.

>>cofactor should have accepted http:#36188279   as the solution.  

He should have accepted yours, with my adjustment ;)