What is required of plugin authors to support K2 m...

# intellij

[Josh Friend]

What is required of plugin authors to support K2 mode for intellij plugins? We have a custom IDE plugin that (i thought) had nothing to do with what K1/K2 handle in the IDE, so I was surprised to see it was disabled when I turned on K2 mode

[Anton Yalyshev [JB]]

cc @Roman Golyshev

[Roman Golyshev]

Hi! Is your plugin happen to be public, is it possible to take a look at the code?

[Josh Friend]

it is not public, any pointers of what I should look at? something in plugin.xml? it does have <depends>org.jetbrains.kotlin</depends> which i am not sure is actually required for it to work

[Roman Golyshev]

Look for the following line in your project:

import org.jetbrains.kotlin

Do you have any matches? If you do, what are the imported classes? Do they have prefixes like Kt ? Or maybe the word Descriptor or BindingContext or ResolutionFacade in them?

[Josh Friend]

there are a few imports from that package:

org.jetbrains.kotlin.idea.actions.JavaToKotlinAction
org.jetbrains.kotlin.idea.configuration.ExperimentalFeatures
org.jetbrains.kotlin.idea.core.getPackage
org.jetbrains.kotlin.idea.KotlinBundle
org.jetbrains.kotlin.j2k.getContainingClass
org.jetbrains.kotlin.j2k.getContainingMethod
org.jetbrains.kotlin.j2k.J2kConverterExtension
org.jetbrains.kotlin.psi.KtClass
org.jetbrains.kotlin.psi.KtNamedFunction
org.jetbrains.kotlin.psi.psiUtil.getParentOfType
org.jetbrains.kotlin.util.prefixIfNot

looks like KtClass and KtNamedFunction are used to provide some custom test running related actions

[Roman Golyshev]

Since you’re using J2K features (which are heavily dependant on the resolve == K1/K2 frontend), your plugin would probably have to do some migration, since there’s a lot of changes in that API AFAIK

Other imports look like utils and PSI related stuff, so it should be fine

What is your usage of the J2K extension mechanism, if you don’t mind me asking?

[Josh Friend]

theres a variation of the "convert java to kotlin" feature which renames the file in git to *.kt first, then converts to kotlin so that at least some of the file history can be preserved in git-blame

[Josh Friend]

i think we just invoke the IDE action for the second part though, and dont use j2k directly....

[Josh Friend]

/**
 * Given a [PsiElement], returns the containing method name once found (null otherwise).
 *
 * For Java, there's a convenience method named "getContainingMethod" that returns a PsiMethod.
 * For Kotlin, there's no convenience, so we have use PsiTreeUtil to find the parent [KtNamedFunction].
 */
val PsiElement.containingMethodName: String?
  get() = getContainingMethod()?.name ?: getParentOfType<KtNamedFunction>(false)?.name

/**
 * Given a [PsiElement], returns a list of annotations mapped to a list of human readable strings.
 * This method will only return the annotation name itself, even if the method is annotated with a
 * fully-qualified annotation (i.e. will return "Test" for either "@Test" or "@org.junit.Test")
 *
 * Result will be mapped to a string representation of PsiAnnotations on a Java class, falling back to
 * a string representation of KtAnnotationEntries on a Kotlin class. emptyList() if none are found.
 */
val PsiElement.annotationNames: List<String>
  get() = getContainingMethod()?.annotations
    ?.map { it.qualifiedName.toString().substringAfterLast(".") }
    ?: getParentOfType<KtNamedFunction>(false)?.annotationEntries?.map { it.shortName.toString() }
    ?: emptyList()

/**
 * Given a [PsiElement], returns the containing class name once found (null otherwise).
 *
 * For Java, return a [PsiClass] from a containing class.
 * For Kotlin, walk up the tree to find the first instance of a [KtClass].
 */
val PsiElement.containingClassName: String?
  get() = getContainingClass()?.name ?: getParentOfType<KtClass>(false)?.name

these are the majority of j2k imports, and its only used to retrieve class/method names for a right-click action

[Josh Friend]

the other use calls J2kConverterExtension.extension(useNewJ2k = ExperimentalFeatures.NewJ2k.isEnabled).doCheckBeforeConversion(project, module) and aborts the conversion action if it fails

[Roman Golyshev]

Then it might just work in K2, but I am not 100% sure. We have not yet fully migrated J2K to the K2

The code that you’ve posted is PSI-based, it should be fine (except occasional deprecations)

What is required of plugin authors to support K2 mode for intellij plugins?

We do not have an “official” recommendation/API at the moment; however, we’re going to provide some migration guidance for the plugins authors in the foreseeable future

Currently, any plugin which depends on Kotlin is disabled automatically to avoid exceptions and unexpected behaviours

[Emil Kantis]

Is there any update on this? I'd like to check what's needed for Kotest's IntelliJ plugin to support K2 mode

[henrik]

👀