Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

@Deprecated in Kotlin

DZone's Guide to

@Deprecated in Kotlin

This quick primer on the @Deprecated annotation shows how it works with Kotlin code and how you can customize the deprecation level to suit your needs.

· Java Zone ·
Free Resource

How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.

In Kotlin, we can use the @Deprecated annotation to mark a class, function, property, variable, or parameter as deprecated. What makes this annotation interesting is not only the possibility of deprecation, but also of providing replacements with all the necessary imports. This comes in handy for clients upgrading source code without digging into documentation. Apart from this, we can also control the level of depreciation. Let's see it in action.

To mark a function as deprecated, all you need to do is annotate it and provide the deprecation message. Thanks to Kotlin's Java interoperability, we can use this Annotation within existing Java code bases.

@Deprecated(message = "we are going to replace with StringUtils.isEmpty)
public static boolean isEmpty(String input) {
    return input.equals("");
}

Client view when invoking the method

It would be nice if we could also provide the replacement code as part of an IDE suggestion to help a client to upgrade their code base. @ReplaceWith aims to achieve exactly that. It takes two arguments :

  1. expression: method call to replace with.
  2. imports: necessary import to make an expression compile.

E.g.

@Deprecated(message = "we are going to replace with StringUtils.isEmpty",
        replaceWith = @ReplaceWith(
                expression = "StringUtils.isEmpty(input)",
                imports = {"org.apache.commons.lang3.StringUtils"})
)
public static boolean isEmpty(String input) {
    return input.equals("");
}

IDE can now suggest the replacement method

Depending on the use case, we can also tweak the deprecation level for an immediate upgrade. Supported levels are:

  1. Warning: will result in a compilation warning. This is the default level.
  2. Error: will result in a compilation error.
  3. Hidden: will be hidden in the code base (non-existing for the caller), but will be present at the bytecode level. This is useful in scenarios where we want to pretend the method doesn't exist at the source code level but still want to keep it at bytecode level (for compatibility reasons).

E.g. DeprecationLevel.ERROR

@Deprecated(level = DeprecationLevel.ERROR,
        message = "we are going to replace with StringUtils",
        replaceWith = @ReplaceWith(
                expression = "StringUtils.isEmpty(input)",
                imports = {"org.apache.commons.lang3.StringUtils"})
)
public static boolean isEmpty(String input) {
    return input.equals("");
}

Deprecation level – Error
E.g. DeprecationLevel.HIDDEN 

@Deprecated(level = DeprecationLevel.HIDDEN,
        message = "we are going to replace with StringUtils",
        replaceWith = @ReplaceWith(
                expression = "StringUtils.isEmpty(input)",
                imports = {"org.apache.commons.lang3.StringUtils"})
)
public static boolean isEmpty(String input) {
    return input.equals("");
}

Deprecation Level – Hidden


How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.

Topics:
kotlin ,java ,deprecation ,annotation ,tutorial

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}