Почему JVM —это ОС и больше чем Кубер

    Я давно работаю с платформой Java и прекрасно знаю её сильные и слабые стороны. В этой статье я хочу рассказать, как могла бы повернуться история, если бы не бы. Ведь мы могли бы вместо докер-систем использовать ява-машину. А сама ява-машина вполне могла целиком заменить ОС.

    Это обзорная статья, я лишь изложу несколько соображений. Полный их разбор занял бы очень много места.

    Итак Ява-машина — это ОС. Даже круче чем ОС местами. На самом деле это не такое уж заявление из ряда вон. Ведь всем прекрасно известен пример полноценной ОС, значительно основанной (изначально) на Ява – Андроид. Кроме того, существуют и ОС в классическом понимании полностью на базе JVM.

    Итак, какие признаки ОС мы имеем у JVM? Управление памятью - несомненно. Управление потоками - да, но как правило на базе существующих местных потоков базовой ОС. Тем не менее, потоки являются важной неотъемлемой и очень развитой подсистемой машины, предоставляя гораздо больше сервисных средств, чем базовые потоки ОС.

    Ввод-вывод также очень развит, если иметь в виду всю инфраструктуру Ява, со всеми серверами и библиотеками. В этом смысле ввод-вывод базовой ОС - примерно как старый Биос для последней, осуществляет низкоуровневые операции.

    У Ява есть философия. Если в Юникс - всё файл, то в Ява всё (почти) есть объект.

    Есть важная часть системы, про которую многие либо не знают, либо забывают. Ява – среда с мощнейшими средствами разграничения доступа. Именно поэтому в том числе её широко применяют в банковской сфере.

    Наличие этих средств вкупе с полноценной многопоточностью на уровне языка создаёт предпосылки для создания многозадачной И многопользовательской среды исполнения. Про многопоточность знают многие. Что касается разграничения доступа, остановимся подробнее.

    Во-первых, JVM – управляемая (managed) среда. Это не только означает безопасность исполнения кода. Это также модель разграничения, аналогичная выделению ядра в большинстве ОС в отдельный контекст привилегированного исполнения. Т.н. нативный контекст исполнения, в котором работает сама машина - прямой аналог реального (или подобного) режима исполнения процессором ядра ОС. Сама машина имеет полный контроль над всеми процессами внутри неё. Байт-коду достаётся уже сильно ограниченная, защищённая среда. Степень свободы загружаемого байт-кода определяется Ява-машиной и её рантайм-библиотекой.

    Иерархия загрузки в эталонной реализации сервера приложений
    Иерархия загрузки в эталонной реализации сервера приложений

    Более того, сам механизм загрузки байт-кода (классов в первую очередь) иерархичен и подразумевает разделение прав и ответственности – ветвление прав. Это ветвление достигается за счёт применения отдельных загрузчиков классов. При этом создаётся иерархия областей видимости, код, загруженный в одном контексте не имеет доступа к другому независимому контексту. При этом нельзя получить указатель на произвольную область памяти, нет доступа к произвольным полям объектов, даже через механизм рефлексии, даже к целым отдельным объектам. Этот механизм встроен в язык (ключевые слова private, protected и т.п.) и в платформу – уже названные загрузчики и конечно менеджеры безопасности, о которых тоже не забудем. Такие механизмы обеспечивают разделение контекстов выполнения аналогично процессам классических ОС. Я бы даже сказал более строгое и надёжное разделение. Загрузчики классов совместно с менеджерами безопасности (SecurityManager) обеспечивают полный контроль над тем, что может попасть внутрь среды исполнения Ява, а что не может. Механизм этот необычайно гибкий. При этом, в отличие от нативного кода, загружаемый байт-код проходит полную проверку на валидность (он не может затем вызвать непредсказуемый сбой) и безопасность - так как возможные варианты поведения ограничены теми же загрузчиком+менеджером безопасности. Вы слышали когда-нибудь о вирусах на Яве?

    Для больших систем вышеописанный механизм хорошо согласуется с модульностью и плагинным подходом. При этом, как я уже сказал, эта плагинная система значительно защищённее аналогов, т.к. плагины могут вести себя как отдельные приложения. Яркий пример - OSGi.

    Здесь стоит отметить, что все вышеуказанные черты существуют в рамках всего одного процесса. Это позволяет не использовать сложные, рискованные и дорогие механизмы межпроцессного взаимодействия. С другой стороны есть один из главных недостатков ява-машины, до последнего времени неслабо портивший бочку мёда – большая общая куча со сборкой мусора. Но новое поколение сборщиков почти полностью устранило этот недостаток, позволяя запускать Ява машины с кучей в десятки гигабайт.

    Круче чем кубер

    Почему Ява-машина круче чем кубер? Потому что, как я уже сказал, она позволяет создавать множество независимых изолированных контекстов – читай пространств имён – на базе общего ядра Ява-машины и рантайм-библиотеки. И эти пространства могут настраиваться более гибко, обеспечивая различные уровни изоляции (доступа). Они могут дополнительно компоноваться. Отличным примером этого являются мощные сервера приложений. Они предлагают всё то, что обещает нам докер и его оркестраторы – отказоустойчивость, балансировка нагрузки, отличная модульность (суть микросервисности), сервисы и веб сервисы и даже самые микро и нано-модули – лямбды в виде супер легковесных ejb, решение проблем совместимости версий библиотек, удалённый вызов процедур в качестве альтернативы protoBuf & gRPC – RMI и его развития Corba & RMI-IIOP. И это всё в виде стандартов и множества реализаций.

    Единственное, чего не хватает - красивых картинок и графиков (хотя тут от реализации зависит) и развёртывания инфраструктуры из нарисованной диаграммки. Но последнее и в коробку с Кубером никто бесплатно не положит.

    И для иллюстрации посмотрим на стандартную модульность сервера приложений. Есть иерархия загрузки: система -> сервер -> приложение -> модуль приложения.

    Что ж, на этом пока всё. Порадуемся выходу очередной версии Jakarta EE 9 и пожелаем им успехов.

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 99

      –6

      И чо?

        –2
        и то
        +2
        Есть в этом логика, но JVM вряд ли сможет заменить докер, так как на докере можно запустить проекты написанные на других языках программирования типа python, go, php и т.д. Хотя и эту проблему стараются решить с помощью GraalVM, но пока он еще не созрел для замены докера. Может со временем он станет таковым. Но когда придет время это не будет супер фичей на мой взгляд. Слышал недавно что kubernetes вообще отказывается от докер тоже.

        Насчет OSGi… OSGi фигня какая та, и да, JVM плохо пока справляется с Hot Swapping'ом.

        Если ставить вопрос: JVM круче чем Docker? Ответ однозначно, да. Но… мы тут сравниваем яблоки с апельсинами.
          +1
          Насчёт памяти согласен. Это одна из больных проблем Ява-машины. Как и долгий старт. Ну а что вы хотите? Делать супернакрученную логику по загрузке классов и при этом не потерять в производительности?
          Я нарочно здесь пел хвалебные песни. Но я ведь отметил, что недостатков хватает. О них расскажут другие.
          На мой взгляд, в современных реалиях Ява может найти применение именно в виде легковесных лямбд, целиком грузить процессы слишком накладно. Причём для легких функций больше подойдут именно EJB, Spring в данном случае проигрывает как монолит и его уже вытесняют Quarcus и аналоги.
            +1
            Вы разве не знаете, что на OSGi построены Eclipse- и Netbeans- производные платформы? А ещё он в основе бортовых систем BMW.
              +3
              Знаю. Но OSGi все равно боль и в Intellij IDEA правильно сделали что не пошли по такому пути. Легче просто перезапустить IDE после установки плагинов чем такая реализация. Потому что мы очень редко устанавливаем плагины.
                0

                Это опять же смотря где. В GlassFish плагинами являются по сути сами приложения, если я ничего не путаю. И они устанавливаются при каждом деплое.

                  0
                  Хм. Вот у меня есть положительный опыт несколько лет работы с OSGI. Я его описал в одной статье, и вторая в черновиках. Не просто никакой боли, а наоборот — где-то сотни приложений в форме бандлов, по сути — микросервисы. Причем силами примерно четырех-пяти человек, с постоянным созданием новых, и поддержкой кучи старых.

                  Можно пруфчик про боль?
                    +1
                    Просто у меня был горький опыт реализации plugin-based GUI приложения на JavaFX через OSGi. Помню все время какие-то трудности возникали. Потом я забил на это и GUI часть просто написал на веб морде, а на Java только бэкенд часть.
                      0
                      Странно что вы делаете глубокие выводы из этого одного эксперимента. Для начала — GUI это наверное эклипс? Вы точно уверены, что это проблема OSGI, а не эклипса, потому что это сильно разные вещи?
                        0
                        Нет не эклипс, я на JavaFX фреймворке писал приложение. Помню что OSGi плохо дружил с JavaFX. Деталей не помню потому что это было давно.
                          0
                          Ну тогда не знаю. У меня не было таких приложений — у меня в общем чисто серверные вещи, типа ESB, если совсем обобщить. Вполне верю, что у GUI могут быть какие-то особенности (типа того, что UI обычно в одном потоке), но совершенно не вижу, какие из них могли бы реально мешать, потому что OSGI на архитектуру (в смысле числа потоков и их назначение) никаких ограничений в целом не накладывает.
                      +1

                      *пикосервисы. Официально бандлы называются пико-, а не микросервисами. И, как мне кажется, не просто так:
                      Проблема с OSGi в том, что с точки зрения масштабирования, эффективно это монолит. То есть никакого горизонтального масштабирования сервисов(по крайней мере, я не встречал такой возможности), только вертикальное.


                      Ещё одна проблема — нестабильность и ошибочные состояния. По моим внутренним ощущениям, вероятность, что при установке нового бандла ничего не сломается — 99%. При обновлении старого — 99.9%. Но если что-то сломается — последствия могут быть самыми разными.
                      Я встречал:


                      • "застрявшую" установку(лечится перезагрузкой)
                      • бандл включён, но не работает(лечится удалением и установкой)
                      • бандл написал, что переустановился, но на самом деле этого не сделал(удаление и установка, в лучшем случае ап версии)
                      • "osgi пошёл в разнос"(перезагрузка)
                      • всё приложение упало
                      • бандл не установился и его не возможно установить(перезагрузка)
                      • бандл сломал другой бандл из-за того, что по невнимательности у них оказалось одинаковое название (удалить ошибочный бандл после недель отладки).

                      Это то, что я вспомнил "прямщас" из своего опыта работы с Atlassian Confluence. Бандлы не зависели друг от друга, только от системных.
                      Конечно, при разработке десктопных приложений это не проблема, но если делать что-то с высокими требованиями к устойчивости и доступности (или, не дай бог, SLA 99.999), то OSGi(на мой скромный взгляд) представляет собой ужасное решение. Что бы они сами там не говорили.

                        +1
                        >никакого горизонтального масштабирования сервисов
                        Это в смысле кластер что-ли? Я вам скажу, что это не только встречается, но и весьма просто. Скажем, karaf + cellar = профит. Вариантов посложнее вообще куча.

                        Что до всего остального, то я не понимаю, как вам удается такие результаты получать. Никогда за много лет такого не видел, ни на карафе, ни на эклипсе. Может, проблема в самом конфлюенсе все же?
                          0

                          Хм. Благодарю. Похоже, у меня сложилось ошибочное мнение о масштабировании osgi-приложений.


                          Не удивлюсь, если описанные косяки — действительно проблемы конфы. Ну, или феликса, на котором построена конфа.


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

                            0
                            Да не, вряд ли феликса. Караф тоже строится на феликсе, и ничего. Ну разве что устаревшей и не обновляемой версии его — но тут я уже бессилен диагноз ставить по фотографии :)

                            Ну или это проблема тулинга, возможно. Скажем, вот это:

                            >бандл сломал другой бандл из-за того, что по невнимательности у них оказалось одинаковое название
                            Ну, вообще говоря, одинаковое название — это вполне штатно. При разной версии. Понятно что если ваших бандлов сотни — то выявить это может оказаться не так просто, но в карафе я бы это обнаружил скорее всего почти сразу. Там у конфлюенса вообще консоль есть, где можно было бы список бандлов посмотреть?
                +4

                И самое забавное что все это было еще со времен Java 6.


                Но приколы с патентами от Oracle, куча платных библиотек которые сегодня есть а завтра уже история и распространяются только в уже скомпиленном виде без возможности модификации, лагающий Eclipse на основе которого +100500 IDE. Сложность всего этого добра для освоения ( я еще студентом бросил Java в web после того как попытался понять web.xml от tomcat ) превращаются в лютый Ынтенпрайз от которого стынет кровь в жилах. Про JavaEE "hello world" только ленивый не шутил.


                Сейчас времена поменялись — есть Idea которая шикарна и позволяет компилироваться только ту часть байт-кода которая поменялась а не ждать 10 часов из за изменений в 2-х строчках, есть Android. OpenESB и Apachee Talend тоже шикарные вещи которые использовал. Для запуска одиночного сервиса не нужно долго подымать JavaEE сервер — достаточно упаковать его в тот-же docker.


                Только время уже упущено и на все это смотрят как на жуткое legacy а Oracle все еще пугает патентами. Тот-же Google вынужден платить, терпеть и пилить матерясь про себя свою Fuchsia.

                  +2

                  Меня всегда интересовало, почему разработчики яваее жалуются на долгий деплой. Если у вас приложение не монолит, а цивилизованно побито на небольшие модули, как то: еджби и вареники, то проблем с инкрементальной сборкой и даже деплоем не будет. Один небольшой EJB деплоится в считанные секунды. Это быстрее и удобнее, чем любые микросервисы.
                  Ясно понятно, что под завязку нагруженный сервер стартует довольно долго. Но его не надо стартовать часто. Раз в неделю вполне достаточно. Вы же не разворачиваете кластер Кубера каждые полчаса?
                  Дело в правильном планировании и организации работ.

                    +1
                    Один небольшой бандл в Karaf деплоится еще быстрее (при этом он достается из репозитория). Я много раз говорил, что OSGI в его современном виде — это удобнее микросервисов. Во-первых, потому что при наличии опыта работы с языками семейства JVM вам в общем-то обычно не нужны никакие другие языки, поэтому возможность написать микросервис на условном Go — это для тех, кто переходит с PHP, где долгоживущие сервисы писать было больно (а может и сейчас так). У тех, кто писал на JavaEE или OSGI, EJB и бандлы всегда и были микросервисами, при условии приложения головы к проектированию.
                      0
                      с PHP, где долгоживущие сервисы писать было больно

                      Да и сейчас больно. Но и смысла в долго живущих сервисах не так много. Сервисы с api где достать данные и выдать в определенном формате и возможно закешировать — проще простого.


                      Если нужно обработать поток данных то RabbitMq или Kafka + php тоже все ок.


                      Так что остается только стримы аудио и видео — там да постоянно открытый сокет и постоянно живущий сервис. Вот только с этим и голый nginx справляется на отлично.
                      Если же нужна еще и модификация этого контента на лету — тогда да тут и подключаются go/java/python/etc...

                        0
                        >Kafka + php
                        В этом-то и разница на мой взгляд, что я (если приспичит) легко (ну, или не очень) напишу кафку на Java, а вам придется взять готовую. Т.е. по сути, если долгоживущие сервисы писать больно — то вы их либо не пишете, либо используете написанные на других языках. Отсюда никак не следует, что они не нужны как таковые. Любая СУБД — это долгоживущий сервис. В них тоже нет смысла? :)
                          0

                          Эмм и часто приходиться писать свои базы данных ?

                            0
                            Ну, не часто, да. Но таки на Java написано по-моему минимум четыре SQL движка, вполне себе полноценных, с нормальным диалектом SQL, расширениями и всем прочим. Это не считая кассандры, HBase и других. Так что потребности такие есть, и их пишут.
                              0

                              То есть по сути — вы не пишете свою Kafka с нуля. А используете те части интерфейса пакета которые отвечают за producer и consumer?

                                0
                                Кафку нет. Но специализированные простые аналоги — писал.
                                  0

                                  То есть по сути нечто по паттерну Observer либо publisher-subscriber ?

                                    0
                                    Ну, не факт. Полноценный messaging, даже упрощенный — это не совсем про это. Это скорее про то, как хранить сообщения, чтобы было быстро и надежно, как их сериализовывать туда-сюда между приложениями и каналами, и т.п.
                                      0

                                      Хм, надо попробовать!

                      +1

                      K8s просто так не развернешь, для этого требуется целая орава админов. И это своеобразное препятствие разворачиванию проекта целиком. В итоге никто не знает, как работает весь стек.

                      • UFO just landed and posted this here
                          0

                          Либо прогресс за 3 года скакнул выше головы, либо мы имеем в виду разные вещи. Если 3 года назад требовалось 40 админов, чтобы поднять приличное приватное облако на кубере. Откуда вы взяли 1 человеко-день. Что в итоге сможет его облако? Да его на подготовку металло-базы не хватит в размере больше 10 нод. Я же не про миникуб говорю, а настоящую систему.

                        0

                        Ну, во-первых, меня до сих пор интересует зачем вообще делать деплой, если мы не на продакшне. Это бесполезная операция. Функция public static void main(String… args) до сих пор не deprecated, а весь функционал сервера приложений доступен ввиде библиотек или фреймворков.


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


                        Хорошее решение сделано в Spring Boot Devtools: там разделены контексты класслоадеров на статические — которые грузят из джаров (которые в свою очередь редко меняются) и динамические — которые грузят из .class вокрспейса. При изменении в файле класса спринг перезагружает контекст, при этом оставляя статические класслоадеры, которые уже отрезольвили все необходимые зависимости. В итоге приложение апдейтится за секунду.

                          0

                          Так это вы про Спринг, который монолит. Java EE не пробовали использовать?

                            0

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


                            Я поневоле использую JavaEE с 2005 с открытыми и коммерческими серверами вкупе с кучей проприетарного барахла, которое шло поверх. Причем, сколько использую, столько плююсь — платформа реально мешает выполнять задачу, ограничивает и усложняет многие вещи, которые без нее сделать в разы проще.

                              0

                              Спринг является монолитным независимо ни от каких слов-вирусов, поскольку разбить его на модули в рантайме нельзя. Проблемы будут уже при попытке запуска второго контекста. И всё потому что Спринг изначально отдал предпочтение простоте, разменяв на нефункциональные возможности ПО.
                              В целом, как замена пхп он работал, поэтому и снискал популярность в студенческой среде. Но итог эволюции был предсказуем и никакие костыли, пытающиеся превратить Спринг то в наносервисы, то наоборот в интегрированное решение наподобие Java EE, уже не помогут.

                                0
                                Спринг является монолитным независимо ни от каких слов-вирусов, поскольку разбить его на модули в рантайме нельзя.

                                Один вопрос — нафига? Модуль — логическая единица, а не физическая. В одном процессе и контексте могут сожительствовать сколь угодно много модулей. Сделать инъекцию бина и локальный вызов метода гораздо проще, чем городить API, усложнять архитектуру и искать себе проблемы там, где их нет. Какие конкретно насущные задачи решит разбивка на разные deployable units?


                                пытающиеся превратить Спринг то в наносервисы, то наоборот в интегрированное решение наподобие Java EE, уже не помогут

                                Это все-равно что превращать трамвай в паровоз. Spring стал популярным именно как замена JEE, сначала предоставляя более простой слой интеграции с ней, а затем как независимое решение. И уже JEE в надежде удержать юзеров стал таскать идеи из спринга, например CDI.

                                  +1
                                  Нафига? Чтобы не было вот таких перлов от начинающих разработчиков:
                                  Для запуска одиночного сервиса не нужно долго подымать JavaEE сервер — достаточно упаковать его в тот-же docker
                                  превращаются в лютый Ынтенпрайз от которого стынет кровь в жилах
                                  Любой профессионал хотя бы должен знать о существовании термина "нефункциональные требования к ПО". Но если вдруг не знаете, то вот и вот минимум. Физическое разбиение на микросервисы потому и появилось, что при разработке в Спринге невозможно логический модуль независимо развернуть. Да, девтулс частично и не всегда стабильно решает эту проблему. Его проблема ещё и в том, что нужно по мере разработки сдвигать границу между статической и динамической логикой. И всё равно динамическая часть как правило довольно большая и её перезагрузка тоже требует немалого времени.

                                  Я не отрицаю что у Java EE до 6 версии были серьёзные проблемы со сложностью разработки. Помнится, я сам, когда тоже будучи студентом пытался разобраться, как работают EJB. И меня тоже несколько смутила необходимость понять структуру их вызовов, написания нескольких требуемых интерфейсов и ещё пары -тройки классов к ним. Но если бы у меня была тогда возможность, думаю, что я разобрался бы. Ведь мои однокурсники вполне себе сносно работали с тогдашними энтерпрайз-системами и не жаловались.

                                  Но следующий мой опыт был уже с вышедшей к тому времени JavaEE 6. И удивляясь тому, насколько все упростилось, я за пару недель накидал вполне себе работоспособный проект на стеке JavaEE 6, со всеми его преимуществами.

                                  Теперь проиллюстрирую на реальном примере, не очень большом проекте, в котором без EJB я бы большую часть рабочего времени медитировал.
                                  Было простое веб-приложение, которое доставало из базы сущности, процессило их и сохраняло назад. Сложность в том, что сущности надо было нетривиальным образом в базе найти, а логика зачастую зависела от данных. Т.е. смотришь на то, какие есть данные — пишешь логику их обработки. Так вот, загруженные данные сохранялись в веб-контексте, который на JSF. Логика поначалу была вынесена в локальный то ли е-бин, то ли именной бин. Проект собирался на месте (компиляция при сохранении включена), но JRebel я не использовал, и при изменении чего-то большего, чем тело метода, происходил полный передеплой (тоже автоматом кстати). В моём случае это само по себе не было большой проблемой, т.к. в проекте всего несколько бинов. Но вот веб-контекст при этом сбрасывался и надо было его начинать заново. Обидно было. Скоростная разработка страдала.
                                  И тут на помощь как раз пришли remote версии EJB. Выносим логику в отдельный физический модуль — тип соответсвенно EJB. И собираем и деплоим этот модуль отдельно. Веб-часть с её контекстом остаётся нетронутой (кто бы что не думал по этому поводу). Даже транзакция к базе нормально предсказуемо работала. То есть имеем кэшированный контекст, который вызывает меняющуюся постоянно логику (меняется только внешний EJB-бин). И всё работает! Размер модуля EJB — десятки килобайт, который деплоится за 200 мс, поскольку все веб-либы и прочий хлам вынесены отдельно и прогреты с кэшем.

                                  Вот зачем нужно разделение на модули в физическом смысле.

                                  А по поводу CDI — это во многом повторение EJB 3 версии, без их преимуществ. Попробуйте в CDI организовать транзакцию.
                                    0

                                    Чтобы разделить business и web tier не нужен JEE сервер — для джавы есть 100500 легких технологий ремоутинга. Помнится мы в свое время (лет 15 назад) использовали RMI. Сейчас это модно делать при помощи Rest API. Запускаются локально два процесса: business и web, по мере необходимости рестартится любой из них.


                                    Теперь по поводу вашего проекта. Вангую:


                                    • Функционал проекта не выходит за рамки базы данных и веба
                                    • Вы единственный разработчик
                                    • У вас нет ни одного автоматического теста
                                    • Конфигурация сервера и ресурсов лежит отдельно от кода
                                    • Вы используете Eclipse и ваш проект сильно завязан на его тулинг, отсутствуют средства автоматического деплоя
                                    • Вы используете какой-нибудь opensource сервер, типа Glassfish или TomEE
                                    • Отсутствует более чем полностью параметризация приложения
                                    • Не используется CI/CD

                                    А по поводу CDI — это во многом повторение EJB 3 версии, без их преимуществ. Попробуйте в CDI организовать транзакцию.

                                    Скорей без их рудиментов. С JEE7 бины умеют транзакцию.

                                      0

                                      Заметил, что на хабре переиначивают лексику. Вообще, ванговать — значить предсказывать, прогнозировать (с иронией), от прорицательницы Ванги. А проект этот из прошлого.


                                      Да, вы правы во многом, проект делался мной одним и никаких наворотов поверх него не делалось, поскольку это по сути была временная утилита, которая разрабатывалась прям на лету. Она сделала своё дело за 2-3 дня разработки и всё. Поэтому:


                                      • Функционал всего проекта выходить мог далеко. Но конкретно для этой тулзы нужно было подкорректировать/рапарсить данные в БД.
                                      • Да, единственный и неповторимый
                                      • Тесты, конечно, были на начальном этапе, модульные, 2-3 штуки.
                                      • Поскольку это JEE сервер, конфиг для всех подпроектов я записал один раз на этот сервер — датасорс, после чего он используется всеми причастными веб-приложениями. И не надо его копировать по нескольку раз.
                                      • Я использовал Netbeans, потому что в нем как раз лучшая интеграция с сервером. Именно из-за того что проект завязан на тулинг только в плане интегрированной разработки на сервере, разработка происходит моментально, с мгновенным фидбэком. Код компилируется и деплоится, не успеешь ещё кнопку сохранить нажать — каждые несколько секунд. Если сложный случай — сигнатуры методов поменялись — то автоматический редеплой прям на месте, почти незаметно (2-3 секунды). Шаблоны JSF подхватываются как статика. Сам проект да, это нетбинс, т.е. скрипты анта. Но никто не мешает рядом положить хоть мавен, хоть грэдл.
                                      • Это был эталонный Glassfish. Скорость работы, деплоя и абсолютная интеграция с ИДЕ не заставляли смотреть на аналоги.
                                      • Конкретно для этого одноразового приложения параметризация была не нужна. Хотя её несложно настроить в сервере. И какое это имеет отношение к обсуждаемому? Параметризованный каркас не мешает перезагружать бины с чистой логикой. Логика, конечно по конкретным данным работала из контекста.
                                      • Здесь CI/CD попросту не нужен был, интегрироваться не с чем, результат работы — новая версия БД. Хотя потратить время, сделать — вполне возможно было.

                                      мы в свое время (лет 15 назад) использовали RMI. Сейчас это модно делать при помощи Rest API

                                      EJB как раз на RMI в одном из вариантов. Все другие коннекты не прокидывают контексты и транзакцию. Вы подцепитесь по Rest, а управление ошибками и транзакциями потом будете делать вручную, изобретать велосипед. И так в каждом проекте на Спринге.

                                        0

                                        Собственно все как я и предполагал. А теперь почему я никогда НЕ выберу JEE для своего проекта.


                                        • Каждый девелопер в команде должен пройти дебильную ручную процедуру установки и конфигурации сервера локально на своей тачке. То же самое нужно сделать для каждого environment, сервера CI/CD, etc. Конфиги сервера всегда хранятся отдельно от проекта бог знает где и нередко недоступны ввиде файлов. Поэтому правильно делают те, кто пакуют сервер с приложением в докер.
                                        • Вам повезло, что ваш сервер OpenSource. Коммерческие решения как правило не так приветливы к программеру (по секрету скажу, что вендорам насрать на девелоперов: их целевая аудитория — шефы) и как правило не умеют пускаться и деплоиться локально из IDE. Поэтому прощай нормальный дебаг и IDE и здравствуй коммандная строка и System.out.println().
                                        • Все JEE решения сильно завязаны на тулинг (коммерческие IDE, плагины, коннекторы). Через пару лет тулзы апдейтнутся, и ваш проект тупо перестанет собираться или запускаться. Так у меня было практически с любым JEE проектом — через пару лет так просто поправить плевый баг или фичу без геморроя уже не удастся.
                                        • JEE вообще не предназначен для юнит-тестирования. Когда он задумывался, еще даже не было такого модного слова. Во-первых в общем случае JEE не умеет пускаться из IDE локально в embedded режиме и цеплять приложение из workspace (в случае с Glassfish для вас это делает умный плагин к IDE). Во-вторых, не позволяет управлять сборкой контекста: то есть тупо нельзя динамически указать какие бины для теста нужно задеплоить, а какие нет, ведь весь bean-дискавери завязан на текущий classpath. Евангелисты JEE предлагали иметь на каждый тест свой maven-профайл, где указывается свой classpath с ресурсами, специфичными для теста, и пускать тесты вручную из мавена. В-третьих, нельзя программно установить конфигурацию сервера для конкретного теста, например когда ваш тестовый сервис должен послать месседж в тестовую очередь или законнектиться к другой базе данных. Особо продвинутые умудряются отделить всю логику от ресурсов сервера, обвешаться со всех сторон моками и тестировать локально без контейнера. Что конкретно они при этом тестируют — они не понимают сами. Конечно есть технологии типа TomEE и Arquillian, но это велосипеды, призванные криво обойти одно из важнейших ограничений JEE.
                                        • Application-specific parameters вообще отсутствует как таковой. То есть тупо указать вебсервису, что тут на данной машине он должен вызывать этот URL, а на другой тот, будет связано с глубоким копанием JAX-WS и велосипедами ввиде отдельно лежащего файла .properties, достижимого по абсолютному путю, либо environment variables. С другой стороны, конфигурация приложения — это то, что из коробки предоставляет вообще любой фреймворк.
                                        • Конкретно что такое дает ваш JEE, чего нет в библиотеках и фреймворках? Правильный ответ — JTA. Это то единственное, ради чего его используют в энтерпрайзе. Однако JTA — это один большой закамуфлированный архитектурный антипаттерн, который вы никогда не поймете до конца и никода не сможете настроить нормально. Все остальное делается проще, лучше и изящнее, нежели в JEE.
                                          0
                                          • Про кофиги это вообще отдельная история. Помнится, когда делали проект на Спринге, его настройки паковались под каждый профиль отдельно. Причём для продакшена и препрода эти настройки были пустые по понятным причинам безопасности в банке. Поэтому настройки прописывал админ, который деплоил наше приложение на банковский джбосс. И делал это перепаковкой архивов с приложением, рискуя ошибиться и сломать к черту всё приложение. И он ругался и плевался, поэтому я специально сделал запрос конфигов в Спринге из jndi контекста и боль пропала. Локально при разработке можно было продолжать пользоваться пропертями, но я этого не делал, потому что настроить сервер проще и логичнее.
                                            По поводу сервера на каждого разраба: извините, если разработчик не может даже сервер настроить на основе имеющейся конфы, то что тогда он вообще может.
                                            Отсутствие конфига сервера в проекте — это сугубо ваша личная боль. Если в проекте бардак, то сервер тут ни при чём. Для глассФиша можно конфиг отправлять онлайн прямо при деплое или заблаговременно. Но в целом, что в глассФише, что в джбоссе, что в Веб-сфере конфиг можно просто подложить целиком — самый простой способ.
                                            На самом деле, когда у вас несколько конфигураций, то прописывать их вручную всё равно придётся, в лучшем случае через указание путей в среде окружения. Сервера приложений в этом смысле удобнее ещё и тем, что можно на одном инстансе запустить все сервера на каждый конфиг, и деплоить потом туда, куда требуется. Не нужно останавливать один сервер, чтобы запустить хотя бы один другой — память расходуется экономнее и, если руки прямые, конфликта по портам нет, как обычно бывает со спрингом.
                                          • Про коммерческие: если придерживаться стандартов, можно разрабатывать и на бесплатном. Хотя я описанные вами проблемы не встречал ни в джбоссе, ни в Веб-сфере. Есть свои особенности, но они преодолимы. В сфере логи можно настраивать и смотреть из панели управления.
                                          • Апдейты — да, есть неудобства при переходе на новый мажорный релиз, коих всего то было три штуки за 10 лет. Но это меньшая боль, чем мажорный апгрейд Спринга или тем более смена его на нечто другое. Сфера сносно управляется мавен-плагином. А отладка так это вообще свойство JVM, а не сервера, её всегда можно включить и цепляться вручную, даже на удалёнке
                                          • Мне кажется, вы путаете модульные и интеграционные тесты. Модульные — на классы и методы. Интеграция — с бинами.
                                            Никакого волшебного плагина к иде я не знаю. Если хочется интеграции, то надо пускать встроенную версию глассФиша или джбосса вручную, т.е. программно (ну или с помощью плагина для junit). При этом можно нормально конфиг в контекст передать, не видел в этом проблем, когда редко это требовалось.
                                          • Про урл не понял, это клиентский что ли? Если серверный, то обычно он от контекста зависит, корень которого вполне задаётся. Если у вас параметры для приложения задаются извне, то это не параметры приложения, а параметры среды, и логично тогда параметры среды задавать в среде, т.е. на сервере.
                                          • Я не видел нормальных альтернатив JTA. Кроме того, как я говорил, сама концепция — ты приносишь логику, инфраструктуру готовит заказчик — подходит для многих приложений. Даже для облака. Плюс не надо тратить ресурс в виде встроенных серверов и кучи зависимостей. Приложения лёгкие, они несут только логику самого приложения. Возможность запуска нескольких компонент независимо, но на общей базе экономит память и время запуска.
                                            А коммерческие решения ещё и предоставляют масштабирование, балансировку и отказоустойчивость с меньшим геммороем, чем тот же кубернетос или редшифт, который средние компании вообще не потянут в приватной версии.
                        +1
                        >понять web.xml
                        Э… вообще-то web.xml это примерно три вещи: сервлеты (просто список), фильтры (просто список), и маппинг URL на те и другие. Т.е. по сути — маршрутизация запросов в приложении. Пусть она сто раз кривая и неудобная — но это просто. Или вы шутите (я видел смайл, если чо), или ваша квалификация и выводы как бы вызывает некоторые сомнения.

                        Ну или точнее — это было так, как вы рассказываете, примерно до 2010 года, до JavaEE 6 версии и EJB 3-ей. С тех пор все изменилось.

                        Но даже и тогда, в 2010, никакого деплоя часами просто так не было. Да, у меня было приложение, которое деплоилось минутами. Из них несколько секунд — старт томката, остальное время — зачитывание в кеш (которым оно по сути и являлось) кучи данных, и их подготовка. Ну т.е. сам контейнер стартовал практически мгновенно (и это еще был старый томкат, до JavaEE 6). А уж как медленно могут стартовать ваши приложения — это вам решать, и больше никому.
                          0

                          Ну так после 2010 я пересел на стек с php, видел что да на GlassFish все действительно стартует быстро но мне уже на это было как-то пофиг. Поле 2018 пересел на node.js.
                          Далее по плану нормально изучить Ceph + k8s а после уже думаю развиваться в сторону go/rust/python.


                          На java за это время — написал только один сервис допилил — добавил в него провайдер который берет сертификат X.509 с хитрыми алгоритмами ГОСТ и подписывает XML. И то это так — считай ничего и не написал.

                            0
                            >мне уже на это было как-то пофиг
                            Ну, если это чисто ваше мнение, с учетом вашего давнего опыта — то может так оно и было. Только не очень понятно, какие выводы нужно сделать с учетом того, что за последние 10 лет очень многое изменилось? Ну т.е. вот реально — вы уже два или три раза стек сменили, а мне ни разу не пришлось — при этом я четырежды менял направления, оставаясь в рамках JVM. Какой из этих путей правильный? Вполне возможно оба — для каждого свой.
                              0

                              Скорее не сменил а расширил. Был только backend теперь fullstack.


                              Постоянно делать одно и тоже на одном и том же стеке оно конечно и удобно и даже прибыльно. Но вот поковырять и другие технологии тоже полезно и интересно. Да java тоже доберусь постепенно.

                                0
                                >одно и тоже на одном и том же стеке
                                Я бы не сказал, что делаю одно и тоже. Скажем, один из моих проектов был близкий аналог Google Maps. Не по размерам, конечно, но по функциональности. А сейчас вот BigData. Это совершенно не одно и тоже.
                                  0

                                  Хм, интересно. Можно будет ссылку на карты?

                                    0
                                    Не. Не то чтобы мне было жалко, но это чисто внутренний проект. Он даже в интернет никогда не торчал.
                        +4
                        Какая-то чепуха, извините. Ну, да, JVM во-многом дублирует функции и API ОС, просто потому, что предполагает работать прослойкой между ОС и приложением. Но кроме редчайших случаев JVM не работает на голом железе. И пример Андроида не хороший — потому что там есть вполне себе живой Linux. И кубернетис JVM тоже не заменяет — потому что опять же, в большинстве случаев JVM это одна физическая машина, а кубернетис это кластер. И даже Hadoop, который в общем очень близок к тому, чтобы быть ОС, со своей распределенной файловой системой, с планировщиком задач — и он тоже ей не является, потому что снова внизу линукс.

                        Ну т.е. можно было бы написать ОС, в основе которой была бы JVM на голом железе. Но это из оперы если бы да кабы.
                          –3

                          В JavaEE и других фреймворках вполне хватает средств кластеризации. Только там немного другая гранулярность. В качестве инстанса выступает джвм с Веб-сферой, к примеру. Инстансы организуются в кластер и другие объединения.
                          Что касается ОС: у Оракла была такая система, JRocketVM. Это тоже не Линукс, конечно, но из него выдраны многие лишние компоненты. Лёгкая версия, скажем так. И позиционировалась для запуска на металле.
                          Для самой jvm по большому счёту, не нужна ОС, достаточно ядра. Причём я даже рассматривал варианты запуска в реальном режиме по причинам, описанным в статье.

                            +3
                            >В JavaEE и других фреймворках вполне хватает средств кластеризации.
                            Конечно хватает. Но это не делает из них ОС по умолчанию. И потом, берем тот же хадуп, и что мы там видим? Вместо AD — FreeIPA (не Java вообще), у Hive в качестве среды хранения метаданных — обычная СУБД (хотя можно в теории прикрутить скажем Derby, но никто этого не делает никогда. И много-много других компонент, которые взяты из линукса.

                            Кроме того, попробуйте из JavaEE приложения порулить тем, как ваши EJB распределятся по кластеру? Насколько я помню, такого API никогда и не было. А для кубера это чуть ли не основное. Ну в общем я согласен с тем, что JVM могла бы во многих случаях заменить многие другие инструменты (в случае того же докера — у меня вот не было ни одной реальной потребности его применять, опять же потому что JVM), но все-таки JVM и ОС не равны друг другу в сегодняшней реальной жизни. Похожи — но не равны.
                              0

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

                                0
                                Дело в том, что планировщик вообще дело достаточно хитрое (ну, тупо потому, что для хорошего планирования было бы замечательно предсказывать нагрузку, а это вообще никто не умеет.). И мне кажется, для его написания еще просто не хватает API как минимум. Ну т.е. нужного чтобы собирать информацию о нагрузке.
                              –1
                              Я бы попросил скрытных товарищей предъявлять аргументы в споре, а не молча подленько про себя минусовать. Неоднократно отмечалось, что если вы не согласны — это не повод минусить.
                              –2

                              Насчёт Андроид, да, там ява больше для гуи оболочки использовалась. Примерно как иксы или винда 3 версии. В принципе, с некоторой натяжкой можно и её считать отдельной ОС.
                              Вообще я перечислил признаки ОС в Ява-машине.
                              Можно ещё уточнить, что Линукс — не ОС, это ядро ОС. А ОС чаще всего гну. Андроид не гну ос. И обратно, гну ос может работать на ядре Хёрд.

                                0
                                Винда третьей версии уже несла в себе функции, на которых строился GUI софта, а не самой ОС.
                                Не надо путать ОС и платформу.

                                Можно ещё уточнить, что Линукс — не ОС, это ядро ОС.

                                Как раз Линукс — это ОС, состоящее из ядра и приложений.

                                А ОС чаще всего гну.

                                ОС в первую очередь — ядро (и его стандарты, например POSIX), а затем уже остальные вещи, которые теоретически можно заменить, и Линукс не перестанет быть Линуксом, он перестанет быть GNU линуксом.

                                Андроид не гну ос

                                Потому что это ОС на базе Линукс-ядра.

                                И обратно, гну ос может работать на ядре Хёрд.

                                Это будет GNU Хёрд ОС
                                  0

                                  Я как раз и говорю про "функции, на которых строился GUI софта". Это и называется графической оболочкой, часто одной из главных частей ОС.

                                    0
                                    Но это не так.
                                    Графическая подсистема и стандарт для gui приложений может быть и не связан с GUI оболочкой. Например, в Windows есть GUI проводник, но он не является графической подсистемой, на базе которой другие приложения что-то строят.

                                    Оболочка (shell) это интерфейс для пользователя, а не для программ.
                                      0

                                      Вы путаете теплое с мягким.
                                      Прежде чем утверждать, что я путаю ОС с чем-то, определитесь с тем, что такое ОС. По мнению Википедии, например, графическая оболочка входит в ОС как важный третий компонент. А в Гну/Линукс ОС можно включать оболочку Гном.
                                      Далее. В win 3.x оболочка и апи были практически неотделимы. Поскольку апи – это библиотеки, оболочка в их случае была всего лишь диспетчер задач на основе этих апи, как и проводник впоследствии. Поэтому в случае вин, имеются в виду именно библиотеки примитивов, аналогично гному или кутэ. В винНт, насколько я знаю, такой подсистемой является гди вкупе с директИкс.
                                      Я не вижу смысла называть приложения типа проводника оболочками в статье, посвященной системным вещам. Оболочка здесь в архитектурном смысле.
                                      Что касается Андроид: здесь именно далвик выполняет функции графической подсистемы, плюс обёртка над нативными апи Андроид.

                                        0
                                        У каждого термина есть определение. Оболочка это оболочка, Апи это Апи. И то, что в win 3.x оболочка и API была монолитом, не делает их одним целым ни по смыслу ни по терминологии.
                                          0
                                          Апи это Апи
                                          API это вообще абстрактное понятие, набор соглашений, контракт. А вот его реализация уже может быть в чём-то конкретном. В библиотеке, в адресах вызова в ядре, в номерах прерываний, rest или qraphql эндпойнтах.
                                          Поэтому API не может быть с чем-то монолитом, оно может в чём-то реализоваться.

                                          Например, в Вин 3.1, если библиотека реализует АПИ ГДИ32, то через этот АПИ, большинство приложений, подключая эту библиотеку, рисуют ГУЙ. Где тогда оболочка? Ответ: оболочка в библиотеке и доступна через АПИ этой библиотеки. И эта библиотека была частью ОС Вин со времён динозавров.
                                            0
                                            Ответ.
                                            Оболочка — это программа для взаимодействия Пользователя и Операционной системы.
                                            Не для взаимодействия программы и программы, или программы или системы. Это именно то, где пользователь может что-то набрать, написать, кликнуть и увидеть или запустить программу/скопировать файл и так далее.
                                            Со времен динозавров оболочка и API для отрисовки чего-либо (графические API, прерывания, телетайпы) эти термины не менялись.
                              0
                              Если в Юникс — всё файл, то в Ява всё (почти) есть объект.

                              Который лежит в heap. Запихнуть всю фс в хип, конечно, можно...

                                0
                                >Который лежит в heap
                                Не обязательно. off heap память уже достаточно давно доступна, если уж хочется странного.
                                  0

                                  Незачем пихать файлы в Хип. Зачем? Чтобы быть похожими на юникс?
                                  Хотя есть одна ОС, в которой даже файлы в виде объектов на офф-хипе

                                • UFO just landed and posted this here
                                    +1
                                    >Переместит ли «джава» нагрузку на другую ноду?
                                    Ну, в случае скажем хадупа — вполне перемещает. И балансировка там есть, и планировщик тоже.

                                    Ну только это не JVM, разумеется, а большое такое приложение, пусть и написанное на Java. Ну т.е. это я к чему — что написать ОС на базе JVM в принципе было бы можно. Но на сегодня никто не будет.
                                      0

                                      Поскольку Ява почти ОС, то Ява и есть нода. Если вылетит, то целиком. Но она не вылетит. И нода большая, иначе смысла запускать Яву вообще нет. Т.е. одна Явная нода. И вылет по явовскому ООМ случится тогда, когда кончатся ресурсы, и это безопаснее, чем пресловутая молчаливая смерть от нативного ООМ.
                                      Как я уже описал, в специализированных серверах есть балансировка, это значит, что да, нагрузка перемещается по кластеру, на то он и кластер.
                                      Если под л вы подразумеваете левел сети, то ejb/RMI – прикладной уровень. Да, я не спорю, что может быть уровень тисипи эффективнее. Но это нивелируется работой с джсоном по хттп между сервисами в большинстве случаев.
                                      И кстати, я не делал вывод, что Ява может заменить Кубер. Я лишь оцениваю недавнюю историю развития Явы и как платформа профукала свой рынок. И показываю как должна работать Ява. Что т.н. кровавый ынтырпрайз по мнению некоторых был неудачным тяжеловесным решением и надо срочно сделать монолитный Спринг.
                                      История показала, кто был прав и какие технологии продуманны и обкатаны, а какие сделаны на коленке. И показываю, что еджби в ентерпрайз-кластерах, по сути то же, что докеры в кубере. А заголовок — это для привлечения внимания.

                                        0
                                        JVM это как игрушечный Smalltalk. Ява была сделана одними из авторов Smalltalk которых выкупил Sun в начале 90-х. Smalltalk, как известно, это и была ОС.
                                        А вот по теме статьи как раз, лучше сравнить Erlang(Elixir) на OTP — вот уж точно замена докеру с кубером, мало того что там управление ресурсами есть между потоками и взаимодействие при помощи сообщений, так еще можно прозрачно процессы между нодами перекидывать + встроенный supervisord. Отлажено уже всё это 10-ти летиями. ;)
                                      +1

                                      Ну до ОС, как уже правильно написали выше, JVM конечно не дотягивает и не пытается. ОС это все-таки про работу с железом, с сетью, про лимиты по ресурсам, файловые системы и все прочее. Кубернетис он про то как управлять несколькими серверами, чего JVM не делает.
                                      У JVM собственный мир, во много устаревший. И все эти OSGI, уже упомянутый web.xml и прочие spring-и, излишне сильно раздутое и переусложненная модель которая делает простые вещи. Никогда не понимал зачем нужны всякие web.xml и прочие spring.xml если можно тот же маппинг url-ов написать прям на Java. Библиотечный подход он все-таки попроще и попонятнее, ненадо ещё разбираться с вымышленным языком всех этих xml-ей.
                                      Времена статичных сайтов и shared хотингов прошли, и все как-то более переместилось в сторону виртуализации, контейнеров и вот этого всего. Потому что внезапно оказалось что интернет совсем не дружелюбная среда, какой она была на заре становления. Нужно ограничивать ресурсы, процессор, память, место на диске, сетевое взаимодействие. А разделяемые сервера этого не умеют.

                                        0

                                        Как же не умеют. Есть джеластик Ява как раз про это всё.
                                        JVM не умеет, зато доменный контроллер, запущенный на ней, вполне умеет (в современной терминологии контрол-плэйн).
                                        XML нужен не тогда, когда у вас 1 экземпляр, а когда надо 15 настроенных релизов выкатить на 20 клиентов с очень разным но тем не менее схожим составом блинов в логике и разным расположением ендпойнтов на корп. портале.

                                          +2
                                          JVM не умеет, зато доменный контроллер, запущенный на ней, вполне умеет (в современной терминологии контрол-плэйн).

                                          И что прямо приоритеты потоков, пропускную способность сети, количество выделяемой памяти, количество открытых сокетов может ограничить? Незнаю что такое доменный контроллер, но что-то сомневаюсь.


                                          а когда надо 15 настроенных релизов выкатить на 20 клиентов с очень разным но тем не менее схожим составом блинов в логике и разным расположением ендпойнтов на корп. портале.

                                          Когда 20 клиентов на корп. портале — это не настоящие 20 клиентов, это просто 20 приложений в конторе, их более менее можно контролировать административно.
                                          А вот времена 20 настоящих незнакомых клиентов на одном аппликейшн сервере прошли, сейчас каждый из 20 клиентов либо на своей отдельной виртуалке, либо вообще платит за вызовы API и колиество загруженных мегабайт в БД.

                                            0

                                            Имелись в виду 20 сторонних клиентов с 20-ю порталами.
                                            Доменный контроллер глассФиша умеет управлять серверами. И Флай тоже.
                                            Правда управлять в смысле определять лимиты, кол-во копий бинов и т.п. Это оценка ресурсов в штуках, а не в мб, как в Амазон ЕЦС.
                                            А вот jelastic cloud как раз метрики собирает и как-то хитро калибрует память.

                                              0
                                              А вот jelastic cloud как раз метрики собирает и как-то хитро калибрует память.

                                              Так jelastic-то как раз работает на контейнерах, просто один из вариантов контейнера это JVM + Tomcat. Jelastic это как раз антипример, это пример жуткой неэффективности и того как делать ненадо. Tomcat эффективен когда запускает 20 приложений в одном Tomcat-е и в одной JVM. А когда 20 приложений запускаются в 20 контейнерах, в каждом из которых своя JVM и свой Tomcat — это ужас, это насколько лишний разход ресурсов. Тут как раз лучше запускать встроенный в приложение сервер на Java (javalin или прости господи spring boot), и лучше даже со встроенной JVM, скомпилировать в native-image от GraalVM, например.

                                                0

                                                На контейнерах они стали работать, чтобы следовать моде. Изначально у них был чисто явовый паас.

                                                  –1
                                                  Вы пожалуй правы в одном — что JavaEE в частности и JVM в целом не обеспечивает должного уровня защиты одного приложения от другого (если их просто несколько, а тем более — если они не слишком доверяют друг другу). Ну т.е. JVM, JavaEE контейнер (и OSGI в общем тоже) — это такое место, где выполняются компоненты одного приложения, а не много разных приложений. И в этом смысле они все ни разу не ОС.

                                                  Я бы только добавил, что в этом же смысле и докер тоже не ОС, потому что полную изоляцию и безопасность тоже не обеспечивает. Ей и полноценные-то ОС не всегда могут обеспечить.
                                                    –1

                                                    Вот насчёт защиты JVM вы зря. Апплеты вполне себе независимо работали. И обычный инстанс если запустить с секурити, вы мало что сможете вне контекста сделать. Например рефлексируя в OSGI, получите по рукам.
                                                    И сервера приложений слабо, но защищены даже по умолчанию. Рми сильно ограничен. И можно ужесточить защиту.

                                                      –1
                                                      >Вот насчёт защиты JVM вы зря.
                                                      Зря не зря, а мой скромный опыт работы с JVM мне такое подсказывает.

                                                      Вы все верно говорите, только вы не про ту защиту. Покажете мне, где лимит на число создаваемых threads, на потребление памяти и процессора? Это все может и есть — но не на уровне JVM. Поэтому один из компонентов, будь то EJB, WAR, или там бандл — вполне может выжрать все ресурсы вообще, доступные JVM в целом, и не оставить остальным ничего. На защищенную систему для деплоя приложений, которые друг другу не доверяют, это вовсе не похоже.

                                                      Попробуйте в EJB сделать бесконечный цикл — потом расскажите мне, как повел себя контейнер, хорошо ли отреагировал.
                                                        –1

                                                        Ограничение на потоки делается имеющимися средствами в пару строк кода: https://stackoverflow.com/a/31039987
                                                        В принципе, управление ресурсами можно реализовать при желании. Всеми, кроме памяти. Что и делает тот же желастик. Для меня всегда было загадкой только как они управляют объемом памяти. Это единственная вещь, которую я считал если не невозможной, то очень трудной.


                                                        В ответ на ваш пример: сделать административный Бин или коннектор для сервера, который прибьет зависший поток — плёвое дело. Часто это делают через JMX.

                                                          –1
                                                          Да вы издеваетесь что-ли? Приложению можно создавать потоки — но в ограниченном количестве, не более лимита. Тоже самое — с памятью. А пример ваш с SO просто дурацкий, я знаю про java security, там нет ограничения на _число_ разрешенных создаваемых потоков. Все что вы получите, создав скажем 32К threads — это скорее всего OOM, в зависимости от объема доступной памяти.

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

                                                            Я рекомендую вам внимательнее читать и код, и документацию, прежде чем писать комментарии.

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

                                                              Более того, там явно написано в конце:

                                                              We get an exception in our Test class when we try to create the new thread:

                                                              И это не то, о чем я спрашивал. Так что эта, сначала сами поучитесь читать, что у вас спрашивали, прежде чем отвечать.
                                                                –1

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

                                                                  0
                                                                  Минимальные? Ну, вы, для начала, еще даже не представляете себе, что такое «приложение», которому нужно ограничить права на создание потоков. И как его идентифицировать. Потому что у SecurityManager такой информации нет. Во всяком случае — в явном виде. Есть данные о том, откуда код (т.е. по сути — ссылка на jar), но этого недостаточно, потому что потоки может создавать произвольный класс из произвольной библиотеки, и отследить путь от него до того, что реально является приложением — далеко не тривиально. Более того, совсем хорошее решение предполагало бы нечно вроде планировщика, который бы разрешал выдачу ресурсов в зависимости от наличия свободных — а это уже вообще задача нетривиальная, и далеко не в каждой ОС она как следует решена.

                                                                  Так что минимальными изменениями вы скорее всего не отделаетесь. В этом собственно и разница между готовым решением (которого не просто нет из коробки, а нет по факту ни в одном известном мне контейнере), и поделкой на коленке, которая в лучшем случае позволяет в рамках JavaEE просто запретить потоки (и там это логично, ибо есть managed пулы, которыми и следует пользоваться). Но в общем случае — нет.
                                                                    0

                                                                    При проверке от лица системы всегда можно подняться вверх по стеку и проверить, кто вызвал привилегированную операцию. В стандартном Privileged Action по-моему так и делается. И хорошо, что Ява управляемая – позволяет сделать это без риска все закрэшить. Т.е. если есть некий определенный соглашениями контекст, то проверить его свойства вполне можно, в т.ч. число оставшихся потоков и даже потреблённую память (но это уже задание со звёздочкой)

                                                                      0
                                                                      Да, чтоб два раза не вставать — чтобы сделать полноценное управление ресурсами в рамках текущей архитектуры JVM, вам скорее всего придется запретить JNI. Потому что что там делает native код внутри — вы вообще не знаете, может он там ресурсы жрет в любых количествах… да в общем-то точно жрет, за этим же и пишут.
                                                                      0
                                                                      PS Минимальные и малые — не синонимы.
                                                  0

                                                  Да почему же на одном то. У вас 20 сборок, которые деплоят в 20 разных конторах в 20 местах планеты на 20 разных языках вот такой кейс.

                                                +1
                                                > переусложненная модель которая делает простые вещи
                                                Вот честно, когда такое пишут про OSGI, у меня всегда создается впечатление, что люди вообще никогда с этим реально не работали. У OSGI снаружи простая модель, которая делает простые вещи. Ну т.е. элементарно — бандл это просто jar, который умеет экспортировать наружу избранные packages (а не все подряд классы), и импортировать чужие, у которого есть простейший жизненный цикл (что есть вообще у всех систем, состоящих из компонентов), и еще он может экспортировать наружу произвольные методы, которые может найти и вызвать кто угодно извне. Все. Все остальное (его немало) — это лишь бантики, не более.
                                                  –1

                                                  С OSGI не работал, да, никогда не видел вообще что это такое. Зато видел Tomcat и spring

                                                    0
                                                    >И все эти OSGI,
                                                    Это ваши слова? Если не работали, нахрена вы вот это писали?
                                                –10
                                                Сколько еще будем пинать труп Java?
                                                  0
                                                  А почему сразу труп? Рано или поздно появляется задача, для которой какой-либо язык не приспособлен\менее удобен, разве из-за этого один из популярнейших становится трупом? Если не нравится — не юзай, а многие пишут на нём и всё устраивает.
                                                  –1
                                                  Вы слышали когда-нибудь о вирусах на Яве?

                                                  Лет 15 назад каждый второй вирус распространялся через JVM Browser Plugin, хотя аплеты вроде как работают в изолированной песочнице. Из-за чего юзеры начали массовый выпил джавы со своих компов.


                                                  Итак Ява-машина — это ОС. Даже круче чем ОС местами.

                                                  Нет, это именно виртуальная машина, не более. А вот была попытка написания настоящей ОС на 100% джаве: https://www.jnode.org/


                                                  Потому что, как я уже сказал, она позволяет создавать множество независимых изолированных контекстов

                                                  Она не может создавать изолированные контексты памяти (разные кучи) внутри одной JVM. Поэтому любой тред легко может навернуть всю JVM с OutOfMemory. Плюс все контроли за ресурсами устанавливаются на уровне процесса, а не контекста, поэтому никто не запретит треду открыть миллион файлов или создать еще миллион тредов.

                                                    –2

                                                    Можно подумать, что яваскрипт в браузере безопаснее. Выпил из браузера происходил, потому что Гугл объявил войну Ораклу и Яве в целом.
                                                    ОС на Яве есть несколько.
                                                    Контроль над контекстом памяти я подразумевал в смысле непосредственного доступа. А контроль над ресурсами это вполне реализуемая вещь зачастую средствами самой машины, о чём я писал в статье и в комментариях диалога с sshikov обсуждал.
                                                    Опять же, если не применять лимиты на ресурсы на уровне процессов, то и нативный процесс закрэшит систему. Причём в отличие от Явы, последствия будут серьёзнее: например один процесс может выжрать всю память ОС и тогда Линукс либо тупо застынет, либо будут прибиты случайные процессы. Так что даже здесь сравнение не в пользу натива.

                                                      –1
                                                      Сорри, по ошибке минус пнул, промахнулся. Я уже который день тут автора убеждаю, что поскольку на уровне памяти никакой изоляции нет (и не предвидится, т.е. сделать ее своими руками нельзя — а можно только модифицировав JVM, что по сложности сразу на пару порядков выше) — то и ограничивать потребление ресурсов приложениями на сегодня нельзя — поэтому JVM конечно же ОС не является. Да, попытки сделать были — но не более того. А с тредами — переписка несколько выше.
                                                        –2

                                                        Мне кажется, чем что-то доказывать уговорами, проще сделать и показать.
                                                        Тем не менее: на уровне памяти изоляция есть хотя бы потому, что ни у кого в принципе нет доступа к памяти.

                                                          0
                                                          Ну, это же вы уверяете что сделать ОС из JVM можно. Сделайте и покажите — это будет доказательство.

                                                          А как вы представляете, что я должен сделать и показать — если я считаю что сделать это нельзя (ну или очень сложно)?
                                                            0

                                                            Речь не идёт об ОС, это пока не актуально. А вот в качестве оркестратора вполне можно попробовать.

                                                    Only users with full accounts can post comments. Log in, please.