AN
А не логичнее ли делать наоборот?
Ну в котлин плагине мы обычно выставляем котлиновский таргет. Знать не знаем про то, что там джавовый плагин под капотом
Size: a a a
2019 November 20
VP
Ну и если targetCompatibility не указан, значит, пользователя не парит целевая версия jdk
VP
Ну в котлин плагине мы обычно выставляем котлиновский таргет. Знать не знаем про то, что там джавовый плагин под капотом
Ну плагин для jvm тесно связан с java-плагином
AN
Ну и если targetCompatibility не указан, значит, пользователя не парит целевая версия jdk
Ну так внутри же таргет вычисляется, надо только чтобы он автоматом прописывался и в targetCompatibility
AN
Просто как сейчас там прописывается версия JDK - это дефолт джавового плагин
VP
Ну так внутри же таргет вычисляется, надо только чтобы он автоматом прописывался и в targetCompatibility
У Котлина 1.6 дефолт же
AN
У Котлина 1.6 дефолт же
Ну да, по-моему с 1.4 переходим на 1.8 или что-то в этом роде. Но в метадату прописывается 12.
VP
А вот у java - текущая версия jdk.
И это не секрет, что не указывать targetCompatibility в либе - плохая идея.
И это не секрет, что не указывать targetCompatibility в либе - плохая идея.
VP
Ну да, по-моему с 1.4 переходим на 1.8 или что-то в этом роде. Но в метадату прописывается 12.
Это потому что gradle знать не знает, какая версия байткода у классов, которые выдал kotlinc. Если рядом положить исходник на джаве, он в 12 и скомпилится.
AN
Это потому что gradle знать не знает, какая версия байткода у классов, которые выдал kotlinc. Если рядом положить исходник на джаве, он в 12 и скомпилится.
я вообще не про это. Я про то, что теперь публишится градл метадата. И там указан таргет. Если этот таргет, скажем, 12. То при попытке использовать либу из проекта с меньшим таргетом, будет ошибка.
AN
Байткод там при этом может быть и 1.8
VP
я вообще не про это. Я про то, что теперь публишится градл метадата. И там указан таргет. Если этот таргет, скажем, 12. То при попытке использовать либу из проекта с меньшим таргетом, будет ошибка.
Так всё правильно же 🤷♂
Единственное, что есть смысл улучшать в этой схеме - подхватывать этот таргет в котлиновском плагине.
Единственное, что есть смысл улучшать в этой схеме - подхватывать этот таргет в котлиновском плагине.
AN
Так всё правильно же 🤷♂
Единственное, что есть смысл улучшать в этой схеме - подхватывать этот таргет в котлиновском плагине.
Единственное, что есть смысл улучшать в этой схеме - подхватывать этот таргет в котлиновском плагине.
Это бессмыслица. Если мы компилим под JDK 12, это не значит, что мы хотим использовать либу только на JDK 12. Байткод-то соместим.
VP
Вы как будто игнорируете существование java плагина и то, что котлиновский базируется на нём
VP
Это бессмыслица. Если мы компилим под JDK 12, это не значит, что мы хотим использовать либу только на JDK 12. Байткод-то соместим.
Так укажите параметры совместимости и всё. И нет, не у котлина.
AN
Вы как будто игнорируете существование java плагина и то, что котлиновский базируется на нём
Да не в этом дело, а в том, что если бы мы писали на джава плагине, мы бы ему настройки выставляли и о нем думали. Мы думаем про котлин плагин и выставляем его настройки. То, что он не сообщает джава плагину об этих настройках - не очевидное поведение.
AN
О чем спор вообще? Я просто говорю, что jvmTarget у котлиновского плагина должен быть синхронизован с метадатой
VP
О чем спор вообще? Я просто говорю, что jvmTarget у котлиновского плагина должен быть синхронизован с метадатой
О том, в какую сторону синхронизировать
VP
Да не в этом дело, а в том, что если бы мы писали на джава плагине, мы бы ему настройки выставляли и о нем думали. Мы думаем про котлин плагин и выставляем его настройки. То, что он не сообщает джава плагину об этих настройках - не очевидное поведение.
Я если что не про MPP проекты. Там о джаве думать надо.
AN
Да хоть в обе стороны. Важно чтобы было синхронизовано