Some Guava features were really useful for Java 7 application because Guava was bringing APIs missing in the JDK. The introduction of Kotlin and
Java 8+ fixed some of these limitations. When migrating an application to Kotlin and/or using a Java 8+ target, it is recommended to prefer the
provided native APIs over Guava to ease maintenance: developers don’t need to learn how to use two APIs and can stick to the default one.
This rule raises an issue when the Guava APIs listed below are used.
  
    
    
  
  
    
      | Guava API | Kotlin API | 
  
  
    
      | com.google.common.base.Joiner.on
 | kotlin.collections.Iterable.joinToStringorkotlin.Array.joinToString
 | 
    
      | com.google.common.base.Predicate
 | Use function with type (T) → Booleanas a replacement forPredicate<T> | 
    
      | com.google.common.base.Function
 | Use function with type (T) → Ras a replacement forFunction<T, R> | 
    
      | com.google.common.base.Supplier
 | Use function with type () → Tas a replacement forSupplier<T> | 
    
      | com.google.common.io.Files.createTempDir
 | kotlin.io.path.createTempDirectory
 | 
    
      | com.google.common.collect.ImmutableSet.of
 | kotlin.collections.setOf
 | 
    
      | com.google.common.collect.ImmutableList.of
 | kotlin.collections.listOf
 | 
    
      | com.google.common.collect.ImmutableMap.of
 | kotlin.collections.mapOf
 | 
  
  
    
    
  
  
    
      | Guava API | Java 8 API | 
  
  
    
      | com.google.common.io.BaseEncoding.base64
 | java.util.Base64
 | 
    
      | com.google.common.io.BaseEncoding.base64Url
 | java.util.Base64
 | 
    
      | com.google.common.base.Optional
 | java.util.Optional*
 | 
    
      | com.google.common.base.Optional.of
 | java.util.Optional.of*
 | 
    
      | com.google.common.base.Optional.absent
 | java.util.Optional.empty*
 | 
    
      | com.google.common.base.Optional.fromNullable
 | java.util.Optional.ofNullable*
 | 
  
*: Note that this rule will also raise issues for the use of Guava Optional and recommend using the Java 8+ equivalent instead. In
most Kotlin-only cases, you will probably be better off using Kotlin’s null-safe type system directly, without wrapping Optional
constructs. In some cases, such as those involving Java interoperability, it may be necessary to use Optional in Kotlin, however.