В этом вся и фишка. Если бы взвимодействие распространялось мгновенно, то никаких бы волн оно не генерировало. Согласно ОТО оно не может превышать скорость света. ЛИГО установил, что оно в точности равно скорости света.
По поводу Солнца. Солнце лишь косвенная причина движения Земли вокруг него. Прямая причина — пространство, искривленное массивным телом-Солнцем, в котором прямая траектория принимает форму эллипса орбиты (геодезическая линия).
Если быстро убрать Солнце, пространство на месте него начнет резко "выпрямляться", что сгенерирует гравитационное цунами, которое дойдя до Земли через 8 минут, должно неминуемо разрушить ее приливными силами. Но до тех пор, пока волна не подошла к Земле, искривленное пространство в ее окресностях будет оставаться в точности таким же, и Земля будет продолжать двигаться по своей траектории.
Это не будет наилучшим решением. Поверх HTML/CSS/Js вы все-равно используете какую-нибудь библиотеку стилей типа bootstrap или polymer, которые вместо каши тегов вводят концепт виджетов и добавляют к ним поведение. Для логики используете какой-нибудь JQuery или Angular. Для каждого запроса приходится отдельно разрабатывать интерфейс с сервером и мепить (ручками или полуавтоматически) получаемые структуры данных на виджеты. Так что на одном HTML/CSS/JS далеко не уедешь.
Vaadin позволяет быстро разработать вебприложение типа админки, фактически программируя только серверную часть. Взаимодействие с браузером полностью прозрачно. Плюс в том, что многие нюансы UI уже учтены и идут из коробки. Плюс мепить данные на сервере в typesafe java-объекты на порядок проще, нежели заморочки с Json. Фреймворк будет близок тем, кто разрабатывал приложения на Swing и подобных библиотеках виджетов.
Отличный язык. Но, боюсь, как бы он не встал на одну полку с Ceylon, GoSu, Fantom, Xtend, etc… На мой взгляд основные просчеты:
— Долго тянут с релизом. Язык был анонсирован несколько лет назад, и вау эффект уже изрядно поутих. Самое время его было выпустить до Java 8. Сейчас внимание программеров переключилось на джавовские лямбды и стримы, и мощь котлина в их глазах уже поугасла.
— Недостаточная огласка в СМИ. Взять хотя бы Одерски, который пиарит свою скалу везде, где только возможно. Несколько статей на хабре не решат проблемы.
— Нет своего стека технологий. Красивый язык оценят, но без сопутствующих технологий им пользоваться не будут. Вот Groovy некрасивый язык, а им пользуются (про Scala толерантно помалкиваю). Нужен стек типа typesafe (или, упаси господи, JEE) и фреймворки типа play. Кроме того, на первое время нужно определиться с нишей решаемых задач, напр. scala — параллельное программирование, kotlin — андроид, клиентские веб приложения (прощай, GWT), микросервисы. На одной экосистеме Java далеко не уедешь.
— Success stories. Типа «Twitter признал свою ошибку со scala и переписал свой стек на kotlin-е» :)
P.S. Персональное ощущение: пробовал Kotlin несколько раз. Писал несколько проектов. В итоге, за пару часов все переписывал на java и избавлялся от котлина в проекте, ибо отличия в структуре несущественны. Да, код короче, элегантнее, но IDE позволяет быстро писать и на Java.
Спасибо за исчерпывающую статью!
Насчет leap second: последний раз она добавлялась в полночь 30 июня 2015 года, в связи с чем утром лежало большое количество сервисов, в том числе и java. С чем могут быть связаны подобные сбои?
Про все эти BPM я уже ответил здесь: http://habrahabr.ru/post/273025/#comment_8690463 (Хабр мне не дает вставлять нормально ссылку).
С BPEL работал и работаю до сих пор. В самой его наихудшей реализации: IBM Websphere Process Server. Oracle SOA выглядит и работает значительно лучше. Самый лучший и во многом продуманный продукт — это JBoss BPM Suite.
Про асинхронное выполнение. Можно взять уже готовый движок jBPM или Activiti. Они в минимальном окружении весят 50кб и ничего дополнительного не требуют. Для Java есть фреймворк Quasar, который прозрачно для кода заменяет треды файберами, которые в свою очередь suspendable и serializable.
Основная задача — окучить клиента. Если тупо показать ему код, то он почувствует себя дураком и покупать ваше изделие не станет. А схемки нехило поднимут его самооценку.
BPEL вообще мертворожденный язык. Изначально планировался для оркестрации вебсервисов и выполнения примитивной логики. Но внезапно оказалось, что людям требуется делать нечто бОльшее, чем тупые меппинги полей 1-1 при помощи XPath, а стандарт на этот счет молчал. Поэтому каждый кулибин внедряет в свой BPEL специальные нестандартные ноды типа «Compute», которые позволяют выполнять хоть что-то полезное в какой-нибудь среде: sql, java, etc. Сейчас BPEL повсемесно вытесняется BPMN-ом.
Основное отличие от кода на языке — возможность асинхронного выполнения процесса и «засыпания» с сохранением состояния в базе до прихода события извне, ответа вебсервиса, etc… Но это только для «хороших» BPMS.
О косяках концепта BPM как такового я писал здесь.
Эпоха BPM началась 10 лет назад и успешно загнулась 5 лет назад. BPMS — это инструмент окучивания толстого клиента, которому можно показать на экранчике схемку как работает его компания. Но мы-то с вами, конечно, понимаем, что это всего лишь один из способов программирования конечного автомата, и что десятками лет люди делают то же без всякого BPM.
Основные части BPMS:
1. Красивая схемка т.н. «бизнес процесса», желательно с визуальной программулиной, позволяющей расставлять на листе «ящички». И которая еще позволяет «запускать» процессы и показывать где он сейчас выполняется. Без этого не ничего продастся.
2. Некий навороченный «BPM-движок» весом в 30кб (jBPM), позволяющий «выполнять» позадачно диаграмму. Практически всегда требует базу данных, чтобы состоянию было куда-то сохраняться.
3. Fallback в какую-нибудь реальную среду проргаммирования: java, xquery, PL, etc… Как ни вертись, а ящики на диаграмме никакой полезной нагрузки не несут — приходится все-таки на чем-то кодить.
4. Паровозом предлагают средства интеграции с внешним миром: какую-нибудь самопальную ESB, JEE коннекторы, адаптеры, вебсервисы, etc…
5. Ну и самая основная часть — портал для Human Task-ов. Без него все ваши BPMS вообще не имеют смысла (а до 2005 года они скромно назывались Workflow). Визуально список папок по таскам а ля Outlook, на каждую задачу убогая стандартная формочка с данными, которую чтобы кастомизировать, то проще свой портал написать.
Что не так с BPM? А практически все.
— Вопреки изначальной идее, как ни старайся, динамически процесс изменить не удастся. Бизнес аналист расставит ящики и стрелочки. Затем каждый ящик закодит кодер. Затем аналист поменяет местами ящики в надежде, что все будет работать, но процесс благополучно упадет. Сколько ни пытался Oracle сделать колаборацию двух тулзов: BAM и BPM — хорошо все только на поверпоинтах.
— Резко поменалась бизнес логика, но половина процессов еще идет по старой версии. А интерфейсы, среда, база, модель — все уже новое. Версионность — основной бич всех BPM. Если в своем велосипеде ты полностью контролируешь педали, и можно эволюционировать запущенные процессы, просто актуализнув базу, то в пропиетарной BPMS — хрен ты до чего докопаешься.
— Возможности портала убоги. Всегда плохо адаптируется к реальным потребностям в интерфейсе. Интегрировать BPM в свой корпоративный портал тот еще танец с бубном.
— Одним BPM-ом сыт не будешь. Ящики должны выполнять какие-то полезные действия. Не всем же только управлять! Поэтому кодить все-равно придется. Но всегда где-то сбоку в окошке или через задницу.
— Интеграция. Достижение нашей BPMS в том, что есть специальный ящик, который умеет вызывать вебсервис. Правда хост намертво прибит гвоздями без возможности поменять, и все мэппинги нужно мышкой прокликивать в специальном окошечке, но это не беда.
— Ну и как бы зачем? Есть миллион других способов биться головой об стенку. Практика показывает, что эти решения не работают.
Вобщем, BPM — это исключительно инструмент бизнес-аналиста, и пусть таким и остается. А у нас, кодеров, свои приблуды. И нехрен мешать дерьмо с мармеладом!
Все-таки, вопросы из первой части остаются открытыми.
По поводу API: если мой модуль импортирует java.xml.bind, и я хочу инициализировать контекст с моими классами: JAXBContext jc = JAXBContext.newInstance(«com.acme.foo»), то классы com.acme.foo должны быть доступны для java.xml.bind. В предлагаемой схеме, неясно: либо java.xml.bind нужно где-то указать, что ему доступен модуль com.acme.foo для чтения. Плюс мой модуль обязательно должен экспортировать пакет com.acme.foo, чтобы он был видимым для java.xml.bind. Либо вообще юзать java.xml.bind в «безымянном» модуле, но тогда смысла в модулях я не вижу.
По-моему не взлетит. Основная необходимость модульной системы — решать конфликт с версиями транзитивных зависимостей — не решена. Требует радикальных изменений систем сборки. Также затронет существующие фреймворки, сервера приложений, и многие API, которые изначально не рассчитывались на модульную систему. Все ради сомнительной абстрактной цели.
> смерть семи миллионов людей в год от загрязнения окружающей среды
Пруфы в студию.
> За второй дверью — идентичная герметичная комната, но с электромобилем
Шварц лукавит. В комнату к электромобилю нужно добавить дизель-генератор для зарядки. Это только тупой обыватель думает, что если ток из розетки, то он 100% чистый. А пол надо усеять распотрошенными батарейками. Ведь утилизация миллиардов литий-ионных батарей в год не проблема для окружающей среды.
P.S. У меня ощущение, что что-то толстое назревает в политическом плане. Вдруг неожиданно всплыла тема окружающей среды. Скандал с Фольксвагеном… загрязненность в новостях. В европейских городах вдруг запрещают парковаться (типа вдруг уровень NOx скакнул), такси в Норвегии переходит на электро… Какой-то очередной передел, где окружающая среда лишь предлог…
Работаю другой компании в сфере телекоммуникаций (OSS) разработка и интеграция решений. Видел презентации решений Netcracker-а для Одного Большого Клиента. Впечатляет, особенно когда занимаешься почти тем же уже долгое время. Смотрю в сторону Netcracker как альтернативу для дальнейшего профессионального роста, в связи с чем вопрос. Как у вас локализован девелопмент? Я знаю, что основные центры в Штатах и России. Есть ли разработчики из Европы (в т.ч. Испании)? Или это вообще прозрачно?
Сорри за задержку. И все-таки настораживает сильная равномерность распределения. Почему обычная материя склонна образовывать плотные сгустки: облака, звезды, планеты, а ТМ, которая вроде бы также подвержена гравитации, нет? Хоть механизм и одинаковый, но в первом случае гравитация «стягивает» материю, а во втором лишь перемешивает общий бульон и создает небольшие возмущения типа волос.
Кстати, по поводу «волос»: определенный эффект анизотропии вроде бы был обнаружен Шнолем. Вот передача Гордона на этот счет: www.youtube.com/watch?v=ZqROlQkt6GI&list=PLF99B05F40D904963&index=113
Шноль ставит гипотезу, что само пространство анизотропно. Но возможно это влияние флуктуаций темной материи в окресностях Земли.
1. Рантайм грузит каждый модуль собственным classloader-ом, как OSGI? Или как раньше все в общем супе?
2. Как обстоят дела с версионированием модулей и сожительством одинаковых классов разных версий?
3. Что насчет экспорта/импорта ресурсов? ClassLoader.getResources() ищет только экспортнутые ресурсы по всем загруженным модулям, или только в текущем и импортнутых?
4. Экспортирование транзитивно?
5. Я хочу «наследовать» чей-то модуль, т.е. сделать свой модуль, добавив в него пару классов (или перекрыв старые). При этом, ессно, его приватная часть должна быть доступна. Можно ли это?
5. И, наконец, как я понял, импортируемый модуль должен иметь доступ ко всем классам импортирующего. Иначе это нарушит работу кучи библиотек и API. Пример:
JAXBContext jc = JAXBContext.newInstance( «com.acme.foo» );
JAXBContext лежит модуле в java.xml.bind, но доменные классы в com.acme.foo. То есть классы из com.acme.foo должны быть доступны модулю java.xml.bind, даже если он не импортирует модуль com.acme.foo.
6. И наконец, где и как вообще рантайм проверяет private/export class checking? Это фича исключительно classloader-а при резольвинге класса, или вообще JVM следит за тем, чтобы везде и всегда visibility не нарушалась?
Например, я вызываю из своего модуля метод объекта из другого модуля:
Все хорошо, все export-нуто. Но внезапно AnyException.getCause() содержит внутренний эксепшн из другого модуля, который не импортирован. Если рантайм на это не выругается, то есть возможность получить ссылку на ClassLoader импортируемого модуля и загрузить любой внутренний класс: AnyException.getCause().getClass().getClassLoader().loadClass()
С темной материей вообще странная ситуация. С одной стороны ее в 5 раз больше, чем обычной, а с другой — а где она? Проявления видны лишь на больших масштабах ввиде эффектов кинематики вращающихся галактик и гравитационного линзирования. А вот на локальных масштабах она себя никак не проявляет. Хотя чисто умозрительно в той же солнечной системе темной материи должно быть не на каких-то там несколько мифических волос, а как минимум еще на несколько солнц.
Все, что Вы описали, делается быстрее и надежней без JTA. Любая БД всегда поддерживает обычные (локальные) транзакции. Случай, когда нужно обращаться (а именно апдейтить) сразу несколько БД довольно редок, и как правило говорит о плохой архитектуре. В этом случае лучше разделить апдейты разных БД в разные транзакции, а иногда даже делать это асинхронно при помощи того же JMS.
JTA именно дает гарантии, что сообщение не будет продублировано или потеряно, а обработано атомарно вместе с апдейтом БД. В случае, если двухфазный коммит фейлится на второй фазе (да, такое бывает!), то отваливается весь TransactionManager, и будет терпеливо ждать, пока его не починят ручками, и не подправят данные. А это реальный геморрой, особенно в случае нескольких БД.
Без JTA с ручным JMS acknowledgement (ACK) худшее, что может случиться — это когда выполнился коммит в БД, но система свалилась на посылке ACK брокеру. В этом случае случится ределивери (при настроеной персистенции), и возможны дубликаты, которые могут быть проконтролированы отдельно той же БД.
Так что польза от JTA достаточно сомнительная: они тяжелые, медленные, сложнонастраиваемые (в Weblogic 100+ настроек), сложнотестируемые и как правило глючные. В подавляющем большинстве случаев их использование неоправдано поставленной задачей.
Вопрос в том, реально ли нужен JTA и стоит ли ради нее возиться с дерьмом JEE? Все остальное доступно по отдельности, лучше, удобоваримее, и легко подцепляется в виде библиотек.
— Во-первых, JTA создает ложную уверенность в atomicity. Если у Вас грохается ресурс на критической операции (сеть, машина, диски), транзакция становится unrecoverable. Внезапно, transaction manager перестает создавать другие транзакции, пока не будет решена проблема с грохнувшейся. Как это делается в конкретно взятом сервере — знают несколько человек в мире. Пока админ судорожно разбирается как откатить грохнувшуюся транзакцию, где подправить какие данные, работа стоИт.
— Во-вторых, впринципе невозможно создать надежную координированную работу нескольких удаленных систем (теорема CAP). Можно лишь немного приблизить работу, исходя из неочевидных предположений, например, когда сеть и железо более-менее надежно, вероятность сбоя при координированном коммите ничтожно мала. JTA неявно скрывает это, вселяя ложную уверенность в надежности.
— В-третьих, JMS без транзакции имеет ручной ACK, который является аналогом коммита. При этом брокер считает месседж обработанным и удаляет из очереди. Поэтому сначала делаем процессинг месседжа, коммит транзакции в DB, а потом ручками посылаем ACK брокеру. При такой структуре программист уже обязан въявную подумать, что случится, если на ACK грохнется ресурс. JMS в этом случае попробует еще раз прислать сообщение. Обычное решение — вести контроль дубликатов: сохранять в базе данных ID уже обработаных месседжей.
Как вариант, можно минимизировать риски от сбоя сети, если поднимать локально на каждый instance приложения embedded брокер, а затем связывать их в кластер. Сообщения надежно (если нет сбоя железа) отдаются и принимаются только от локального брокера, который уже в свою очередь занимается их пересылкой по сети.
Если так нужен JTA, то есть JBoss Transactions, или Atomikos. Оба интегрируются в Spring. Но в любом случае, JTA — это не панацея, а скорей вред.
Хорошая демонстрация возможностей Xtext — это язык Xtend.
Но все-таки сейчас основная тенденция для метамоделирования — это создание DSL-ей в рамках самого же языка. В основном используются три метода:
1. Создание DSL на основе системы типов языка и вспомогательных API (Builders). Scala особенно этим пестрит. Есть еще Groovy DSL, на основе которого построен Gradle, etc… Синтаксис Java не особо способствует созданию собственных DSL, хотя с появлением лямбд ситуация немного улучшилась.
2. Доступ к синтаксическому дереву на этапе компиляции. Для Scala есть scala.meta, в Java есть для этого AST-трансформации.
3. Генерация кода в рантайме. Очень популярно у многочисленных фреймворков. В основном служат для прозрачного добавления функционала к уже готовой модели.
Ну и еще один очень неплохой метод — использовать стандартные средства XML: XSD для метамоделирования, XML для моделирования и XSLT для трансформации.
Когда я вижу подобные блок-схемы, мне почему-то всегда вспоминается Том Смиковски из «Office Space» и его произведение:
Видимо, в реальном мире у Тома все получилось, он открыл консалтинговую компанию и учит других правильно работать.
По поводу Солнца. Солнце лишь косвенная причина движения Земли вокруг него. Прямая причина — пространство, искривленное массивным телом-Солнцем, в котором прямая траектория принимает форму эллипса орбиты (геодезическая линия).
Если быстро убрать Солнце, пространство на месте него начнет резко "выпрямляться", что сгенерирует гравитационное цунами, которое дойдя до Земли через 8 минут, должно неминуемо разрушить ее приливными силами. Но до тех пор, пока волна не подошла к Земле, искривленное пространство в ее окресностях будет оставаться в точности таким же, и Земля будет продолжать двигаться по своей траектории.
Vaadin позволяет быстро разработать вебприложение типа админки, фактически программируя только серверную часть. Взаимодействие с браузером полностью прозрачно. Плюс в том, что многие нюансы UI уже учтены и идут из коробки. Плюс мепить данные на сервере в typesafe java-объекты на порядок проще, нежели заморочки с Json. Фреймворк будет близок тем, кто разрабатывал приложения на Swing и подобных библиотеках виджетов.
— Долго тянут с релизом. Язык был анонсирован несколько лет назад, и вау эффект уже изрядно поутих. Самое время его было выпустить до Java 8. Сейчас внимание программеров переключилось на джавовские лямбды и стримы, и мощь котлина в их глазах уже поугасла.
— Недостаточная огласка в СМИ. Взять хотя бы Одерски, который пиарит свою скалу везде, где только возможно. Несколько статей на хабре не решат проблемы.
— Нет своего стека технологий. Красивый язык оценят, но без сопутствующих технологий им пользоваться не будут. Вот Groovy некрасивый язык, а им пользуются (про Scala толерантно помалкиваю). Нужен стек типа typesafe (или, упаси господи, JEE) и фреймворки типа play. Кроме того, на первое время нужно определиться с нишей решаемых задач, напр. scala — параллельное программирование, kotlin — андроид, клиентские веб приложения (прощай, GWT), микросервисы. На одной экосистеме Java далеко не уедешь.
— Success stories. Типа «Twitter признал свою ошибку со scala и переписал свой стек на kotlin-е» :)
P.S. Персональное ощущение: пробовал Kotlin несколько раз. Писал несколько проектов. В итоге, за пару часов все переписывал на java и избавлялся от котлина в проекте, ибо отличия в структуре несущественны. Да, код короче, элегантнее, но IDE позволяет быстро писать и на Java.
Насчет leap second: последний раз она добавлялась в полночь 30 июня 2015 года, в связи с чем утром лежало большое количество сервисов, в том числе и java. С чем могут быть связаны подобные сбои?
С BPEL работал и работаю до сих пор. В самой его наихудшей реализации: IBM Websphere Process Server. Oracle SOA выглядит и работает значительно лучше. Самый лучший и во многом продуманный продукт — это JBoss BPM Suite.
Про асинхронное выполнение. Можно взять уже готовый движок jBPM или Activiti. Они в минимальном окружении весят 50кб и ничего дополнительного не требуют. Для Java есть фреймворк Quasar, который прозрачно для кода заменяет треды файберами, которые в свою очередь suspendable и serializable.
BPEL вообще мертворожденный язык. Изначально планировался для оркестрации вебсервисов и выполнения примитивной логики. Но внезапно оказалось, что людям требуется делать нечто бОльшее, чем тупые меппинги полей 1-1 при помощи XPath, а стандарт на этот счет молчал. Поэтому каждый кулибин внедряет в свой BPEL специальные нестандартные ноды типа «Compute», которые позволяют выполнять хоть что-то полезное в какой-нибудь среде: sql, java, etc. Сейчас BPEL повсемесно вытесняется BPMN-ом.
Основное отличие от кода на языке — возможность асинхронного выполнения процесса и «засыпания» с сохранением состояния в базе до прихода события извне, ответа вебсервиса, etc… Но это только для «хороших» BPMS.
О косяках концепта BPM как такового я писал здесь.
Основные части BPMS:
1. Красивая схемка т.н. «бизнес процесса», желательно с визуальной программулиной, позволяющей расставлять на листе «ящички». И которая еще позволяет «запускать» процессы и показывать где он сейчас выполняется. Без этого не ничего продастся.
2. Некий навороченный «BPM-движок» весом в 30кб (jBPM), позволяющий «выполнять» позадачно диаграмму. Практически всегда требует базу данных, чтобы состоянию было куда-то сохраняться.
3. Fallback в какую-нибудь реальную среду проргаммирования: java, xquery, PL, etc… Как ни вертись, а ящики на диаграмме никакой полезной нагрузки не несут — приходится все-таки на чем-то кодить.
4. Паровозом предлагают средства интеграции с внешним миром: какую-нибудь самопальную ESB, JEE коннекторы, адаптеры, вебсервисы, etc…
5. Ну и самая основная часть — портал для Human Task-ов. Без него все ваши BPMS вообще не имеют смысла (а до 2005 года они скромно назывались Workflow). Визуально список папок по таскам а ля Outlook, на каждую задачу убогая стандартная формочка с данными, которую чтобы кастомизировать, то проще свой портал написать.
Что не так с BPM? А практически все.
— Вопреки изначальной идее, как ни старайся, динамически процесс изменить не удастся. Бизнес аналист расставит ящики и стрелочки. Затем каждый ящик закодит кодер. Затем аналист поменяет местами ящики в надежде, что все будет работать, но процесс благополучно упадет. Сколько ни пытался Oracle сделать колаборацию двух тулзов: BAM и BPM — хорошо все только на поверпоинтах.
— Резко поменалась бизнес логика, но половина процессов еще идет по старой версии. А интерфейсы, среда, база, модель — все уже новое. Версионность — основной бич всех BPM. Если в своем велосипеде ты полностью контролируешь педали, и можно эволюционировать запущенные процессы, просто актуализнув базу, то в пропиетарной BPMS — хрен ты до чего докопаешься.
— Возможности портала убоги. Всегда плохо адаптируется к реальным потребностям в интерфейсе. Интегрировать BPM в свой корпоративный портал тот еще танец с бубном.
— Одним BPM-ом сыт не будешь. Ящики должны выполнять какие-то полезные действия. Не всем же только управлять! Поэтому кодить все-равно придется. Но всегда где-то сбоку в окошке или через задницу.
— Интеграция. Достижение нашей BPMS в том, что есть специальный ящик, который умеет вызывать вебсервис. Правда хост намертво прибит гвоздями без возможности поменять, и все мэппинги нужно мышкой прокликивать в специальном окошечке, но это не беда.
— Ну и как бы зачем? Есть миллион других способов биться головой об стенку. Практика показывает, что эти решения не работают.
Вобщем, BPM — это исключительно инструмент бизнес-аналиста, и пусть таким и остается. А у нас, кодеров, свои приблуды. И нехрен мешать дерьмо с мармеладом!
По поводу API: если мой модуль импортирует java.xml.bind, и я хочу инициализировать контекст с моими классами: JAXBContext jc = JAXBContext.newInstance(«com.acme.foo»), то классы com.acme.foo должны быть доступны для java.xml.bind. В предлагаемой схеме, неясно: либо java.xml.bind нужно где-то указать, что ему доступен модуль com.acme.foo для чтения. Плюс мой модуль обязательно должен экспортировать пакет com.acme.foo, чтобы он был видимым для java.xml.bind. Либо вообще юзать java.xml.bind в «безымянном» модуле, но тогда смысла в модулях я не вижу.
Пруфы в студию.
> За второй дверью — идентичная герметичная комната, но с электромобилем
Шварц лукавит. В комнату к электромобилю нужно добавить дизель-генератор для зарядки. Это только тупой обыватель думает, что если ток из розетки, то он 100% чистый. А пол надо усеять распотрошенными батарейками. Ведь утилизация миллиардов литий-ионных батарей в год не проблема для окружающей среды.
P.S. У меня ощущение, что что-то толстое назревает в политическом плане. Вдруг неожиданно всплыла тема окружающей среды. Скандал с Фольксвагеном… загрязненность в новостях. В европейских городах вдруг запрещают парковаться (типа вдруг уровень NOx скакнул), такси в Норвегии переходит на электро… Какой-то очередной передел, где окружающая среда лишь предлог…
Кстати, по поводу «волос»: определенный эффект анизотропии вроде бы был обнаружен Шнолем. Вот передача Гордона на этот счет: www.youtube.com/watch?v=ZqROlQkt6GI&list=PLF99B05F40D904963&index=113
Шноль ставит гипотезу, что само пространство анизотропно. Но возможно это влияние флуктуаций темной материи в окресностях Земли.
1. Рантайм грузит каждый модуль собственным classloader-ом, как OSGI? Или как раньше все в общем супе?
2. Как обстоят дела с версионированием модулей и сожительством одинаковых классов разных версий?
3. Что насчет экспорта/импорта ресурсов? ClassLoader.getResources() ищет только экспортнутые ресурсы по всем загруженным модулям, или только в текущем и импортнутых?
4. Экспортирование транзитивно?
5. Я хочу «наследовать» чей-то модуль, т.е. сделать свой модуль, добавив в него пару классов (или перекрыв старые). При этом, ессно, его приватная часть должна быть доступна. Можно ли это?
5. И, наконец, как я понял, импортируемый модуль должен иметь доступ ко всем классам импортирующего. Иначе это нарушит работу кучи библиотек и API. Пример:
JAXBContext jc = JAXBContext.newInstance( «com.acme.foo» );
JAXBContext лежит модуле в java.xml.bind, но доменные классы в com.acme.foo. То есть классы из com.acme.foo должны быть доступны модулю java.xml.bind, даже если он не импортирует модуль com.acme.foo.
6. И наконец, где и как вообще рантайм проверяет private/export class checking? Это фича исключительно classloader-а при резольвинге класса, или вообще JVM следит за тем, чтобы везде и всегда visibility не нарушалась?
Например, я вызываю из своего модуля метод объекта из другого модуля:
servicemodule.AnyService.anyMethod(params) throws AnyException
Все хорошо, все export-нуто. Но внезапно AnyException.getCause() содержит внутренний эксепшн из другого модуля, который не импортирован. Если рантайм на это не выругается, то есть возможность получить ссылку на ClassLoader импортируемого модуля и загрузить любой внутренний класс: AnyException.getCause().getClass().getClassLoader().loadClass()
JTA именно дает гарантии, что сообщение не будет продублировано или потеряно, а обработано атомарно вместе с апдейтом БД. В случае, если двухфазный коммит фейлится на второй фазе (да, такое бывает!), то отваливается весь TransactionManager, и будет терпеливо ждать, пока его не починят ручками, и не подправят данные. А это реальный геморрой, особенно в случае нескольких БД.
Без JTA с ручным JMS acknowledgement (ACK) худшее, что может случиться — это когда выполнился коммит в БД, но система свалилась на посылке ACK брокеру. В этом случае случится ределивери (при настроеной персистенции), и возможны дубликаты, которые могут быть проконтролированы отдельно той же БД.
Так что польза от JTA достаточно сомнительная: они тяжелые, медленные, сложнонастраиваемые (в Weblogic 100+ настроек), сложнотестируемые и как правило глючные. В подавляющем большинстве случаев их использование неоправдано поставленной задачей.
— Во-первых, JTA создает ложную уверенность в atomicity. Если у Вас грохается ресурс на критической операции (сеть, машина, диски), транзакция становится unrecoverable. Внезапно, transaction manager перестает создавать другие транзакции, пока не будет решена проблема с грохнувшейся. Как это делается в конкретно взятом сервере — знают несколько человек в мире. Пока админ судорожно разбирается как откатить грохнувшуюся транзакцию, где подправить какие данные, работа стоИт.
— Во-вторых, впринципе невозможно создать надежную координированную работу нескольких удаленных систем (теорема CAP). Можно лишь немного приблизить работу, исходя из неочевидных предположений, например, когда сеть и железо более-менее надежно, вероятность сбоя при координированном коммите ничтожно мала. JTA неявно скрывает это, вселяя ложную уверенность в надежности.
— В-третьих, JMS без транзакции имеет ручной ACK, который является аналогом коммита. При этом брокер считает месседж обработанным и удаляет из очереди. Поэтому сначала делаем процессинг месседжа, коммит транзакции в DB, а потом ручками посылаем ACK брокеру. При такой структуре программист уже обязан въявную подумать, что случится, если на ACK грохнется ресурс. JMS в этом случае попробует еще раз прислать сообщение. Обычное решение — вести контроль дубликатов: сохранять в базе данных ID уже обработаных месседжей.
Как вариант, можно минимизировать риски от сбоя сети, если поднимать локально на каждый instance приложения embedded брокер, а затем связывать их в кластер. Сообщения надежно (если нет сбоя железа) отдаются и принимаются только от локального брокера, который уже в свою очередь занимается их пересылкой по сети.
Если так нужен JTA, то есть JBoss Transactions, или Atomikos. Оба интегрируются в Spring. Но в любом случае, JTA — это не панацея, а скорей вред.
Но все-таки сейчас основная тенденция для метамоделирования — это создание DSL-ей в рамках самого же языка. В основном используются три метода:
1. Создание DSL на основе системы типов языка и вспомогательных API (Builders). Scala особенно этим пестрит. Есть еще Groovy DSL, на основе которого построен Gradle, etc… Синтаксис Java не особо способствует созданию собственных DSL, хотя с появлением лямбд ситуация немного улучшилась.
2. Доступ к синтаксическому дереву на этапе компиляции. Для Scala есть scala.meta, в Java есть для этого AST-трансформации.
3. Генерация кода в рантайме. Очень популярно у многочисленных фреймворков. В основном служат для прозрачного добавления функционала к уже готовой модели.
Ну и еще один очень неплохой метод — использовать стандартные средства XML: XSD для метамоделирования, XML для моделирования и XSLT для трансформации.
Видимо, в реальном мире у Тома все получилось, он открыл консалтинговую компанию и учит других правильно работать.