Если из Java-кода попытаться обратиться к internal-полю Kotlin-класса напрямую, произойдет ошибка компиляции. Это связано с особенностями модификатора internal в Kotlin и тем, как Kotlin-код транслируется в байткод JVM, а также с тем, как работает модификатор видимости на уровне JVM и в межъязыковой совместимости между Kotlin и Java.

Что означает internal в Kotlin

В Kotlin модификатор доступа internal означает, что член (класс, метод, поле, свойство и т. д.) доступен только в пределах одного модуля. Модуль в контексте Kotlin — это, например:

• отдельный Gradle-модуль,

• Maven-артефакт,

• IntelliJ IDEA-модуль.

Таким образом, любой другой код (в том числе Java-код), находящийся вне текущего Kotlin-модуля, не может получить доступ к элементу, помеченному как internal.

Что происходит на уровне байткода

Компилятор Kotlin транслирует модификатор internal в public на уровне JVM, поскольку JVM не поддерживает модификатор видимости internal как таковой. Но, чтобы обеспечить контроль доступа, Kotlin использует аннотацию @PublishedApi и метаданные, с помощью которых инструменты Kotlin (компилятор, IDE и т. д.) могут контролировать доступ к internal-элементам.

Однако Java-компилятор не распознаёт эти метаданные, и в большинстве случаев просто не видит internal-членов Kotlin-класса, даже если они физически присутствуют в байткоде как public.

Чтобы добиться этого, Kotlin использует сгенерированные имена классов и методов, а также флаги synthetic, указывающие, что элемент не предназначен для использования напрямую из других языков или даже из самого Kotlin-кода без специальных условий.

Пример: Kotlin-класс с internal-полем

// KotlinClass.kt
class KotlinClass {
internal val secret = "Internal secret"
}

Попробуем обратиться к полю из Java-кода:

// JavaClass.java
public class JavaClass {
public static void main(String\[\] args) {
KotlinClass kotlinObject = new KotlinClass();
System.out.println(kotlinObject.secret); // Ошибка компиляции
}
}

Этот код не скомпилируется, несмотря на то что на уровне байткода поле secret может быть доступным как public. Причина — в сгенерированном Kotlin-манифесте, который делает это поле недоступным из Java.

Как Kotlin добивается ограничения доступа

Kotlin может использовать несколько подходов:

1. **Синтетические методы и свойства
   **

   • Метка ACC_SYNTHETIC на уровне JVM говорит, что метод или поле не должно использоваться напрямую.

   • Java-компилятор обычно не видит такие члены (например, не показывает их в автодополнении и не позволяет к ним обращаться).

2. **Mangling имён
   **

   • В некоторых случаях Kotlin "порчит" имена методов/полей, добавляя суффиксы, чтобы избежать коллизий и скрыть реализацию от Java.

3. **Встроенные проверки в IDE и компиляторе
   **

   • Даже если поле есть в байткоде, среда разработки и компилятор Java не позволят к нему обратиться, если оно помечено как internal.

Исключения и обходы (не рекомендуется)

Существуют способы обойти это ограничение, но они противоречат идеологии internal и использовать их стоит только в очень крайних случаях:

Через рефлексию:
Java-рефлексия позволяет получить доступ ко всем членам класса, даже private. Однако такой подход нарушает инкапсуляцию и может быть опасным (например, сломается при обновлении Kotlin-компилятора или модуля).

Field field = KotlinClass.class.getDeclaredField("secret");
field.setAccessible(true);
String value = (String) field.get(kotlinObject);

Через публикацию API:
Если добавить аннотацию @PublishedApi и @JvmField, это изменит поведение и допустит доступ из Java. Однако в этом случае internal становится условным, и фактически такая переменная становится доступной.

class KotlinClass {
@PublishedApi
@JvmField
internal val secret = "Internal secret"
}

После этого Java-код сможет получить доступ к полю secret.

Что в итоге

• По умолчанию internal-члены Kotlin недоступны из Java.

• Это ограничение накладывается компилятором Kotlin и механизмами JVM (ACC_SYNTHETIC), несмотря на то, что модификаторы видимости JVM не поддерживают internal.

• Обход возможен через рефлексию или использование аннотаций @PublishedApi/@JvmField, но это нарушает принципы модульности и может привести к проблемам при изменении API.

Таким образом, безопаснее всего считать, что Java не может получить доступ к internal-элементам Kotlin, и проектировать архитектуру так, чтобы не было необходимости нарушать это ограничение.