Using Calendar::add to add +n years to a calendar when the calendar is set to era 0 may move forward or backward in time depending on the calendar; this behavior is neither documented nor consistent (for some gregorian variants it moves forward, for others it moves backwards).
The following chart shows, for each calendar, what the current era is; what Calendar::clear sets the fields to (and what this corresponds to in the Gregorian calendar), what era 0 year 1 corresponds to in the Gregorian calendar, and what direction in time results in era 0 from adding positive amounts to the year0 ([ICU-unknown]). This corresponds to increasing the value of the year field, but (depending on the calendar) that may go forward or backward in time.
This causes problems for Calendar::fieldDifference, which are documented in a separate bug, #9227.
I have not checked ICU4J, it likely has the same problem.
ICU api for calendar metadata?
CLDR: need to add eraGoesBackward=true to CLDR supplementalData?
Check ICU4J behavior.
Note that ICU4C roll documentation always says that adding a positive value to year goes forward in time regardless of the direction in which years go in a given era, and add is supposed to be aligned with roll.
Also note that ICU4C fieldDifference expects that adding a positive value to year always goes forward in time.
At any rate, should have a method to find out the direction of an era. As Steven notes, this may be part of a larger API to get calendar metadata.
Also see Yoshito ticket about negative values in calendar fields, #9204
See more detailed analysis and proposal at http://site.icu-project.org/design/calendar-issues/backwards-era-0-years-and-add-roll. The decision from ICU PMC 2012-06-13 is:
add with a positive year value should always move forward in time
roll with a positive year value should always move forward in time, except that forward movement past the end of an era may wrap to the beginning of the era, see next item
a roll that would move beyond an era boundary should wrap within the era as long as the era has definite bounds at each end (as with Chinese calendar eras or previous Japanese eras), otherwise it should pin at the era boundary.
Note, the Java implementation for add intentionally uses a fallthrough from one case to the next in a switch statement, which produces a compilation warning "warning: [fallthrough] possible fall-through into case". If we want to get rid of this I could either change the code (adding more duplication) or - I think - add a Java annotation '@SuppressWarnings("fallthrough")'. For the latter, I am not very familiar with Java annotations and not sure where the best place is to add it.