1. Чтобы документы, регламентирующие процессы взаимодействия с Заказчиком, «работали», необходимо чтобы процессы самого Исполнителя в точности соответствовали этим регламентам. Иначе получится, что вы принесли заказчику просто красивый документ «для галочки», который вам самому не близок.
2. А чтобы процессы работали у вас, необходимо чтобы они были автоматизированы. Иначе любые процессы неизбежно будут прогибаться под особенности каждого отдельного заказчика и получится бардак.
Для «динамического инстанцирования объектов» в JDK есть масса способов.
А вы-то инстанцируете не просто «объекты» а конкретно java.lang.Class — особый объект, не предназначенный для прямого инстанцирования.
Но в целом понятно — видимо, для вас это просто fun :)
Вы описали аж 6 заходов на то, чтобы вызвать конструктор java.lang.Class, но так и не обозначили ЗАЧЕМ вы это задумали. Вот лишь некоторые из вопросов, на которые статья даже не пытается ответить:
— Какое будет имя у класса, который инстанцируете (что вернет getName())?
— Какие у него будут методы и поля?
— Как он будет связан с класс-лоадером (просто установка приватного поля в самом инстансе класса очевидно недостаточно)?
Даже если бы у вас получилось, вы на выходе будете иметь заведомо нерабочую конструкцию — зачем??
Если вы это все делаете просто из желания «обмануть систему» — тогда Ok, как говорится, «каждый борется со скукой по-своему».
Но если вы хотели вручную создать экземпляр класса, еще не загруженного JVM, то для этого есть нормальный путь:
1. Загрузить байткод (т.е. файл my/package/MyClass.class) в массив байт
2. Вызвать ClassLoader.defineClass(...) в том класслоадере, в котором хотите иметь вновь загруженный класс.
Вот краткий HOWTO про то, о чем что я писал выше:
http://www.nirendra.net/cms/java/linux
Но если серьезно, то это все игрушки.
Как, например, Вы будете устанавливать максимальный размер кучи, разные системные переменные, настройки GC, режим дебага и т.п.?
А Вы когда-нибудь ядро Linux перекомпилировали самостоятельно?
Я помню, еще в дремучие 2000-е годы (а то и в конце 90-х) при конфигурировании ядра Linux была такая опция: Support for Java binaries.
Если ее включить — то достаточно было потом сделать только «chmod +x MyJavaClass.class» — и он запускался непосредственно, безо всяких скриптов.
С тех пор уже много воды утекло, конечно… но все же, это, часом, не то, что Вы искали?
Я не буду упоминать про классическое определение вероятности — полагаю, оно всем известно.
Но даже из чисто практических соображений матрица смежности должна содержать значения вероятностей от 0 до 1. Потому что, например, вероятность перехода за N шагов — это матрица смежности в N-ной степени, стационарные вероятности — это результат решения САУ на основе матрицы смежности и т.д.
Вы ведь не просто так марковскую цепь моделируете — вы, наверное, хотите эту модель затем как-то исследовать. Для этого, я полагаю, лучше придерживаться классики.
Идея о том, что целые числа генерировать удобнее — вообще непонятна.
В каждой строке у нас есть ненулевые значения в тех столбцах, чей номер совпадает с последующим событием, а само ненулевое значение — вероятность, что это событие наступит
Подход хорош.
Но что-то мне кажется, что при таком подходе Major-версия вообще никогда меняться не будет.
Получится эдакое Java-style версионирование, до сих пор формально последняя версия Java — это 1.8 (т.к. совместимость поддерживается), но количество новых добавленных фич такое, что уже давно все говорят «Java 8-й версии», т.е. major-составляющая вырождается.
Возможно то, о чем я упомянул, — это не самые «простые вещи», но определенно необходимые любому новичку (да и не только), потому что с ними он столкнется ровно в тот самый момент, как только начнет использовать логгер.
Понимаю, что такую готовую статью найти трудно — потому и поинтересовался опытом DataArt. :)
Статья неплохая, но увы! — в ней разбираются только простейшие практики организации и настройки логирования. При этом за кадром остались, возможно, самые принципиально важные вещи: что, когда и как логировать.
Было бы очень интересно, например, узнать опыт DataArt в части
— шаблонов строк лога (чтобы grep-апь потом было легче)
— правил, регламентирующих обязательность логирования того или иного (например, исключения должны попадать в лог всегда или только при каких-то определенных обстоятельствах)
— взаимоотношения try-catch-throw и практик ведения логов (например, логировать ли что-нибудь при перевыбросе исключений)
— подходов к разруливанию «вложенного логирования» (когда часто используемый метод-утилита что-то логирует, и это иногда помогает, а иногда мешает)
— одновременного ведения нескольких логов (разбиваемых, например, по уровню) — хорошо это или плохо, помогает или нет и т.п.
— вопросов синхронизации лога на клиентской и серверной сторонах приложения
Спасибо, очень содержательно.
Было бы также интересно получить сравнительный анализ аналогичных библиотек (вы ведь его commons-cli не просто так выбрали).
Желательно.
Прочесть книгу я и сам могу (тем более что это практически классика), гораздо интереснее узнать личное мнение автора по поводу прочитанного. Может быть, он сталкивался с примерами в жизни, которые бы уточняли, поясняли или даже опровергали тезисы Брукса-Ханта — вот это было бы гораздо интереснее.
Поддерживаю VaiMR. Статья похожа на пересказ своими словами некоторых идей из упомянутых книг. Пересказ, кстати, хороший — кратко, ясно и приятным языком, но кроме этого никакой собственной работы автора не видно.
Несколько суток в режиме зомби — это все-таки из области программирования серверных приложений, а у меня Swing. В отрыве от контекста — безусловно, отлов Throwable есть зло.
Исправил код в статье, дабы не вводить в соблазн новичков. :)
А что будет с системой в случае ядерного удара?
OutOfMemoryError — это по-любому трындец и перезапуск приложения. Поэтому, отвечая на ваш вопрос, скажу — ничего хорошего не будет, но не будет его и в случае отлова Exception вместо Throwable.
Поверьте, я знаю все «за» и «против», читал это и другие умные статьи и книги. Решение ловить Throwable или Exception — это всегда компромисс. В моем случае, например, подписчики, подключаемые из плагинов, могли иногда выкинуть NoClassDefFoundError. Это, конечно, тоже не дело, но в процессе разработки и экплуатации софта оно визникало на порядки чаще, чем OOME, отсюда и решение — ловить Throwable.
Но конечно, я не призываю всех всегда поступать именно так (да и статья, в общем-то совсем не о том).
Посмотрел. Действительно интересно, спасибо за ссылку!
По сути Announcer — это то же самое, только он не сам является прокси, а агрегирует ее. Не очень понятно только, зачем там реализация InvocationHandler перенесена, по сути, в сам Announcer (я бы вместо анонимного сделал inner класс и всю реализацию в нем), но это несущественно.
Про лишний final при приватном конструкторе — согласен, принимается.
Про то, что код пишется для людей — тоже, конечно, согласен.
По остальному — не согласен, могу поспорить, но не буду, т.к. подобный спор явно не относится к теме статьи. :)
В любом случае, спасибо за замечания!
2. А чтобы процессы работали у вас, необходимо чтобы они были автоматизированы. Иначе любые процессы неизбежно будут прогибаться под особенности каждого отдельного заказчика и получится бардак.
:)
А вы-то инстанцируете не просто «объекты» а конкретно java.lang.Class — особый объект, не предназначенный для прямого инстанцирования.
Но в целом понятно — видимо, для вас это просто fun :)
— Какое будет имя у класса, который инстанцируете (что вернет getName())?
— Какие у него будут методы и поля?
— Как он будет связан с класс-лоадером (просто установка приватного поля в самом инстансе класса очевидно недостаточно)?
Даже если бы у вас получилось, вы на выходе будете иметь заведомо нерабочую конструкцию — зачем??
Если вы это все делаете просто из желания «обмануть систему» — тогда Ok, как говорится, «каждый борется со скукой по-своему».
Но если вы хотели вручную создать экземпляр класса, еще не загруженного JVM, то для этого есть нормальный путь:
1. Загрузить байткод (т.е. файл my/package/MyClass.class) в массив байт
2. Вызвать ClassLoader.defineClass(...) в том класслоадере, в котором хотите иметь вновь загруженный класс.
http://www.nirendra.net/cms/java/linux
Но если серьезно, то это все игрушки.
Как, например, Вы будете устанавливать максимальный размер кучи, разные системные переменные, настройки GC, режим дебага и т.п.?
Я помню, еще в дремучие 2000-е годы (а то и в конце 90-х) при конфигурировании ядра Linux была такая опция: Support for Java binaries.
Если ее включить — то достаточно было потом сделать только «chmod +x MyJavaClass.class» — и он запускался непосредственно, безо всяких скриптов.
С тех пор уже много воды утекло, конечно… но все же, это, часом, не то, что Вы искали?
Но даже из чисто практических соображений матрица смежности должна содержать значения вероятностей от 0 до 1. Потому что, например, вероятность перехода за N шагов — это матрица смежности в N-ной степени, стационарные вероятности — это результат решения САУ на основе матрицы смежности и т.д.
Вы ведь не просто так марковскую цепь моделируете — вы, наверное, хотите эту модель затем как-то исследовать. Для этого, я полагаю, лучше придерживаться классики.
Идея о том, что целые числа генерировать удобнее — вообще непонятна.
Вы вероятность в процентах, что ли, измеряете?
Но что-то мне кажется, что при таком подходе Major-версия вообще никогда меняться не будет.
Получится эдакое Java-style версионирование, до сих пор формально последняя версия Java — это 1.8 (т.к. совместимость поддерживается), но количество новых добавленных фич такое, что уже давно все говорят «Java 8-й версии», т.е. major-составляющая вырождается.
Понимаю, что такую готовую статью найти трудно — потому и поинтересовался опытом DataArt. :)
Было бы очень интересно, например, узнать опыт DataArt в части
— шаблонов строк лога (чтобы grep-апь потом было легче)
— правил, регламентирующих обязательность логирования того или иного (например, исключения должны попадать в лог всегда или только при каких-то определенных обстоятельствах)
— взаимоотношения try-catch-throw и практик ведения логов (например, логировать ли что-нибудь при перевыбросе исключений)
— подходов к разруливанию «вложенного логирования» (когда часто используемый метод-утилита что-то логирует, и это иногда помогает, а иногда мешает)
— одновременного ведения нескольких логов (разбиваемых, например, по уровню) — хорошо это или плохо, помогает или нет и т.п.
— вопросов синхронизации лога на клиентской и серверной сторонах приложения
ну и других подобных аспектов.
Было бы также интересно получить сравнительный анализ аналогичных библиотек (вы ведь его commons-cli не просто так выбрали).
Прочесть книгу я и сам могу (тем более что это практически классика), гораздо интереснее узнать личное мнение автора по поводу прочитанного. Может быть, он сталкивался с примерами в жизни, которые бы уточняли, поясняли или даже опровергали тезисы Брукса-Ханта — вот это было бы гораздо интереснее.
Исправил код в статье, дабы не вводить в соблазн новичков. :)
OutOfMemoryError — это по-любому трындец и перезапуск приложения. Поэтому, отвечая на ваш вопрос, скажу — ничего хорошего не будет, но не будет его и в случае отлова Exception вместо Throwable.
Поверьте, я знаю все «за» и «против», читал это и другие умные статьи и книги. Решение ловить Throwable или Exception — это всегда компромисс. В моем случае, например, подписчики, подключаемые из плагинов, могли иногда выкинуть NoClassDefFoundError. Это, конечно, тоже не дело, но в процессе разработки и экплуатации софта оно визникало на порядки чаще, чем OOME, отсюда и решение — ловить Throwable.
Но конечно, я не призываю всех всегда поступать именно так (да и статья, в общем-то совсем не о том).
По сути Announcer — это то же самое, только он не сам является прокси, а агрегирует ее. Не очень понятно только, зачем там реализация InvocationHandler перенесена, по сути, в сам Announcer (я бы вместо анонимного сделал inner класс и всю реализацию в нем), но это несущественно.
Про то, что код пишется для людей — тоже, конечно, согласен.
По остальному — не согласен, могу поспорить, но не буду, т.к. подобный спор явно не относится к теме статьи. :)
В любом случае, спасибо за замечания!