Планы команды IntelliJ Platform на 2020 год

[xRay]

С Java перепишете IntelliJ Platform на C++, Rust?

[germn]

C++, Rust — зачем такие медленные языки? Надо сразу на ассемблере переписывать.

[xRay]

Это была шутка

[ShashkovS]

например, мы создали и задействовали стандартный механизм асинхронной обработки событий от файловой системы

А вот скажите, это у одного меня такая проблема, или это общее:
иногда я хочу открыть какой-нибудь проект или файл. Для этого открывается кастомное IntelliJ-окно со структурой папок-файлов. Но оно открывается несколько минут. И даже если я в точности знаю путь к файлу, или тупо передумал, оно блокирует UI и пару минут что-то сканирует. Да, у меня там папка с проектами и там фигова туча подпапок и файлов. Но не надо туда внутрь лезть до того, как явно попросят.
Могу гифку сделать.

[Vest]

… или хотя бы несколько thread dumps… к гифке будут полезны…

[ShashkovS]

Неправильно написал. UI не блокирует. Не даёт ничего открыть (даже если знаешь точный путь) или сменить текущую папку на другую, пока не подождёшь минутку-другую. Окно можно закрыть и открыть заново, но снова придётся ждать.

[Vest]

теперь лучше, а можно thread dump? Может быть у вас антивирус крутится и препятствует обращению к файлам.

[Maccimo]

Не у одного.
Быстро открыть диалог, вставить путь из буфера обмена и сразу нажать на «ОК» — сейчас это что-то из области фантастики.

Всегда присутствует дополнительный этап «мы будем долго шуршать диском и строить никому не нужное дерево».

Если сильно не повезёт, то случается ситуация «что-то я в своём дереве такого пути не вижу, идите лесом». Пока диалог не найдёт введённый путь в своём дереве, через «ОК» его закрыть нельзя, только через «Отмену».

[Vest]

Я не из JetBrains, мне просто стало интересно. У меня не получается воспроизвести вашу ситуацию. Максимум, что я заметил, так это то, что диалоговое окно (см. выше) может обращаться к файлу для построения его иконки… Вы бы смогли сделать парочку тред-дампов?

[Vadem]

Загрузка и выгрузка плагинов без рестарта

Вот эту штуку очень бы хотелось увидеть.

[orionll]

Первый раз слышу, чтобы Eclipse позволял перезагружать плагины без перезагрузки. Любая установка плагинов / обновление Eclipse показывает окно с просьбой перезагрузки.

[FruTb]

> Во-первых, мы планируем поддержать готовые фрагменты индекса. Теперь вместо того, чтобы каждая копия IntelliJ IDEA заново индексировала класс java.lang.String, мы сможем предоставить для скачивания готовый фрагмент индекса для JDK, который можно будет переиспользовать без дополнительных затрат CPU

может стоить глянуть в сторону того как bazel свой расаредеоенный кеш организует?

[puyol_dev2]

С индексацией у вас и правда какая-то хрень. Даже крошечный проект индексируется несколько десятков секунд

[MIKEk8]

Теперь вместо того, чтобы каждая копия IntelliJ IDEA заново индексировала класс java.lang.String, мы сможем предоставить для скачивания готовый фрагмент индекса для JDK

То есть вне зависимости от размера вашего проекта IDEA индексирует и стандартные библиотеки, что скорей всего и занимает эти десятки секунд.

[Marahal]

У меня есть предложения:
1. У вас в планах окружение для выполнения. Это очень хорошо. Можно ли еще добавить туда возможность, чтобы исходники лежали на сервере и сборка и компиляция могла быть тоже на сервере. То есть было бы «Окружение для сборки и выполнения». Или добавить «окружение для сборки». Чтобы собрать часто приходится настраивать окружение, если работаешь с разных компьютеров. Удобно настроить его на сервере, положить туда проект, а работать с ним с IDE с компьютера дома или на работе или коллега может туда зайти и т.д.

2. Многие хотят быстрый запуск. Сейчас появилась концепция compile time инициализации, то есть когда объекты инициализируются при компиляции, а во время выполнения грузится сразу область памяти целиком. Например, запуск Quarkus native приложения может занимать 0.001 секунды. Для компиляции используется GraalVM. Тут будет проблема с плагинами, но и для нее есть варианты решения. Мне кажется, направление перспективное.
Большое спасибо за внимание.

[yole]

Про поддержку работы с проектами, где исходники лежат только на сервере, мы пока не готовы ничего анонсировать. Понятие «окружение для сборки» имеет смысл далеко не для всех проектов — сборка большинства Java проектов не зависит от окружения, а для Ruby/Python/PHP собирать часто вообще ничего не надо — поэтому у нас нет планов вводить такое понятие на уровне платформы.

На GraalVM мы конечно смотрим, но пока что мы не видим такого соотношения cost/benefit, которое оправдывало бы серьезные в него вложения.

[yole]

Как сказано в посте, мы пока что не готовы анонсировать какие-либо планы в этой области. :)

[Blekel]

Выглядит довольно хорошо. Желаю удачи в реализации планов в новом году!
И поменьше CPU Usage в IDE тоже. )

Было бы здорово увидеть подобный план от команды ktor.
А то на бумаге выглядит хорошо (только дока простовата), а при переписывании относительно небольшого проекта со Spring Boot на ktor — испытываешь кучу проблем на стадии мелочей, которых после такого срока разработки, казалось бы, — уже не должно быть.

Например, фичи поддержки Tomcat и Thymeleaf по-отдельности реализованы, но вот вместе это все работает пока на честном слове:

• приходится хардкодить контекст приложения во вью, если не делать мэппинг на фронте на отдельный поддомен — потому что в объекте фичи Thymeleaf контекст создается тупо через Context(), который не совместим с IWebContext;
• основной сервлет падает при редеплое war в локальный Tomcat;
• и т.п.

А так вообще, подход более явного application setup — очень хорош относительно других микрофреймворков.

[cy6erGn0m]

Откройте, пожалуйста, тикеты, описывающие эти проблемы в github.com/ktorio/ktor/issues. Все предложения и пожелания есть смысл описывать там.

Подробный план на данный момент нигде не опубликован, однако, основные планы вокруг коммонизации (Kotlin Multiplatform) сервера и более тесной интеграции с kotlinx.serialization.

[lasc]

А что там с чтением .ssh/config еще пяток лет подождать?

[e_v_genius]

Хочу просто поблагодарить за лучшую, с моей точки зрения, IDE для разработки. Большое вам спасибо, ребята!

[spontaliku]

Не планируете перестать релизить версии с известными мажорными багами ломающими процесс тысячам пользователей?

[yole]

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