Opennet.ruКомпания JetBrains объявила об открытии кода компонентов, связанных с реализацией языка программирования Kotlin.

Самое интересное:
Изначальной целью проекта было создание максимально совместимого с Java языка программирования, одновременно лишённого ограничений и недостатков Java, от которых Java не может избавиться из-за необходимости обеспечения обратной совместимости.

Бонусы нового языка:
отсутствие NPE. проводится через проверку типов на нуллы и запрет присвоение переменной значения null если она объявлена как "не содержащая null". компилятор проверяет обработку проверки на null у null-не-защищенных ссылок.

функции высшего порядка

делегирование

примеси

вывод типов

дополнительные приятный фишечки:

встроенная поддержка проперти

замыкания

Основной бонус - возможность полного двунаправленного взаимодействия с java. т.е. можно как из java вызывать kotlin, так и наоборот. Как я понял разработчиков этот язык нацелен на нишу java.

По мне у этого языка есть шансы "взлететь". А вы как думаете, коллеги?

----

- Just Do IT! (c)

Интересная статья на эту тему: http://www.osp.ru/os/2011/09/13011550/

ZyK_BotaNвот не понимаю, как в такой высокоуровневый язык как жава - попало это понятие, от которого даже скрыться нельзя.на момент создания языка возможность нулла в переменной было естественным. а дальше обратная совместимость.

Фактически у Oracle два варианта дальнейшего развития java как языка это либо забить на обратную совместимость и сделать Java X. но на подобный ход они вряд ли пойдут. Либо создать новый java и JVM совместимый язык и мигрировать на него, а базовая java останется для back-compatibility и old-legacy кода. Второй вариант более вероятен. Об этом можно судить по тому, как еще Sun стремился сделать JVM многоязычной платформой. Этим они развязывают себе руки по смене языка каждые 15-20 лет при бесшовной миграции.

ZyK_BotaNвот тот же мл был, могли от туда стырить.
т.е. разъясните мне естественность его использования.java язык который должен был захватить часть С++ программистов. без этого он бы умер не родившись. в С++ null указатель - норма, потому в java взяли ту же модель.

МЛ наверняка круто и полный Ъ, но что сейчас что раньше (в момент создания java) вакансий на него было около нуля. потому на него особо не ориентируются при создании production языков.

BlazkowiczJetBrains, вроде идею будет понемногу на Kotlin переводить. JBoss, интересно, тоже всё на свой цейлон перепишут. Ктобы оба пощупал для сравнения.сначала Kotlin перепишут на Kotlin (не шутка!) и только набрав большое количество кода на Kotlin стабилизируют синтаксис и выпустят в продакшен.

А щупать для сравнения лучше после выхода релизов. Что котлин что цейлон имеют ... сложно сопоставимые нюансы.

BlazkowiczКстати, замыканий в Kotlin, кажется пока нет.Следующая конструкция напоминает замыкание. Призываю ZyK_BotaN и других знатоков подтвердить или опровергнуть замыкание это или нет.




Другое дело, что kotlin не ввели замыкание как элемент языка, а применили функции высших порядков и синтаксический сахар. получилось мощно и красиво:



использованы следующие "сахарки":
1. если параметр функции один, то можно не присваивать имя переменной. тогда используется имя по умолчанию - it
2. если последний параметр функции - функция, то ее описание можно вынести из круглых скобок '()'. Если при этом у функции больше нет параметров, то круглые скобки можно вообще не указывать.

LeonidvСвою роль сыграло развитие DSL. Думаю, именно это послужило поводом для поддержки нескольких языков JDK, а затем в JVM.насколько я знаю JDK поддерживает только один язык. Для других требуются их собственные SDK.

LeonidvНе совсем понятно, что именно мешает Oracle вообще забить на Java как ня язык и оставить только JVM. Пусть Java остается базовым языком платформы, но лично я смысла развивать его - не вижу. Со своими задачами простого языка он справляется хорошо, а при необходимости на JVM есть уже ряд устоявшихся языков, пригодных для решения различных задач.Еще в бытность Sun он забил на развитие java как языка. сейчас Oracle пытается догнать конкурентов хотя бы в роли базового языка. что Oracle будет делать дальше - посмотрим. Возможно начнут заимствовать интересные фичи из языков типа Ceylon/Kotlin.

