GeneralCodingRules to detect usages of old time and date classes

[Bukama]

Over at Bluesky Gunnar Morling "cried" about the fact that still many people use old date and time classes and asked if there are any build time checkers to detect that. I answered that my team at work and I wrote ArchUnit rules for that, which lead @rweisleder to ask if I could provide them to the ArchUnit's GeneralCodingRules .

The rules we wrote at my work

 */
public class DateTimeRules {

  static final String JAVATIME_REASON = "since Java 8 and JavaEE 7 java.time-API should be used.";

  @ArchTest
  public static final ArchRule NO_JAVA_SQL_DATE = noClasses().should().dependOnClassesThat()
      .haveFullyQualifiedName("java.sql.Date").because(JAVATIME_REASON);

  @ArchTest
  public static final ArchRule NO_JAVA_SQL_TIME = noClasses().should().dependOnClassesThat()
      .haveFullyQualifiedName("java.sql.Time").because(JAVATIME_REASON);

  @ArchTest
  public static final ArchRule NO_JAVA_SQL_TIMESTAMP = noClasses().should().dependOnClassesThat()
      .haveFullyQualifiedName("java.sql.Timestamp").because(JAVATIME_REASON);

  @ArchTest
  public static final ArchRule NO_JAVA_UTIL_CALENDAR = noClasses().should().dependOnClassesThat()
      .haveFullyQualifiedName("java.util.Calendar").because(JAVATIME_REASON);

  @ArchTest
  public static final ArchRule NO_JAVA_UTIL_DATE = noClasses().should().dependOnClassesThat()
      .haveFullyQualifiedName("java.util.Date").because(JAVATIME_REASON);

}

I'll give it a try to create a PR to add them to ArchUnit.

P.S. For everyone who's wondering why those classes are not deprecated: Brian Goetz mentioned that they most probably will never be annotated with @Deprecated cause of the global usage in almost infinite APIs all over the Java universe, e.g. see this mailing list entry.