# HG changeset patch # User scolebourne # Date 1394127972 0 # Node ID ac4e06be5763cb3b5367384289e143f0d9eb7b6f # Parent 08ca64c3f0e4dc077e41b9b60047751fcf5ae3da 8036785: ChronoLocalDate refers to generics that have been removed Reviewed-by: alanb, rriggs Contributed-by: Stephen Colebourne diff -r 08ca64c3f0e4 -r ac4e06be5763 jdk/src/share/classes/java/time/chrono/ChronoLocalDate.java --- a/jdk/src/share/classes/java/time/chrono/ChronoLocalDate.java Sat Mar 29 15:01:47 2014 -0400 +++ b/jdk/src/share/classes/java/time/chrono/ChronoLocalDate.java Thu Mar 06 17:46:12 2014 +0000 @@ -101,19 +101,12 @@ *

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. - *

- * 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. + * calendar systems. *

- * 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}. *