Blazkowicz- Свойства и указатели на функции. Без этого очень страдает как ORM так и многие другие движки на рефлексии - биндинг, IoC и т.п. Мы вынуждены везде писать свойства строкой, а не прямой ссылкой на свойство. Поэтому нет ни праверки что имя написано правильно, ни проверки на тип свойства во время компиляции.Свойства в Kotlin есть, но я не увидел их как First Class Property. потому пока можно пользоваться свойством, но нельзя сослаться на свойство :(

LeonidvЯ их читал. Не считаю, там что-то такое ужасное было, что мешает использовать Scala в проектах.так никто и не мешает. язык стоит использовать если он ПОМОГАЕТ. и при этом не создает серьезных трудностей в изучении, применении и т.п.

LeonidvПравда Java 8 может составить им сильную конкуренцию.только если в версии 9-10, который выйдут через 3 и 5 лет соответственно. First Class Property даже в 8-ке не делают. Максимум что смогли это костыльные мета-классы для JPA 2.0

защиту от NPE в java вообще не сделают будут поддерживать обратную совместимость, т.е. никогда.

ОзверинНе, не взлетит. Причина одна, но очень весомая: никто не хочет поддерживать зоопарк в архитектуре. А для новых проектов требуется веское обоснование выбора языка/платформа и тд.тут и кроется основной бонус Цейлон/Котлин - они обеспечивают возможность совмещать код на java с ceylon/kotlin. Т.е. можно безболезненно писать код на Котлине в больших java проектах или подменять java код на kotlin без фатального рефакторинга проекта.

из за "проблем" с "пропертями" в одном из проектов вместо гет/сет сделали public поля и счастье поскольку во внешний API данные классы не идут, то когда понадобится override для "проперти", тогда и сделаем гет/сет.

на котлине (будь он production-ready) многие вещи можно переписать улучшив читаемость и качество кода. что только в плюс проекту.

Читать так:

LeonidvПравда Java 8 может составить им сильную конкуренцию.только если в версии 9-10, который выйдут через 3 и 5 лет соответственно First Class Property в 8-ке даже не планируют. Максимум что смогли это костыльные мета-классы для JPA 2.0

защиту от NPE в java вообще не сделают пока будут поддерживать обратную совместимость, т.е. никогда.

BlazkowiczVoDAзащиту от NPE в java вообще не сделают будут поддерживать обратную совместимость, т.е. никогда.
В виде @Nullable - никогда. А в виде @NotNull (JSR-305) обсуждалось ещё для Java 7. Так что в 9ку может и попасть.Значит аннотациями... да, тогда могут и сделать :)

9-ка планируется через 3,5 года от момента сейчас, котлин в продакшене будет через год. итого два с половиной года на захват java-программистов


PS самый клевый бонус 8-ки это модульность и jugsaw. Если Oracle-овцы сделают, то уже молодцы =)))

GKS_SamaraДобрый день, VoDA!

Контракты, контракты, контракты!Привет!

А можно пример контракта, который статичен и проверяется компилятором в момент сборки проекта?

BlazkowiczVoDAЕсли Oracle-овцы сделают, то уже молодцы =)))
Кто сделают?Оракловцы )))

BlazkowiczVoDAPS самый клевый бонус 8-ки это модульность и jigsaw.
И какая от них практическая польза?основной бонус: отсутствие classpath и проблем с тем, что класспасы на машине разработчика и продакшен сервере разные.

вместо maven можно использовать саму java с основными бонусами типа локальных/удаленных репозиториев и т.п.

jugsaw в некотором смысле аналог OSGi, только пока без динамического запуска/останова. вероятно динамика появится позже.

появится возможность сделать API для проекта и оградить свой проект от вмешательства во "внутренний" API. сейчас либо все видят класс либо не видит никто кроме пакета.

вероятно вылечат jar-hell проблему когда проект А зависит от Б и В, а сами Б и В зависят от некого Д, но разных несовместимых по API версий. В java пока не лечится, зато C# успешно решил эту проблему много лет назад.

сам JRE вероятно станет модульным и сможет затягивать себя в зависимости от того, что нужно конкретному проекту.

Следом за модульностью JRE вероятно появится модульность JavaEE серверов когда сервер будет запускать/останавливать подсистемы по дескриптору зависимостей приложения. Если приложение зависит от JMS, то сервер запускает JMS, иначе нет. Как следствие JBoss или GlassFish будут работать как Tomcat для простых приложений и в полном объеме для толстых EAR.

BlazkowiczИ какая от них практическая польза?

Подведу итог:
отсутствие classpath и его болезней

большая часть работы maven будет реализована прямо в JDK

jugsaw в некотором смысле аналог OSGi

появится возможность сделать API проекта

вероятно вылечат jar-hell проблему diamond зависимостей

сам JRE станет модульным

модульность JavaEE серверов когда сервер будет запускать/останавливать подсистемы по дескриптору зависимостей приложения

ZyK_BotaNвторой(для меня более предпочтительный) пример:
resm2 = method2()
method1(resm2)
-вот здесь, уже не знаю как контракты на статически смогут сработать.Этот вариант и работает в Kotlin

переменные объявляются как nullable/notnull, также параметры и результаты функций. компилятор выдает ошибку при попытке в notnull записать или передать nullable переменную (результат)

Пример:
var str : String - значит notnull переменная, можно пользоваться без проверки на null
var str2: String ? - nullable переменная, любые операции с ней только после проверки на null.


ровно также статически проверяются ошибки при работе с функциями.

GKS_SamaraНет. Но достаточно проверки средой разработки. Сейчас это не проблема.
Ещё раз- статические проверки лучше, но контракты универсальнее.в kotlin в сигнатуру функции входит контракт на null / not null. Это еще более универсально чем просто контракт через аннотации ;)

ZyK_BotaNдак я про контракты говорю. что они - тут не помогут.

нужен notnull на уровне типов.читаем внимательнее