diff --git a/src/share/classes/java/time/chrono/ChronoLocalDate.java b/src/share/classes/java/time/chrono/ChronoLocalDate.java index baa7b69348cc7489c2f056661d4e13c47d04144e..6fe6a4578a9fec840e178538ed3b15ebea8d2c61 100644 --- a/src/share/classes/java/time/chrono/ChronoLocalDate.java +++ b/src/share/classes/java/time/chrono/ChronoLocalDate.java @@ -101,19 +101,12 @@ import java.util.Objects; *

When to use this interface

* The design of the API encourages the use of {@code LocalDate} rather than this * interface, even in the case where the application needs to deal with multiple - * calendar systems. The rationale for this is explored in the following documentation. + * calendar systems. *

- * The primary use case where this interface should be used is where the generic - * type parameter {@code } is fully defined as a specific chronology. - * In that case, the assumptions of that chronology are known at development - * time and specified in the code. - *

- * When the chronology is defined in the generic type parameter as ? or otherwise - * unknown at development time, the rest of the discussion below applies. - *

- * To emphasize the point, declaring a method signature, field or variable as this - * interface type can initially seem like the sensible way to globalize an application, - * however it is usually the wrong approach. + * This concept can seem surprising at first, as the natural way to globalize an + * application might initially appear to be to abstract the calendar system. + * However, as explored below, abstracting the calendar system is usually the wrong + * approach, resulting in logic errors and hard to find bugs. * As such, it should be considered an application-wide architectural decision to choose * to use this interface as opposed to {@code LocalDate}. *