Quiz yourself: The strange case of the Java developer’s birthday

You want to know what the day of the week will be, one year from today.

On her birthday one August, a Java developer decided to check what day of the week her next birthday will fall on.

Given the following partial code

LocalDate birthday = LocalDate.now();

// line n1

DayOfWeek dow = birthday.getDayOfWeek();

Which two of the following could be added at line n1 to perform this calculation? Choose two.

A. birthday = birthday.plus(365, ChronoUnit.DAYS);

B. birthday.plus(365, ChronoUnit.DAYS);

C. birthday = birthday.plus(52, ChronoUnit.WEEKS);

D. birthday = birthday.plus(12, ChronoUnit.MONTHS);

E. birthday = birthday.plus(1, ChronoUnit.YEARS);

F. birthday.plusYears(1);

G. birthday.plus(1, ChronoUnit.YEARS);

Answer. This question investigates some simple rules related to the Gregorian calendar and crucial elements of the Date and Time API added with the release of Java 8.

First, consider the Gregorian calendar. In the options above, you are offered choices involving adding 365 days, 52 weeks, 12 months, and 1 year. Only the last two are reliable, because leap years have 366 days, and no year has a full 52 weeks. So, you can immediately reject options A, B, and C as being incorrect from a logic perspective.

Options D, E, F, and G all look like they attempt to add either 12 months or 1 year, so they look believable from the perspective of business logic. To move forward, though, you must determine if the code is correct from the API perspective.

A key feature of the Date and Time API is that the classes within it (with some exceptions, notably the exceptions it defines) are immutable. This means that, as with the String class, when you invoke a method that changes a date-time element, you do not actually change the contents of the existing object; instead, you create a new object that represents the result of the change.

Therefore, if you wrote this String code

String s = "Hello";

s.toUpperCase();

System.out.println(s);

the output would be Hello because you failed to store the uppercase String HELLO that was created in the second line. The same error is made in options F and G. Both of those options correctly create a date exactly one year in the future—but that object is lost, so the third line of the original code sample would still be operating on today’s date. From this you can determine that options F and G are both incorrect.

You now have only two options left: options D and E. These are both correct from a business logic perspective: They are valid API methods, and the new LocalDate object they create is properly stored for use on the final line. From this you can determine that options D and E must be the correct answers.

However, there’s another wrinkle in this question, which explicitly mentions that it’s August. This has significance; that’s been ignored until now, but the logic given above is not complete without considering this.

When the developer runs the query on her birthday, if that day happens to be February 29 (which means that the day is in a leap year) a decision is forced on the API. Clearly it would be an error if the result were February 29 in the following year because the following year will not be a leap year. Therefore, the API would decide to treat the result as February 28 in the following year. That decision may be arbitrary, but it’s documented and therefore predictable.

That’s why, without a stipulation that precludes “today” from being February 29, even options D and E would be questionable—though they’d still be better choices than the others. If you encounter such a situation in an exam, you would be right to choose them in the absence of any other options.

Conclusion. The correct answers are options D and E.

Source: oracle.com