Ну как это никто не пишет? Даже джавовский почти стандартный Jersey умеет уже давно проксировать клиента. Причем один и тот же аннотированный интерфейс можно использовать как для клиента, так и для сервиса.
Джавовский RMI в его основе — это совсем не про то, как клиенту что-то вызвать на сервере через Java Proxy. RMI — это распределенная сеть, там нет ни сервера, ни клиента, есть только peer-s. Любой Remote-объект может быть передан по сети любому из peer-ов точно также как и обычный, например в качестве параметра к удаленному методу или поля объекта. При реализации истинного RMI вам придется решать такие задачи как call-routig, call-forwarding, service discovery, и distributed garbage collector.
Работая в Sun, я верил в технологию Java. Я делал доклады на JavaONE,...
То есть чел реально не фигачил и не поддерживал ни одного проекта с достаточно большой кодовой базой. В лучшем случае делал демки и хелло ворлды для конференций. Поэтому весь остальной опус можно смело смывать в унитаз как малозначимый субъективный опыт.
Программы на Java полны шаблонного кода, который скрывает намерения программиста.
Пишите проще, вас никто не заставляет писать шаблонно.
Разработка с использованием Spring — это, до определённого момента, занятие приятное.
Spring — это инструмент. Если не умеете им пользоваться, то есть только два варианта: либо не пользуйтесь, либо учитесь.
Платформа Java EE была проектом, созданным, так сказать, «всеобщими усилиями»
JEE — это страшный сон для Java родом из конца 90-х, который слава богу скоро сдохнет.
Программирование для Node.js — это сплошное удовольствие.
Для человека, который и на джаве никогда серьезно не программировал впринципе все-равно на каком языке писать демку или "хелло ворлд". Он неизменно будет считать, что чем меньше букв в программе, тем лучше.
В JavaScript нет строгой типизации, характерной для Java. Это — благословение и проклятие языка.
Нет. Отсутствие типизации — это неизменный атрибут всех write-only language.
Обратная сторона строгой типизации Java — это необходимость в постоянном выполнении шаблонных действий. Программист постоянно производит приведение типов или занимается проверкой того, чтобы всё было в точности так, как ожидается.
Это вообще пальцем в небо. Программист на Java в первую очередь занимается ДИЗАЙНОМ приложения, когда описыавет интерфейсы, классы и методы. А частое приведение типов говорит как раз о плохом дизайне, и что программисту лучше вообще писать на JavaScript. С "шаблонным кодом" легко справляется любая IDE, а кроме того, с появлением лямбд он свелся к минимуму. "Проверкой как ожидается" занимается не программист, компилятор и IDE, причем прямо в реальном времени.
В JavaScript типы переменных не указывают при их объявлении, приведение типов обычно не используется, и так далее. В результате код легче читать,
Да нифига не легче. Когда вы видите переменную или параметр, который может быть всем чем угодно, и с "емким" однобуквенным именем… Да и писать тоже не легче, именно из-за отсутствия поддержки IDE и выпадающих пропертей объекта. Хорошо, когда знакомы по памяти с библиотекой...
Сообщество Node.js опубликовало в репозитории npm сотни тысяч пакетов. При этом использовать пакеты, которых нет в npm, так же легко, как и пакеты из npm.
Да, все очень круто. Мы все помним историю с "left-pad", который ВНЕЗАПНО! сломал тысячи проектов… И одно то, что куча JS-программеров испытывает нужду в стороннем "пакете" длиной 11 строчек, говорит о многом...
Выбор того или иного языка или фреймворка должен определяться техническими соображениями.
Выбор технологии должен определаться в большей степени эстетическими соображениями. А как известно, "о вкусах не спорят, не спорят вообще...".
Я всегда думал, что сложность строки связана с понятием энтропии, и что ее очень просто вычислить, просто пройдясь по ней gzip-ом.
P.S. бытует мнение, что любая заданная последовательность содержится в записи числа пи. Программа просто должна выдать позицию, с которой нужно считывать последовательность. )))
Что бы еще ну очень хотелось бы от корутин в Котлине:
вещь подобная ThreadLocal, которая бы идентифицировала текущий scope корутины, например доступ к CoroutineContext
более-менее стандартизированная сериализация корутин. Для длительных бизнес-процессов или пользовательского ввода требуется заперсистить состояние корутины в базе данных, чтобы освободить память. Хотелось бы чтобы при деплое новой версии корутины можно было бы подправить ручками сериализированные данные от старой корутины.
улучшить трассировочную информацию при возникновении исключения. То, что лежит в stackTrace совсем не то, чтобы хотелось иметь в итоге.
Ну вот я пробовал официальные туториалы в т.ч. create react kotlin app и котлиновский tictactoe. Они все используют gradle kotlin frontend plugin, который в свою очередь пускает npm, webpack и babel. Когда я меняю строчку и делаю рефреш, все-равно компилится около 30 секунд — не важно, новый бандл или рефрешнутый. Пробовал поковыряться с настройками, но по ходу нет способа ускорить.
Компиляцию не учитываю. Запуск JVM и бутстрап приложения. Я всегда пользую Embedded Jetty, который сам по себе стартует меньше секунды. Архитектура, где нужно запускать сторонний сервер и туда что-то деплоить — это из эры динозавнов. Приложение обычно использует легкий фреймворк типа Javalin, пускает Flyway для базы, зачастую также использую Eclipselink (JPA), который пускается в 3-5 раз быстрее Hibernate. Иногда прикручиваю Google Guice для DI, но это лишних 0.5 — 0.7 секунд стартапа. Spring (Boot) принципиально не использую.
У нас контроллер выдал ошибку записи, после чего линукс перемонтировал систему в R/O. После этого система работала еще 6 месяцев, пока не заменили диск :)
Для меня критично в 2018 году ждать 30 секунд на любое изменение. С увеличением кодовой базы и используемых сторонних модулей это время будет только расти. Тогда как на сам перезапуск сервера тратится 1.5 секунды (Embedded Jetty).
Проблема там не столько в самом компиляторе Котлина, сколько в бандлере. Чем больше библиотек — тем дольше приходится ждать. Простой хелло ворлд компилируется 10 секунд. Подключите React и время сразу увеличивается до 30.
Плюс ко всему отсутствие документации, нормальных примеров, гайдов и шаблонов для проекта. Вобщем, пока еще более чем зелено.
Я как-то решил попробовать пару примеров, которые есть на GitHub-е на тему Kotlin + React. Предлагаемые решения очень сильно интегрированы в инфраструктуру JS с использованием его жуткого билд-стека, поверх которого еще стоят gradle-плагины.
Из неприятных эффектов — полная рекомпиляция бандла при любом малейшем изменении, которое может длиться от 30 сек. и больше взависимости от кодовой базы. Разрабатывать с таким темпом практически невозможно, из-за чего до сих пор юзаю GWT, который умеет инкрементальную компиляцию.
Сейчас иду на enterprice проект, где требуется Java EE и IBM-Webshpere
Искренне сочуствую!
Возьмите Spring (не boot), напишите на нем стандартное приложение, погоняйте, потестируйте. Затем сделайте отдельную конфигурацию контекста для деплоя на JEE сервер. Поверьте, так будет лучше. Многие, кто пишут под JEE, делают это на спринге.
во-первых, события обрабатываются синхронно или асинхронно?
отсылка нового сообщения изнутри хендлера обрабатывается сразу же или ставится в очередь и обрабатывается по завершении текущего сообщения?
при создании новой подписки изнутри текущего хендлера на это же сообщение будет ли обрабатываемое сообщение переслано новому хендлеру?
если из текущего хендлера я отписываю другой хендлер, который должен будет обработать данное событие, будет ли ему послано текущее событие после такой отписки?
как поведет себя EventBus если я два раза вызову subscribe с одиними и теми же параметрами?
при возникновении исключительной ситуации внутри хендлера, будет ли сообщение доставлено другим хендлерам или же цепочка прервется?
можно ли один и тот же обработчик регистрировать для разных событий?
А, прикрутили-таки, вижу: https://github.com/vaadin/framework/issues/8477
Еще одна неприятная вещь у восьмерки — stateless tabs. Когда переключаешься между табами, state текущей вкладки заново запрашивается с сервера. Когда у тебя в каждом табе редактор текста на сотню килобайт, переключаться становится накладно.
Проблема в том, что не успев как следует выпустить Vaadin 8 они уже выпускают Vaadin 10. Большинство аддонов не успело мигрировать даже под Vaadin 8, и вероятно, никогда уже не мигрирует под Vaadin 10. Для десятки там фактически пустой репозиторий. А количество компонентов в самом Vaadin более чем ограничено. Даже простого confirmation dialog нет.
И такое впечатление, что возможностей от версии к версии становится меньше. Например, в восьмерке в Grid-е исчез метод editRow(), который нужен был, чтобы добавить пустую запись и редактировать ее inline. Теперь нужно дополнительно открывать форму.
Процедура Code Enhancement-а модифицирует байт-код, перехватывая вызовы геттеров и сеттеров для более эффективной инициализации LAZY-полей и оптимального dirty-checking-а. Для этого требуется настроить maven или gradle plugin. В JavaEE контейнерах, а также Spring Data делают code enhancement в рантайме при загрузке классов. Для standalone приложений тоже есть определенный трюк для runtime code enbancement.
Hibernate не умеет EntityGraph.fetchgraph для "@Basic" полей, даже если сделан code enhancement. То есть если вам нужно загрузить только часть полей сущности, придется запрашивать их въявную в select-е. Issue в Jira уже более 5 лет: https://hibernate.atlassian.net/browse/HHH-8776
Есть определенные проблемы с compound primary keys, например не все базы данных могут использовать compound PKs в семантике IN(), однако Hibernate их генерирует как ни в чем ни бывало.
Проблема не в сервере приложений как таковом, а в том, что девелопить под него фактически невозможно. Если ваш проект невозможно запустить в дебаг режиме одним кликом из classpath вашей IDE — то извитите, это не проект, а технологическая помойка. И не важно Application Server это или Docker. Если ваш джава-проект не работает без докера, то это такое же дерьмо, как и проект на JavaEE.
Я с корутинами вижу одну проблему: код, который использует явно или неявно парадигму ThreadLocal, перестанет работать правильно. С корутинами мы с одной стороны не можем больше нигде полагаться на Thread.currentThread(), а с другой у нас нет аналогичной сущности, которая бы идентифицировала текущий (асинхронный) контекст выполнения. А вот например Quasar правильно обрабатывает ThreadLocal, т.к. Fiber ведет себя аналогично треду.
Ну как это никто не пишет? Даже джавовский почти стандартный Jersey умеет уже давно проксировать клиента. Причем один и тот же аннотированный интерфейс можно использовать как для клиента, так и для сервиса.
Джавовский RMI в его основе — это совсем не про то, как клиенту что-то вызвать на сервере через Java Proxy. RMI — это распределенная сеть, там нет ни сервера, ни клиента, есть только peer-s. Любой Remote-объект может быть передан по сети любому из peer-ов точно также как и обычный, например в качестве параметра к удаленному методу или поля объекта. При реализации истинного RMI вам придется решать такие задачи как call-routig, call-forwarding, service discovery, и distributed garbage collector.
Может быть то, что вы хотели сделать, уже существует?
То есть чел реально не фигачил и не поддерживал ни одного проекта с достаточно большой кодовой базой. В лучшем случае делал демки и хелло ворлды для конференций. Поэтому весь остальной опус можно смело смывать в унитаз как малозначимый субъективный опыт.
Пишите проще, вас никто не заставляет писать шаблонно.
Spring — это инструмент. Если не умеете им пользоваться, то есть только два варианта: либо не пользуйтесь, либо учитесь.
JEE — это страшный сон для Java родом из конца 90-х, который слава богу скоро сдохнет.
Для человека, который и на джаве никогда серьезно не программировал впринципе все-равно на каком языке писать демку или "хелло ворлд". Он неизменно будет считать, что чем меньше букв в программе, тем лучше.
Нет. Отсутствие типизации — это неизменный атрибут всех write-only language.
Это вообще пальцем в небо. Программист на Java в первую очередь занимается ДИЗАЙНОМ приложения, когда описыавет интерфейсы, классы и методы. А частое приведение типов говорит как раз о плохом дизайне, и что программисту лучше вообще писать на JavaScript. С "шаблонным кодом" легко справляется любая IDE, а кроме того, с появлением лямбд он свелся к минимуму. "Проверкой как ожидается" занимается не программист, компилятор и IDE, причем прямо в реальном времени.
Да нифига не легче. Когда вы видите переменную или параметр, который может быть всем чем угодно, и с "емким" однобуквенным именем… Да и писать тоже не легче, именно из-за отсутствия поддержки IDE и выпадающих пропертей объекта. Хорошо, когда знакомы по памяти с библиотекой...
Да, все очень круто. Мы все помним историю с "left-pad", который ВНЕЗАПНО! сломал тысячи проектов… И одно то, что куча JS-программеров испытывает нужду в стороннем "пакете" длиной 11 строчек, говорит о многом...
Выбор технологии должен определаться в большей степени эстетическими соображениями. А как известно, "о вкусах не спорят, не спорят вообще...".
Я всегда думал, что сложность строки связана с понятием энтропии, и что ее очень просто вычислить, просто пройдясь по ней gzip-ом.
P.S. бытует мнение, что любая заданная последовательность содержится в записи числа пи. Программа просто должна выдать позицию, с которой нужно считывать последовательность. )))
Что бы еще ну очень хотелось бы от корутин в Котлине:
Ну вот я пробовал официальные туториалы в т.ч. create react kotlin app и котлиновский tictactoe. Они все используют gradle kotlin frontend plugin, который в свою очередь пускает npm, webpack и babel. Когда я меняю строчку и делаю рефреш, все-равно компилится около 30 секунд — не важно, новый бандл или рефрешнутый. Пробовал поковыряться с настройками, но по ходу нет способа ускорить.
Компиляцию не учитываю. Запуск JVM и бутстрап приложения. Я всегда пользую Embedded Jetty, который сам по себе стартует меньше секунды. Архитектура, где нужно запускать сторонний сервер и туда что-то деплоить — это из эры динозавнов. Приложение обычно использует легкий фреймворк типа Javalin, пускает Flyway для базы, зачастую также использую Eclipselink (JPA), который пускается в 3-5 раз быстрее Hibernate. Иногда прикручиваю Google Guice для DI, но это лишних 0.5 — 0.7 секунд стартапа. Spring (Boot) принципиально не использую.
Просто вовремя не заметили. Там только веб и серваки вертелись, а база была на другой машине. Поэтому все работало. Диск вроде Samsung был.
У нас контроллер выдал ошибку записи, после чего линукс перемонтировал систему в R/O. После этого система работала еще 6 месяцев, пока не заменили диск :)
Для меня критично в 2018 году ждать 30 секунд на любое изменение. С увеличением кодовой базы и используемых сторонних модулей это время будет только расти. Тогда как на сам перезапуск сервера тратится 1.5 секунды (Embedded Jetty).
Проблема там не столько в самом компиляторе Котлина, сколько в бандлере. Чем больше библиотек — тем дольше приходится ждать. Простой хелло ворлд компилируется 10 секунд. Подключите React и время сразу увеличивается до 30.
Плюс ко всему отсутствие документации, нормальных примеров, гайдов и шаблонов для проекта. Вобщем, пока еще более чем зелено.
Я как-то решил попробовать пару примеров, которые есть на GitHub-е на тему Kotlin + React. Предлагаемые решения очень сильно интегрированы в инфраструктуру JS с использованием его жуткого билд-стека, поверх которого еще стоят gradle-плагины.
Из неприятных эффектов — полная рекомпиляция бандла при любом малейшем изменении, которое может длиться от 30 сек. и больше взависимости от кодовой базы. Разрабатывать с таким темпом практически невозможно, из-за чего до сих пор юзаю GWT, который умеет инкрементальную компиляцию.
Начинаем наш Quiz:
В Jersey есть очень удобная фича, когда аннотированный jaxrs-интерфейс можно использовать как для сервера, так и для клиента. Тут по ходу такого нет.
А, прикрутили-таки, вижу: https://github.com/vaadin/framework/issues/8477
Еще одна неприятная вещь у восьмерки — stateless tabs. Когда переключаешься между табами, state текущей вкладки заново запрашивается с сервера. Когда у тебя в каждом табе редактор текста на сотню килобайт, переключаться становится накладно.
Проблема в том, что не успев как следует выпустить Vaadin 8 они уже выпускают Vaadin 10. Большинство аддонов не успело мигрировать даже под Vaadin 8, и вероятно, никогда уже не мигрирует под Vaadin 10. Для десятки там фактически пустой репозиторий. А количество компонентов в самом Vaadin более чем ограничено. Даже простого confirmation dialog нет.
И такое впечатление, что возможностей от версии к версии становится меньше. Например, в восьмерке в Grid-е исчез метод editRow(), который нужен был, чтобы добавить пустую запись и редактировать ее inline. Теперь нужно дополнительно открывать форму.
Еще могу добавить:
Конкретно, в чем состоит эта ваша мифическая МОЩЬ? Какие такие бонусы вы привыкли получать от JavaEE, которых не существует в природе?
Проблема не в сервере приложений как таковом, а в том, что девелопить под него фактически невозможно. Если ваш проект невозможно запустить в дебаг режиме одним кликом из classpath вашей IDE — то извитите, это не проект, а технологическая помойка. И не важно Application Server это или Docker. Если ваш джава-проект не работает без докера, то это такое же дерьмо, как и проект на JavaEE.
И слава богу! Эволюция невозможна без естественного отбора.
Я с корутинами вижу одну проблему: код, который использует явно или неявно парадигму ThreadLocal, перестанет работать правильно. С корутинами мы с одной стороны не можем больше нигде полагаться на Thread.currentThread(), а с другой у нас нет аналогичной сущности, которая бы идентифицировала текущий (асинхронный) контекст выполнения. А вот например Quasar правильно обрабатывает ThreadLocal, т.к. Fiber ведет себя аналогично треду.