From 236cccdef90ab09b017cc364c931a31bb3583bc4 Mon Sep 17 00:00:00 2001
From: Stephen Colebourne <scolebourne@joda.org>
Date: Thu, 6 Mar 2014 17:46:12 +0000
Subject: [PATCH] 8036785: ChronoLocalDate refers to generics that have been
 removed

Reviewed-by: alanb, rriggs
---
 .../java/time/chrono/ChronoLocalDate.java       | 17 +++++------------
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git a/jdk/src/share/classes/java/time/chrono/ChronoLocalDate.java b/jdk/src/share/classes/java/time/chrono/ChronoLocalDate.java
index baa7b69348c..6fe6a4578a9 100644
--- a/jdk/src/share/classes/java/time/chrono/ChronoLocalDate.java
+++ b/jdk/src/share/classes/java/time/chrono/ChronoLocalDate.java
@@ -101,19 +101,12 @@ import java.util.Objects;
  * <h3>When to use this interface</h3>
  * 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.
  * <p>
- * The primary use case where this interface should be used is where the generic
- * type parameter {@code <D>} 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.
- * <p>
- * When the chronology is defined in the generic type parameter as ? or otherwise
- * unknown at development time, the rest of the discussion below applies.
- * <p>
- * 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}.
  *