• TeaVM — инструмент для создания веб-фронтэнда на Java, Kotlin и Scala
    +1
    И городить свой UI фреймворк имеет смысл только с прицелом на android разработчиков по-моему.

    У меня не столько фреймворк сделан, сколько компилятор альтернативный. Проблема в том, что ничего GWT-ного в нём не работает, ни UI binder, ни Errai. Теоретически можно попросить создателей Errai портировать его на TeaVM, но вряд ли они на это согласятся. Вот и пришлось городить свой UI-фреймворк.


    Да и стандартный UiBinder вполне себе декларативный

    Вот есть у меня большущая коллекция, и мне нужно показать её в table или в ul. Что делать в UiBinder? Он такого не поддерживает. Приходится городить код, который итерируется по коллекции и добавляет элементы в нужное место (некоторые для строк таблицы пишут ещё один отдельный шаблон). А если надо ещё и обновлять, причём минимальным количеством действий с DOM, то можно вообще убиться. Так что нет, UiBinder вовсе не декларативен и совершенно не удобен.

  • TeaVM — инструмент для создания веб-фронтэнда на Java, Kotlin и Scala
    0
    Ну да, это TeaVM, там насколько я понял, UI кажется вообще нет

    Есть там UI: http://teavm.org/live-examples/graphhopper/


    Хотя бы чтобы помнить, почему он оказался неудачен.

    Технических проблем не было вообще. Были организационные и коммуникационные проблемы.

  • TeaVM — инструмент для создания веб-фронтэнда на Java, Kotlin и Scala
    0

    Это очень древняя история, я давно уже этим не занимаюсь (как и автор Graphhopper). Не стал от греха подальше упоминать о подобных вещах. Но вот в комментах напишу: ещё вполне актуально использование TeaVM в CodenameOne: https://www.codenameone.com/demos.html Почти на каждой демке есть опция JS port. Это они с помощью TeaVM скомпилили.

  • TeaVM — инструмент для создания веб-фронтэнда на Java, Kotlin и Scala
    0

    Заоптимизировал, прислал пулл-реквест. Сам код TodoMVC не менял, просто собрал последний Flavour локально и заменил в pom.xml версию на 0.1.0-SNAPSHOT. А ещё выставил уровень оптимизации FULL. Стало значительно лучше, причём и при добавлении

  • TeaVM — инструмент для создания веб-фронтэнда на Java, Kotlin и Scala
    +1
    Фреймворк может брать на себя оптимизации

    Заставляя при этом подчиняться ему. И, как я уже писал выше, шаг влево, шаг вправо — расстрел. Вместо этого на себя оптимизации могут брать библиотеки. Одна библиотека (RxJava) оптимизирует пересчёт данных, другая (Flavour) оптимизирует перерисовку DOM.

  • TeaVM — инструмент для создания веб-фронтэнда на Java, Kotlin и Scala
    0
    Скорее всего пользователь сделает как проще и всё буде тормозить

    Premature optimization is the root of all evil © Donald Knuth


    Обычно, тормозит 10% программного кода, остальные 90% в принципе работают с такими объёмами данных, что тормозить нечему. Зачем в этих 90% кода городить лишние абстракции?


    Насколько я понял Flavour никакой не фреймворк, а просто библиотека для рендеринга.

    В какой-то степени так. А ещё для роутинга, сериализации, валидации и REST. Не люблю фреймворки, потому что они принуждают пользователей к определённой структуре организации приложения, при этом шаг влево, шаг вправо — расстрел. Но если назвать свой проект "библиотека" или "toolkit", люди не поймут.

  • TeaVM — инструмент для создания веб-фронтэнда на Java, Kotlin и Scala
    +1

    В статье я ясно написал:


    Фреймворк не создаёт экземпляр класса страницы, и никак не управляет им. Вместо этого вы создаёте его сами и сами же им управляете как хотите

    Делается это, чтобы не навязывать пользователю определённую модель данных. А ещё для того, чтобы соблюсти SRP. Но я поиграюсь на выходных, попробую зацепить какую-нибудь RxJava или поищу другие фреймворки для реактивных данных. Суть в том, что пользователь может обновлять данные так, как ему хочется. Хочется руками — пусть обновляет руками, хочется реактива — будет реактив. А если перфоманс не принципиален в конкретном случае, так пусть вообще оставит наивную но простую реализацию.

  • TeaVM — инструмент для создания веб-фронтэнда на Java, Kotlin и Scala
    0

    Flavour — это не про данные, а про их отображение. По идее, для пересчёта данных можно придумать/переиспользовать что-то другое, это никак не отразится на том, как шаблоны выглядят.

  • TeaVM — инструмент для создания веб-фронтэнда на Java, Kotlin и Scala
    0
    Ну, по хорошему реализация должна быть максимально нативная для фреймворка, без заточенных специально под бенчмарк оптимизаций, типа "сохраняем в localStorage лишь через секунду".

    Я не об этом. Например, в моей наивной реализации TodoMVC фильтр (это тот, который All|Active|Completed) применяется при каждом чтении свойства, причём не в ленивый sequence, а в новый ArrayList. Можно сделать sequence, можно немного умнее перестраивать список и т.п. Это никак не относится к фреймворку.

  • TeaVM — инструмент для создания веб-фронтэнда на Java, Kotlin и Scala
    0

    Кстати, мне пришло в голову, что этот бенчмарк измеряет не просто фреймворк, на котором писали TodoMVC, но ещё и конкретную реализацию. Реализацию, прямо скажем, я даже не пытался оптимизировать, написав максимально простой код, ведь это же пример. Уверен, можно сделать и лучше.

  • TeaVM — инструмент для создания веб-фронтэнда на Java, Kotlin и Scala
    0

    Спасибо. Вообще, я знаю в чём дело. Надо просто немного улучшить реализацию std:foreach, потому что сейчас она полностью перестраивает DOM, если изменяется начало списка. Улучшение тривиальное, но руки не доходили сделать. Попробую сегодня поправить, собрать TodoMVC на снапшоте и повторить замер.

  • TeaVM — инструмент для создания веб-фронтэнда на Java, Kotlin и Scala
    0
    В Kotlin же есть нативная поддержка компиляции в Javascript. Получается, что я могу скомпилировать Kotlin-фронтенд двумя разными способами.

    Да, всё так


    Уже пробовали их сравнивать?

    В каком смысле сравнивать? По производительности? По размеру генерируемого кода? Полагаю, можно написать синтетические бенчмарки, показывающие преимущества того или другого в специфическом сценарии. Что касается концептуального: в Kotlin/JS нет возможности использовать библиотеки, написанные на Java, в TeaVM немного сложнее интеропиться с JS (потому что нет специальной поддержки со стороны языка в Java и Kotlin/JVM, приходится придумывать костыли и обкладываться аннотациями). А так, если интересно, можно потратить некоторое время на исследование и составить подробный список различий, преимуществ и недостатков каждого подхода.

  • Spark — Потрясающий веб-микрофреймворк для Java
    +1
    1. В TeaVM не надо писать на JavaScript, для того он и создан
    2. Есть возможность делать гуй на шаблонах (с биндингом, перерисовкой только изменившегося DOM). Пишите шаблоны под bootstrap — будут и компоненты. Можно создавать свои компоненты для шаблонизатора, можно биндиться к JavaScript-компонентам (как и в GWT). Но, разумеется, т.к. мой проект пока не нашёл широкого применения, под него есть только небольшой набор стандартных компонентов.
  • Spark — Потрясающий веб-микрофреймворк для Java
    +1
    Например Element.querySelector() уже более 5 лет доступен в браузерах, а в GWT его так и не поддержали

    А зачем его вызывать вручную? Я всегда думал, что выбор элементов за меня сделает библиотека виджетов. А сделает она это через JSNI или через overlay-тип — мне какая разница? Конечно, иногда надо напрямую сделать что-то с DOM, но это настолько редко требуется, что кусочек JSNI не проблема написать. Зато остальные 99% кода пишутся на Java без проблем.


    но зачем тогда вообще тащить GWT

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

  • Spark — Потрясающий веб-микрофреймворк для Java
    0
    начинать на нем что-то новое на мой взгляд не надо

    А можно услышать какие-нибудь аргументы? Просто интересно

  • Spark — Потрясающий веб-микрофреймворк для Java
    +2

    Пользуясь случаем, попиарю свой проект: http://teavm.org/
    Поддерживаются Java, Scala, Kotlin, есть Angular-образный фреймворк в комплекте

  • Kotlin для Android: Теперь официально
    +1

    Я в курсе. Речь была о том, что даже если автор не позаботился о расстановке этих аннотаций для удобства использования из Java, то полученный негативный эффект будет не более, чем косметическим.

  • Kotlin для Android: Теперь официально
    +1
    например благодаря тому, что котлин дает полный контроль над тем, как API библиотеки выглядит со стороны джавы

    Ну даже "из коробки" тот API, который Kotlin отдаёт Java, выглядит достаточно удобным и естественным, за исключением классов, оканчивающихся на Kt, и необходимости явного обращения к companion object. Обе претензии больше эстетические, чем концептуальные, да и возникают подобные ситуации не очень часто.

  • Kotlin для Android: Теперь официально
    +6

    Ну это интересный вопрос. Я, как один из разработчиков языка, должен бы по идее защищать язык. Однако, скажу честно: я не знаю. Я так понимаю, просто есть разные люди с разным мировосприятием, кто-то хочет стабильности и надёжности (и поддерживаемости кода конченными индусами), кто-то хочет чего-то с приятными синтаксисом. Так что пусть на вопрос "зачем" отвечают разработчики для самих себя. Как мы видим, достаточно большая часть разработчиков нашла ответ на этот вопрос, и Google даже пришлось пойти им навстречу.


    Для себя я придумал такое объяснение, зачем мы делаем Kotlin — чтобы дать людям выбор. Ну и ещё одно — чтобы у людей была возможность писать fullstack-приложения. В мире JS есть node.js, почему в мире Java нет fullstack-решения? Есть GWT, но он в последнее время тихо загибается, плюс это сторонний инструмент от стороннего разработчика, а не официальная технология от разработчиков Java. Мы же в Kotlin координируем усилия между командами, разрабатывающими JVM, JS и Native бэкэнды. А некоторые внутренние продукты JetBrains уже пишутся на fullstack Kotlin.


    когда есть обкатанная Java c миллионом библиотек и готовых решений под неё

    Ваша ошибка в том, что эти библиотеки "для Java". Это не так, Kotlin прекрасно работает с библиотеками, созданными специально "для Java"

  • Пробуем делать web-frontend на Rust (WebAssembly)
    0

    Сборщик мусора можно и свой написать. Я уже частично портировал свой Java-JavaScript компилятор в WebAssembly: https://github.com/konsoletyper/teavm

  • «Скорее всего, будет расти как снежный ком» — Андрей Бреслав и Антон Кекс о Kotlin
    –1

    Внутри у любого современного компилятора есть IR, да не один. У Java это — байт-код, у LLVM — биткод или текстовый IR, у gcc — какой-нибудь gimple и т.п. Над IR, в виду его простоты, достаточно тривиально делать подобные трансформации. В Kotlin есть свои IR, но они ещё не устаканились, так что мы пока не публикуем их. В данный момент трансформация в state-машины в реализации корутин для JS и JVM делается по-разному, возможно, когда-нибудь мы сделаем универсальную трансформацию. Основная проблема в том, что на уровне байт-кода (или любого подобного представления) трансформация делается тривиально, а на уровне AST (который удобен для генерации JS) та же трансформация выглядит значительно менее тривиальной, и оставляет в коде значительно больше мусора.


    Вообще, наличие простого как пробка байт-кода у Java — это то, за что я так люблю эту платформу. Стоит лишь не полениться его выучить, овладеть такими инструментами как asm, и можно творить такую магию, что никаким lisp не снились (к сожалению, очень мало разработчиков знают о такой киллер-фиче и умеют её правильно готовить). По опыту работы с JS, как с целевой платформой, для него как раз такой фичи очень не хватает. Надеюсь, мы когда-нибудь дойдём до того, что сделаем этакий платформо-независимый kotlin bytecode.

  • «Скорее всего, будет расти как снежный ком» — Андрей Бреслав и Антон Кекс о Kotlin
    0

    Вообще-то, JVM хорош тем, что синтаксис новый не нужен — достаточно просто поинструментировать байт-код. Собственно, мы в Kotlin так и делаем (аналогично делает какой-нибудь quasar).

  • Встречайте Kotlin 1.1: JavaScript, корутины и многое другое
    0

    Как раз одним из главных приоритетов при разработке корутин и была бесшовная интеграция с существующими библиотеками. В отличие от .NET, Kotlin не привязывает реализацию корутин к конкретным классам вроде Task. suspend-функцию можно написать для любой имеющейся библиотеки.

  • Встречайте Kotlin 1.1: JavaScript, корутины и многое другое
    0

    Вот мне кажется, что лучше уметь порождать точный source map, чем стремиться к 100% читаемости сгенерированного кода. А для тех случаев, если всё же пришлось подебажить сам сгенерированный код, мне кажется, Kotlin порождает достаточно читаемый код.

  • Встречайте Kotlin 1.1: JavaScript, корутины и многое другое
    –1
    Kotlin же тянет с собой мегабайтную библиотеку

    Я же уже писал — мы постепенно решим эту проблему


    в генерированном коде черт ногу сломит

    А можно про это поподробнее? Что именно непонятно в коде? Кроме очевидных вещей вроде манглирования идентификаторов (что на мой взгляд не сильно страшно) назовите хотя бы несколько пунктов.


    Далее, а зачем генерируемый год должен быть читаемым? Вы часто смотрите на машинный код, сгенерированный каким-нибудь gcc?


    Кроме того, TS на порядок проще.

    И про это можно подробнее? Опять же, хотя бы несколько пунктов.

  • Встречайте Kotlin 1.1: JavaScript, корутины и многое другое
    0

    Да, такие планы есть.


    видимо как раз из за того что не хватает информации о типах.

    В том-то и беда, что "видимо". GCC достаточно плохо работает на stdlib Kotlin, и пока не вполне очевидно почему. Возможно, дело в типах, возможно, в чём-то другом. Это вопрос требует исследования, и мы планируем потратить на них какое-то время.

  • Встречайте Kotlin 1.1: JavaScript, корутины и многое другое
    0

    WebAssembly ещё очень далеко до того, чтобы на нём сделать полноценную реализацию движка JS. Сейчас там нет ни GC (и сложно сделать свой, т.к. нет доступа к стеку), ни вообще какого-либо способа пропатчить код в рантайме или повыставлять защиту страниц памяти.


    По поводу эффективности бинарного формата в плане размера. Если интересно, у меня есть свой экспериментальный транслятор байт-кода Java в WebAssembly, вот работающий пример приложения. Так вот, размер JavaScript — 274 кб, размер WebAssembly — 488 кб.

  • Встречайте Kotlin 1.1: JavaScript, корутины и многое другое
    0

    Предполагается, что можно будет и так и так

  • Встречайте Kotlin 1.1: JavaScript, корутины и многое другое
    0
    Тут все просто — Frontent разработчики используют React/NG2/Vue и тд. Зачем им GWT и подобные абстракции? Все и так отлично.

    Во-первых, я же уже сказал — ИМХО, компилятор из Kotlin в JavaScript больше нужен Kotlin-разработчикам, которые захотели ещё писать фронтэнд, а не фронтэнд-разработчикам, которые уже счастливы с JS.


    Во-вторых, если так мыслить, то вообще никогда ничего нового не будет появляться. В 80-е разработчики прекрасно жили с Cobol. А сейчас люди прекрасно сидят на Java, так что, теперь из этого следует, что Kotlin не нужен? Нет, оказалось, что на это есть какой-то спрос, нашлась ниша. Возможно, найдётся ниша для компилятора в JavaScript. Пока самая очевидная — это та, которую я назвал, но реальность как всегда такова, что выстрелить язык может там, где никто этого не ожидал. Глупо не попытаться использовать шанс, если он есть. Ведь хуже будет, если Scala.js выстрелит, в этом случае Kotlin придётся запрыгивать в уходящий поезд.


    Еще и WebAssembly завезли

    А это вообще мимо кассы. WebAssembly — это средство для бородатых дяденек, пишущих на C и C++ запускать свои шустрые программы в браузере. Мне кажется, пересечение с "традиционным" фронтэндом и всей его экосистемой — минимальное. Вот это отличный шанс туда запрыгнуть новым многообещающим языкам.

  • Встречайте Kotlin 1.1: JavaScript, корутины и многое другое
    0
    JavaScript без своей экосистемы — не очень вкусен.

    GWT прекрасно живёт в своей экосистеме. Сборка — Maven, хранилище артефактов — тот же maven central или jcenter, линтеры — checkstyle и PMD, библиотеки и фреймворки — специально написанные для GWT или портированные с "большой" Java, либо обёртки вокруг JS-ных библиотек. Минификацию делает сам (причём сильно лучше новомодных webpack-ов), модульность на уровне модулей Maven.


    Постоянно поддерживать интеграцию с ней то же мало приятного.

    Мне кажется, это утверждение из разряда "у страха глаза велики". Там достаточно много всего, но интегрироваться с этим не так сложно, есть вещи более-менее устоявшиеся. Ну и да, всё "быстро меняется" в восторженных статьях на Хабре, а весь мир по-прежнему сидит на jQuery.


    Со стороны это похоже на попытку сделать универсальный инструмент для всего и всех.

    Нет, это попытка сделать инструмент для тех, кто хочет fullstack на Kotlin. Кому нормально писать фронтэнд на JS, тот и дальше будет писать на JS.

  • Встречайте Kotlin 1.1: JavaScript, корутины и многое другое
    +1

    Разумеется, так сделать можно, и на первых порах мы возможно так и поступим. И тут придут апологеты TypeScript и начнут сравнивать размеры npm-пакетов. В перспективе, возможно, удастся скомпилировать kotlinc с помощью какого-нибудь AOT-компилятора или полностью вырезать из компилятора все зависимости от Java.

  • Встречайте Kotlin 1.1: JavaScript, корутины и многое другое
    0

    Насчёт Silverlight не знаю, а вот GWT я успешно использовал в production на протяжении трёх лет и очень был доволен. Но у GWT есть фатальный недостаток — он не понимает Kotlin. Хочу пояснить — я хорошо знаю JavaScript и вполне способен писать приложения на каком-нибудь Angular. Проблема в том, что я этого делать не хочу:


    1. Мне JavaScript банально меньше нравится.
    2. Язык — это не только сам язык, но и ещё целая куча технологий вокруг него — библиотеки, системы сборки, IDE, линтеры и т.п. Лично мне неприятно всё время переключать в голове контекст с одного на другое. Да и объём знаний там немаленький, пришлось кучу времени потратить, чтобы переключиться с Java на JavaScript. И собственно язык — это пара дней работы, вся остальная куча времени пришлась на ту самую пресловутую экосистему.
  • Встречайте Kotlin 1.1: JavaScript, корутины и многое другое
    +5

    Жертвы действительно есть:


    1. Компилятор (пока) работает на JVM, соответственно, чтобы полноценно компилироваться в JS, не хватит только node.js/webpack, нужно ещё ставить JVM. Для JS-разработчика, у которого стоит нода, но не стоит JVM, это может стать препятствием.
    2. У нас (пока) нет лоадера для webpack. Т.е. нужно настраивать gradle для компиляции Kotlin и webpack для всего остального. Это, конечно же, не касается пользователей какого-нибудь google closure compiler.
    3. Система типов Kotlin изначально проектировалась с прицелом на JVM, система типов TypeScript — с прицелом на JS. В итоге, не всегда Kotlin так же хорошо ложится на JS, как TypeScript. Например, в Kotlin поддерживается перегрузка функций по типу параметров, чего нет в JS (и следовательно, в TS). Таким образом, по умолчанию Kotlin при компиляции функций с параметрами дописывает к их названию некий суффикс, полученный страшным алгоритмом. Конечно, есть аннотация @JsName, которая позволяет явно задать имя функции в JS. Другой пример — отсутствие union types в нашей системе типов.
    4. Мы тащим с собой жирный рантайм (1,2 мб), и (пока) не умеем из него вырезать неиспользуемые части.
    5. Мы (пока) не умеем компилироваться инкрементально.

    Как видите, часть проблем здесь из разряда "пока не успели сделать" (в основном по тулингу, у нас 1.2 как раз будет на нём фокусироваться), а часть "ничего нельзя поделать". В первом случае надо подождать, во втором — мы пытаемся минимизировать боль от последствий.


    Если у кого-то есть что-то ещё добавить к списку — пожалуйста, отписывайтесь к комментам, мы будем рады перечисленные недостатки устранить.

  • Встречайте Kotlin 1.1: JavaScript, корутины и многое другое
    +2

    Я так понимаю, возможность писать на одном языке бэкэнд и фронт-энд для Android, iOS (скоро) и веба. TS компилируется только в JS. Конечно, можно TS на ноде гонять, но не всем подходит нода. Опять же, можно TS гонять на Cordova/React Native, но нативное приложение должно шустрее работать. Плюс синтаксические вкусности, которых нет в TS:


    • declaration site/use site variance;
    • нелокальные return-ы (например, можно взять и сделать return из вызывающей функции прямо из лямбды, переданной в функцию map);
    • смарткасты;
    • богатые возможности для построения DSL;
    • навороченные корутины

    Ну и не забывайте про тех пользователей, которые уже используют Kotlin на JVM, и хотят на нём же писать и веб-клиент (либо с нуля, либо переписать на нём имеющийся JS-клиент).


    В принципе, тот факт, что мы не сможем поспеть за TS в плане лёгкости интеропа и тулинга (да и TS уже банально прочно занял нишу), лично мне понятен. Мой персональный приоритет — это создание именно такого языка, который позволял бы легко бы писать fullstack-приложения. К сожалению, это пока не совсем так, но я надеюсь, мы движемся в правильном направлении и скоро Kotlin станет полноценным языком для fullstack-разработки.


    С другой стороны, мы не сможем перегнать TS, но нам есть, куда расти. Задачей к 1.1 было стабилизироваться, т.е. задизайнить минимальный набор необходимых фич, причём так, чтобы потом не ломать совместимость. Ну и конечно, пофиксить баги и реализовать недостающие языковые фичи, доступные в Kotlin JVM. Некоторыми вещами в интеропе пришлось пожертвовать (например, теми же строковыми enum-ами), но никто не мешает их сделать к следующим версиям языка.

  • Встречайте Kotlin 1.1: JavaScript, корутины и многое другое
    0

    (промахнулся)

  • Встречайте Kotlin 1.1: JavaScript, корутины и многое другое
    +1

    В документации не раскрыта вся суть. А суть в том, что корутины в Kotlin не привязаны ни к конкретным библиотеками, ни к конкретным типам. async/await из примера — это просто библиотечные функции, можно писать свои для различных фреймворков. И ещё — generate/yield — это тоже библиотечные функции, реализованные поверх того же механизма корутин. Подчеркну, что там нет никакой внутренней магии специально для разработчиков stdlib, кто угодно может написать свои реализации generate/yield и async/await.

  • Встречайте Kotlin 1.1: JavaScript, корутины и многое другое
    +2
    Чего можно ждать в обозримом будущем от KotlinJS?

    Инкрементальной компиляции, минификации aka dead code elimination (так же известный под названием tree shaking, которое меня немного выбешивает), куча примеров кода, работающего с современными фреймворками (такими, как React) и документации. Это совсем ближайшее время, буквально несколько месяцев. Дальше пока не планировали (или по крайней мере, я не в курсе). Так же надеюсь, что будет время немного улучшить интероп, например, завести правильные external enum. Ещё есть пользователи, которые очень хотят генерацию микромодулей и ES6, мы держим это в голове, и активно обсуждаем, но конкретных сроков у нас сейчас нет.


    Ещё в Kotlin есть такой минус, что достаточно неудобно разрабатывать проект, в котором есть общая кодовая база между JS и JVM. Этот момент непосредственно к JS не относится, там больше по части общекомпиляторной работы и всякого тулинга. Я так понимаю, что мы над этим будем работать в ближайшее время, но по срокам пока непонятно, скорее всего, в обозримом будущем удастся выпустить common-модули в экспериментальном режиме.


    Будет ли возможность помечать методы интерфейса как уже реализованные?

    Не вполне понятно, что вы понимаете под этим. Можете пример из мира JS (и по возможности, пример деклараций в TS)?


    Библиотека kotlin.js — 1Mb, планируется ли существенно сократить его размер?

    Сократить — нет, подружить вывод компилятора с различными минификаторами или разбить на кусочки поменьше — возможно. Конечно, мы понимаем, что такая здоровенная библиотека — это плохо. Кстати, после uglify она где-то в 2 раза ужимается, а после gzip и того более.


    Возможен ли будет вариант, когда только нужная функциональность будет реализована напрямую в финальном js-файле? К примеру, чтобы Hello World не тянул за собой метровую зависимость, а все нужное содержал уже внутри.

    Зачем, если для этого есть стандартные инструменты? У нас в JetBrains для внутренних разработок успешно используют Kotlin в связке с webpack, Kotlin компилирует, webpack — пакует. Как-то нелогично тянуть в компилятор линковку. Есть какая-то небольшая вероятность, что мы захотим написать свой бандлер, но в ближайших обозримых планах ничего такого нет.

  • Как работает hashCode() по умолчанию?
    0

    Ну а толку-то? По сути, не нужен для этого никакой цикл. Это будет эквивалентно какому-нибудь if..else if… else. На уровне синтаксиса это можно подсахарить. Вон, в Kotlin есть when, который по сути является сахаром для if..else if. Но чуда не ждите, на рантайме от этого быстрее не станет. Когда в Java 7 вводили switch по строкам, задизайнили фичу так, чтобы её можно было эффективно реализовать.

  • Как работает hashCode() по умолчанию?
    +1

    Я так понимаю, это всё-таки не документируется в спеке языка. Т.е. компилятор может реализовывать switch по строкам в принципе как ему захочется. А вот в JDK это поведение чётко описано. Просто так особенности реализации в javadoc-ах не описывают, т.е. именно такой способ вычисления String.hashCode — это всё-таки публичный контракт. Учитывая особенности публичного контракта JDK, компилятор может порождать эффективную реализацию (что и делает javac).

  • Как работает hashCode() по умолчанию?
    0

    Что "делается"? Инстанс объекта создаётся? Нет, ничего не создаётся, но вычисление hashCode требует знания, какое у объекта внутреннее состояния. Без знания логики конструирования объекта о внутреннем состоянии судить нельзя, следовательно невозможно вычислить hashCode.


    Зачем компилятору вычислять hashCode? А как он сгенерит такое:


    switch (str.hashCode()) {
        case FOO_HASHCODE: if (o.equals("foo")) { ... } else goto default;
        case BAR_HASHCODE: if (o.equals("bar")) { ... } else goto default;
        default: { ... }
    }

    Ну хорошо, мы можем и дальше так продолжать играть в вопросы. Давайте так, если есть что предложить — предлагайте (и даже можете кинуть JSR в JCP). Только не в духе "хорошо было бы сделать", а в духе "как ИМЕННО сделать" с учётом разных нюансов. Я уверяю, при попытке сформулировать предложение вы сами всё поймёте.