Можно попробовать и запустить приложение на iOS совсем без Swift, например https://github.com/AlexGladkov/TeslaApp-Compose-Mpp, Но команда Jb дропнула поддержку такого подхода, видимо у них были на это веские причины.
Можно и без Swift. В подходе выше проект XCode генерируется на лету. Подход оказался мало-жизнеспособным, потому что у проекта XCode очень много настроек, которые очень сложно поддержать на уровне градл плагина. Проще держать проект xcode внутри compose проекта, чтобы ничем не ограничивать разработчика в конфигурации xcode проекта (а также в выборе инструментов -- нативные отладчики, профилировщики). Держать Swift код в этом случае кажется логичным. Никто его не заставляет править/писать, но это может потребоваться в будущем, если к примеру захочется обернуть композное приложение нативной iOS навигацией. Если в будущем мы увидем, что в большинстве случаев разработчики не трогают xcode обертку вообще (или трогают как-то одинаково) и 100% кода пишут в common коде, конечно мы для них предоставим соответствующий тулинг, скрывающий конкретные платформы по максимуму. Но на данный момент кажется что до этих 100% еще очень далеко
Понятно, что никто в здравом уме не примет такой патч в OpenJDK, я даже пытаться не буду. Но никто не мешает сделать это у себя локально. Конечно, я не даю никаких гарантий, что оно будет правильно работать у вас!
Если правильно оформить JEP и еще немного подумать как сделать красиво, то вполне наверно можно было бы решение задачи "понять откуда ссылка на метод" засунуть в апстрим OpenJDK. Но понятно это время потребует поболее чем давай-ка побыстрому захачим (с другой стороны ты же уже потратил время на статью :). Если вдруг патч станет популярным сам по себе может и JEP появиться сам по себе.
Проблема GraalVM native image — это closed world assumption, когда сразу предполагается, что в рантайме мы ничего нового грузить не будем, а что вообще в принципе будем, вычисляем через замыкание потока управления. Этому подходу очевидно мешает и reflection и динамическая загрузка — статически замкнуть в присутствии reflection — невозможно. У Excelsior JET то же был давно (15 лет назад) оптимизатор на основе предположения замкнутости мира. Практика показала, что подход совршенно нежизнеспобоный для Java — ваши примеры в этом коментарии это наглядно показывают, только это было известно еще 15-20 лет назад. Однако AOT может жить и не полагаясь на CWA, давая сравнимые результаты с CWA по стартапу и футпринту с одной стороны, а с другой полностью соответсвуя спецификации ( то есть и рефлексия и динамическая загрузка — просто работают без всяких конфигурационных файлов). Возвращаясь к вашей презентации — предлагаю переформулировать тезис — «Reflection — нет AOT компиляции», в „Reflection — нельзя замкнуть мир заранее (плохо работает GraalVM native image)“.
a_belyaev, вот сколько можно все-таки повторять миф — «Reflection — нет AOT компиляции»?
Reflection совершенно не противоречит AOT компиляции. Можете по этому поводу посмотреть мой доклад про «AOT компиляцию SpringBoot», где я эту тему разжевал как никогда ранее подробно. Все чему противоречит Reflection — это AOT-компиляции Java приложений в предположении закрытости мира — в присутствии reflection теоретически нельзя определить границы закрытого мира. И уменьшение рефлексии этой проблеме не очень помогает: пока рефлексия есть и используется, закрывать мир — небезопасно, а значит имеет мало смысла с практической точки зрения
Только, если большая часть кода джитуется. Если убедиться, что все компилируется, то теплый старт быстрее в любой редакции. Со стартап оптимизациями (которые есть только в платных версиях), холодный старт тоже сильно быстрее (оптимизации и теплый старт тоже разгоняют). Также замечу, что на SSD разница между теплым и холодным стартом не так заметна, как на HDD.
Только не говори, что ты первый раз слышишь про бесплатный JET. Standard Edition для x86 у нас уже года 2 бесплатный. Совсем. И Spring Boot работает на бесплатной версии в classpath режиме.
>>Ну наверное, если у вас есть купленный JET, это ещё и чисто рабочий вопрос,
>>но у меня такового пока нет.
Для таких как ты в конце была ссылка на бесплатный JET :)
Я говорю про то, что две версии одной библиотеки все еще может приводить к проблемам в OSGi. Проблемы возникают когда эти две версии проползли в сигнатуры других бандлов и теперь вам эти бандлы надо подружить (заиспользовать одновременно, или заиспользовать саму библиотеку, когда она проползла в сигнатуры другого бандла). Если бандлы ваши, то придется серьезно порефакторить, если чужие заниматься оборачиваниям их или еще чем-то. Диагностика этой проблемы может быть уже не простым делом, решение еще более не простым. Почитайте статью одного из авторов OSGi на эту тему (я ссылку на нее давал в слайдах) — njbartlett.name/2011/09/02/uses-constraints.html
Почему не исследовался метод CTRL-ALT-L?
Я уже двести лет никакие отступы руками не ставлю, их вставляет IDE согласно командным правилам форматирования кода.
В правилах же как правило используются пробелы, потому что дифы проще читать.
К тому же warmup — это не только время, которое печатается в строчке «Server startup in»: туда не входит время поднятие самой JVM, что для непрогретой JVM может быть существенным и не входит время, которое потребуется, чтобы ваше приложения начало работать в полную силу: для этого надо возможно еще пособирать профиль, покомпилировать. В конце концов JIT'у не всегда хватает ресурсов, чтобы даже горячий код оптимизировать максимально эффективно. Плюс те оптимизации, что он применяет, часто спекулятивны и при небольших изменениях в окружающей среде система неожиданно может уйти в интерпретатор со всеми вытекающими.
Можно и без Swift. В подходе выше проект XCode генерируется на лету. Подход оказался мало-жизнеспособным, потому что у проекта XCode очень много настроек, которые очень сложно поддержать на уровне градл плагина. Проще держать проект xcode внутри compose проекта, чтобы ничем не ограничивать разработчика в конфигурации xcode проекта (а также в выборе инструментов -- нативные отладчики, профилировщики). Держать Swift код в этом случае кажется логичным. Никто его не заставляет править/писать, но это может потребоваться в будущем, если к примеру захочется обернуть композное приложение нативной iOS навигацией. Если в будущем мы увидем, что в большинстве случаев разработчики не трогают xcode обертку вообще (или трогают как-то одинаково) и 100% кода пишут в common коде, конечно мы для них предоставим соответствующий тулинг, скрывающий конкретные платформы по максимуму. Но на данный момент кажется что до этих 100% еще очень далеко
Если правильно оформить JEP и еще немного подумать как сделать красиво, то вполне наверно можно было бы решение задачи "понять откуда ссылка на метод" засунуть в апстрим OpenJDK. Но понятно это время потребует поболее чем давай-ка побыстрому захачим (с другой стороны ты же уже потратил время на статью :). Если вдруг патч станет популярным сам по себе может и JEP появиться сам по себе.
Reflection совершенно не противоречит AOT компиляции. Можете по этому поводу посмотреть мой доклад про «AOT компиляцию SpringBoot», где я эту тему разжевал как никогда ранее подробно. Все чему противоречит Reflection — это AOT-компиляции Java приложений в предположении закрытости мира — в присутствии reflection теоретически нельзя определить границы закрытого мира. И уменьшение рефлексии этой проблеме не очень помогает: пока рефлексия есть и используется, закрывать мир — небезопасно, а значит имеет мало смысла с практической точки зрения
>>после 18 лет успеха на рынке просто исчезнет?
Да, все верно
>>но у меня такового пока нет.
Для таких как ты в конце была ссылка на бесплатный JET :)
В каком ещё полу_шар_ии? Вы о чём?
Я уже двести лет никакие отступы руками не ставлю, их вставляет IDE согласно командным правилам форматирования кода.
В правилах же как правило используются пробелы, потому что дифы проще читать.