Ну он не является JavaEE сам по себе. Я вас прекрасно понимаю — у меня ровно такие же впечатления от портала, просто это претензия немножко не по адресу.
Вы просто не сталкивались с тем что сервер не всегда позволяет горячий deploy классов.
Я, не сталкивался? Да будет вам ))) У меня была websphere, где один из вендорских EAR устраивал дедлок при деплое, с вероятностью почти 99%. До горячего деплоя просто дело не доходило.
А по поводу PS. я скажу вот что: у меня текущая платформа это Karaf. На котором имеется osgi enterprise. Так вот что выходит в итоге — да, в теории вы можете собрать конструктор. Но на практике это зачастую связано с таким геморроем, что только ой. Т.е. да, в чем-то это лучше, но далеко не во всем. Начиная с того, что для собирания конструктора нужен человек с приличным уровнем квалификации, а для разработки под готовый JavaEE годится уровень значительно более низкий. Проверено.
Использование WebSphere Portal было самым ужасным опытом в моей жизни.
А вот не надо путать теплое с мягким. Портал-то тут при чем? Оно кажется даже не часть JavaEE вообще (не настаиваю).
Приложение начало стартовать не за 5 секунд, а за 1.1.
Это знаете, выглядит как "граждане ученые, у нас тут подземный стук". Не, серьезно. У меня было приложение, которое стартовало 10 минут на машинах разработчиков, и это никого не волновало абсолютно, потому что все это время оно читало в кеш гигабайты данных. Зато потом быстро работало. А в текущем проекте недавно напоролись на баг Windows, где утекали сокеты… если машина работала без перезагрузки более 450 дней. Зачем вы вообще его рестартуете?
Сообщество? Нет, не может. Поглядите например на то, как сделана реализация спецификации JavaEE "для OSGI". Есть такая… На это без слез смотреть трудно.
Дело в том, что JavaEE никогда не выпускалась в таком виде, как JavaSE, это всегда была спецификация на API + референс реализация. И других реализаций всегда был если не вагон, то вагончик. Да, oracle владеет двумя из них — Weblogic и Glassfish, но не более того.
Redhat, IBM Websphere никуда не денутся. Большинство частей реализации давно уже есть в open source.
Если они окончательно проиграют суд с Гуглом по поводу возможности юридической защиты API — то ничто не будет мешать развивать спецификацию и реализации дальше.
А что вы тогда вообще сказать-то хотели? Я даже не про некоторую кривизну перевода — это бывает. Я вот про это например:
Ведь при положительном ответе, программисты смогут гораздо оптимизировать многие аспекты программы
Вы в курсе, что доказательства бывают неконструктивные, от противного, например? И даже если кто-то что-то докажет — это совершенно не будет означать в общем случае наличия способа решения проблемы. Это будет значить, что он существует — но возможно ни на шаг не приблизит к его построению.
Девушка вообще не программист. Она не понимает простой вещи — что софт развивается во времени. Что это развитие нужно отслеживать, чтобы понимать, какие именно проводки мы переключили, прежде чем оно перестало работать. Чтобы исправлять ошибки, и делать выводы.
И не понимает того, что во всех этих системах "без программирования", позволяющих таскать проводки мышкой, ничего этого делать нельзя. У этих картинок нет истории.
Более того — на эти грабли человечество уже наступало много-много раз. Она далеко не первая, и к сожалению не последняя.
Вы забыли упомянуть одну существенную вещь. Еще есть API, доступный например VBA и .Net приложениям (все это про MS Office). И если вы это используете — у вас де-факто вариантов перехода куда-либо почти нет, потому что остальные несовместимы от слова совсем.
Видите ли, в же стиле можно сфорулировать любую чушь.
Интернет — в том смысле, который ему придает сам автор цитаты, т.е. софт TCP/IP, еще как отключается. Позвольте мне не давать вам ссылки на множественные уязвимости серверов любого рода, которые позволяют их легко уронить? Да, система адаптируется, и сильно. Но тем не менее любой из нужных именно вам ресурсов в любой момент может быть недоступен. А то что мы видим — лишь результат дублирования.
Если угодно — общая конструкция интернета, как фиговины состоящей из большого числа независимых частей — она да, устойчивая. Но протоколы, которые в нее входят, и отдельные узлы — совсем нет.
Он просто состоит из множества реально независимых частей, которые сами по себе отключатся регулярно, просто они друг другу не нужны. В том числе — отключаются по вполне себе внутренним причинам.
При тестировании асинхронного кода достаточно часто есть потребность в определенном порядке потоков для определенного теста. Если не применять никакой синхронизации, получим нестабильные тесты, которые иногда отрабатывают, а иногда падают.
Мне кажется, или вы перевернули все с ног на голову? Если тесты падают при случайном порядке выполнения потоков — эначит вы тестируете что-то, что зависит от этого порядка. Поскольку в рабочей программе порядок не определен — она заведомо может работать не так. И что толку в таких тестах?
Представьте, что вы тестируете просто цикл, некий итерационный численный алгоритм, при этом ваш тест зависит от числа повторений. Мне кажется, это какой-то неправильный тест, нет?
Нужно поискать инвариант, который не зависит от порядка выполнения, и проверить, что он правилен.
Называется, угадайте с трех раз, для чего вот это нужно:
TypeToken<List> stringListTok = new TypeToken<List>() {};
Что до генерации на этапе компиляции, то можно просто погуглить проект lombok, и поглядеть на живых примерах. Это конечно не сам компилятор генерирует, а annotation processors, но в данном случае это пофиг.
Что до остального, то я сказал основной язык, а не единственный ))) Мне например вполне комфортно на лиспе, без всяких преувеличений. И на Python тоже. И на многих других.
Не, ну я же вполне конкретно спросил — почему вам не хватает TypeToken? У меня это основной язык, и я в редчайших случаях сталкиваюсь с тем, что рефлексии мне почему-то не хватило.
для динамическоо построения наследника IComparer,
Ну это да, имеете право, хороший пример. Просто я обычно такие вещи пытаюсь решить на этапе компиляции, именно там где дженерики имеются в наличии (а еще есть аннотации).
То, что библиотеки подключать просто, — это вообще ни при чём.
Да ладно ) То-то я видел тут (небольшую правда) кучку постов, о том что не надо тащить в проект лишние зависимости, потому что это трудно. В том-то и дело, что это реальная польза. У меня в текущем открытом проекте — 83 зависимости, и меня это совершенно не волнует. Не будет никакого геморроя — просто не надо тащить все в один проект, надо разбивать на сравнительно мелкие модули.
Почти для всего нужны библиотеки.
Вы не поверите — но это прекрасно! Главное что они не просто нужны — а они есть.
Что до остального — то опять же, с моей точки зрения это мелкие придирки. Да, можно List, можно массив, сейчас стало можно еще и Stream вернуть. Ну так извините, можно ведь и иначе взглянуть — можно вернуть имя файла (это String), можно Path (это уже немного другое, потому тут уже и структура папок в файловой системе, родитель, дети и.т п), а можно и просто File. И в чем же тут недостаток? Это разные вещи, для разных целей.
В результате, пользовательский код часто более, чем наполовину, состоит из циклов по перекладыванию
Ну это вы загнули… Arrays.asList(массив) — у вас этого половина? )))
Но в каком-то смысле — это правда. Потому что большая часть бизнес-кода — она реально из этого и состоит. Из базы в форму, из формы — обратно в базу.
Ну он не является JavaEE сам по себе. Я вас прекрасно понимаю — у меня ровно такие же впечатления от портала, просто это претензия немножко не по адресу.
Я, не сталкивался? Да будет вам ))) У меня была websphere, где один из вендорских EAR устраивал дедлок при деплое, с вероятностью почти 99%. До горячего деплоя просто дело не доходило.
А по поводу PS. я скажу вот что: у меня текущая платформа это Karaf. На котором имеется osgi enterprise. Так вот что выходит в итоге — да, в теории вы можете собрать конструктор. Но на практике это зачастую связано с таким геморроем, что только ой. Т.е. да, в чем-то это лучше, но далеко не во всем. Начиная с того, что для собирания конструктора нужен человек с приличным уровнем квалификации, а для разработки под готовый JavaEE годится уровень значительно более низкий. Проверено.
Ну вот это, к сожалению, не исключено...
А вот не надо путать теплое с мягким. Портал-то тут при чем? Оно кажется даже не часть JavaEE вообще (не настаиваю).
Это знаете, выглядит как "граждане ученые, у нас тут подземный стук". Не, серьезно. У меня было приложение, которое стартовало 10 минут на машинах разработчиков, и это никого не волновало абсолютно, потому что все это время оно читало в кеш гигабайты данных. Зато потом быстро работало. А в текущем проекте недавно напоролись на баг Windows, где утекали сокеты… если машина работала без перезагрузки более 450 дней. Зачем вы вообще его рестартуете?
Сообщество? Нет, не может. Поглядите например на то, как сделана реализация спецификации JavaEE "для OSGI". Есть такая… На это без слез смотреть трудно.
Это мягко говоря неправда.
Видите ли… вот у нас например Red Hat 6.x в качестве стандарта. Пока. И его поддержки не предвидится от слова вообще. Никогда.
Ха. Пусть она сначала заработает хотя бы под линуксами.
А еще… покажете мне для разнообразия что-нибудь аналогичное Apache Camel, но под .Net?
А возможно ничего и не будет.
Дело в том, что JavaEE никогда не выпускалась в таком виде, как JavaSE, это всегда была спецификация на API + референс реализация. И других реализаций всегда был если не вагон, то вагончик. Да, oracle владеет двумя из них — Weblogic и Glassfish, но не более того.
Redhat, IBM Websphere никуда не денутся. Большинство частей реализации давно уже есть в open source.
Если они окончательно проиграют суд с Гуглом по поводу возможности юридической защиты API — то ничто не будет мешать развивать спецификацию и реализации дальше.
Это у вас вышло хорошо. Спасибо.
А что вы тогда вообще сказать-то хотели? Я даже не про некоторую кривизну перевода — это бывает. Я вот про это например:
Вы в курсе, что доказательства бывают неконструктивные, от противного, например? И даже если кто-то что-то докажет — это совершенно не будет означать в общем случае наличия способа решения проблемы. Это будет значить, что он существует — но возможно ни на шаг не приблизит к его построению.
Девушка вообще не программист. Она не понимает простой вещи — что софт развивается во времени. Что это развитие нужно отслеживать, чтобы понимать, какие именно проводки мы переключили, прежде чем оно перестало работать. Чтобы исправлять ошибки, и делать выводы.
И не понимает того, что во всех этих системах "без программирования", позволяющих таскать проводки мышкой, ничего этого делать нельзя. У этих картинок нет истории.
Более того — на эти грабли человечество уже наступало много-много раз. Она далеко не первая, и к сожалению не последняя.
Вы забыли упомянуть одну существенную вещь. Еще есть API, доступный например VBA и .Net приложениям (все это про MS Office). И если вы это используете — у вас де-факто вариантов перехода куда-либо почти нет, потому что остальные несовместимы от слова совсем.
Видите ли, в же стиле можно сфорулировать любую чушь.
Интернет — в том смысле, который ему придает сам автор цитаты, т.е. софт TCP/IP, еще как отключается. Позвольте мне не давать вам ссылки на множественные уязвимости серверов любого рода, которые позволяют их легко уронить? Да, система адаптируется, и сильно. Но тем не менее любой из нужных именно вам ресурсов в любой момент может быть недоступен. А то что мы видим — лишь результат дублирования.
Если угодно — общая конструкция интернета, как фиговины состоящей из большого числа независимых частей — она да, устойчивая. Но протоколы, которые в нее входят, и отдельные узлы — совсем нет.
Интернет никогда не отключался? Да ладно!
Он просто состоит из множества реально независимых частей, которые сами по себе отключатся регулярно, просто они друг другу не нужны. В том числе — отключаются по вполне себе внутренним причинам.
Мне кажется, или вы перевернули все с ног на голову? Если тесты падают при случайном порядке выполнения потоков — эначит вы тестируете что-то, что зависит от этого порядка. Поскольку в рабочей программе порядок не определен — она заведомо может работать не так. И что толку в таких тестах?
Представьте, что вы тестируете просто цикл, некий итерационный численный алгоритм, при этом ваш тест зависит от числа повторений. Мне кажется, это какой-то неправильный тест, нет?
Нужно поискать инвариант, который не зависит от порядка выполнения, и проверить, что он правилен.
Ну вы же его (TypeToken) только что просили? :)
Называется, угадайте с трех раз, для чего вот это нужно:
TypeToken<List> stringListTok = new TypeToken<List>() {};
Что до генерации на этапе компиляции, то можно просто погуглить проект lombok, и поглядеть на живых примерах. Это конечно не сам компилятор генерирует, а annotation processors, но в данном случае это пофиг.
Что до остального, то я сказал основной язык, а не единственный ))) Мне например вполне комфортно на лиспе, без всяких преувеличений. И на Python тоже. И на многих других.
Хоть что-то? Да их навалом, этих инструментов. На любой вкус, вы о чем? На этом построены кучка ORM, и еще кучка JavaEE.
Да ладно ) То-то я видел тут (небольшую правда) кучку постов, о том что не надо тащить в проект лишние зависимости, потому что это трудно. В том-то и дело, что это реальная польза. У меня в текущем открытом проекте — 83 зависимости, и меня это совершенно не волнует. Не будет никакого геморроя — просто не надо тащить все в один проект, надо разбивать на сравнительно мелкие модули.
Что до остального — то опять же, с моей точки зрения это мелкие придирки. Да, можно List, можно массив, сейчас стало можно еще и Stream вернуть. Ну так извините, можно ведь и иначе взглянуть — можно вернуть имя файла (это String), можно Path (это уже немного другое, потому тут уже и структура папок в файловой системе, родитель, дети и.т п), а можно и просто File. И в чем же тут недостаток? Это разные вещи, для разных целей.
Но в каком-то смысле — это правда. Потому что большая часть бизнес-кода — она реально из этого и состоит. Из базы в форму, из формы — обратно в базу.
Вы книжку от Sonatype читали? В смысле, обе книжки?