Организации Apache Software Foundation представила интегрированную среду разработки Apache NetBeans 18, которая предоставляет поддержку языков программирования Java SE, Java EE, PHP, C/C++, JavaScript и Groovy. Готовые сборки сформированы для Linux (snap, flatpak), Windows и macOS...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=59237
Я думал это программа которая не нужна и никто таким уже не пользуется двано.
впервые увидел её в году эдак 2006 это было что-то странное иглючное. это рекомендовали для разработки на php. а потом оказалось что в основном этим никто не пользуется, предпочитая нотепад++
Я для джавы примерно в тех же годах пользовала нормально, правда, на винде - на убунте шрифты оказались покорёжены, переползла на вебшторм
Можно было использовать JRE рантайм от JetBrains из поставки InteliJ IDEA, я запускал NetBeans и тогда шрифты были красивые. Но теперь не актуально, теперь в стандартных JRE можно выбирать какой версией FreeType будут сглаживаться шрифты, и меня устраивает `FREETYPE_PROPERTIES='truetype:interpreter-version=40'`.
Лично я NetBeans не пользуюсь, использую этот параметр для других приложений рисующих интерфейс на Java Swing. Если кого не устраивает шрифты в Java прилоежниях то попробуйте.
Да, хеловорды в нотепаде делать удобно.
Была в свое время лучшей IDE для Java. Eclipse просто разваливался на куски при малейшем дуновении на него (как и сейчас), а Idea умела только Java SE (как и сейчас).
С++ поддержку допилить нормально не могут; зато раст затащили.
Вообще у Netbeans был слоган «One IDE for all».
По факту это «делаем всё, но всё плохо».
Разве что базовая Java нормальная собственно.
На базе платформы NetBeans сделали Oracle SQL Developer. По функционалу вроде бы ничего так, но по исполнению, по тормознутости - авно, DBeaver - намного приятнее и быстрее. Сейчас Oracle SQL Developer под Web (и electron) все это переписывают - дожили, фирма развивающая Java, соскакивает с Java.А начинался NetBeans в общем-то нормально, был резвее Eclipse. Но потом его купила Oracle - могильщик продуктов.
так java для рисования UI плоха, только в Android доработали нормально, а в electron аппаратное ускорение на видео карте из коробки, зато для других задач java хороша и фремворки типа Spring имеют много готовых решений
DBeaver тоже на Java - плагин для Eclipse. Но у него приятные шрифты, он не тормозит, автообновление, работать приятно. Просто, наверное, дело в прямых руках разработчиков. У Этого Джефа Смита и его команды, возможно они росли не оттуда. Ну и Oracle - у нее много было продуктов на Java и почти все уже закончили свой век или не развиваются: JDeveloper, ADF, Oracle Data Integrator, Oracle BI EE, Oracle BPM, Oracle SOA Suite, Oracle WebLogic и т.д.
неужели есть хотя бы 1 спектр задач для которых java нормальный выбор? По-моему таких задач давно не существует
> неужели есть хотя бы 1 спектр задач для которых java нормальный выбор?Java Micro Edition.
> По-моему таких задач давно не существуетSweet Home 3D.
> слоган «One IDE for all»Перевод - Одно ххх для всех.
Начиная с 17 версии NetBeans поддерживает старые версии плагинов, в том числе и C++
> серверов LSPкак это связано с Джавой ?
у них же уже есть свой, правславный отладчик,
а в сторону LSP и конь не валялся
главное вовремя оседлать rust
Учитывая, что поддерживается два десятка языков, включая не самые популярные, удивительно что так поздно.
> главное вовремя оседлать rustТвой раст устарел. С разморозкой.
> поддержку языков программирования Java SE, Java EEВопрос знатокам: чем отличаются языки программирования Java SE и Java EE?
Вопрос со звёздочкой: что написано по этому поводу на сайте Нетбинс?
Java SE это подмножество языка Java предназначенное для написания приложений для рабочего стола.Java EE переводится как Enterprise Edition. И предназначено для написания корпоративных приложений, которые будут крутится на серверах.
Спасибо, вы нам не подходите.
Почему люки круглые?
Из изопериметрической задачи Дидоны следует, что из всех фигур с равным периметром (и массой) круг будет иметь наибольшую площадь.
Упаси меня боже работать на такого работодателя. Вы там в коком-то бреду обитаете.
Вообще, в программировании всё просто и элементарно. Подтверждение этому язык C, на котором написаны и Windows и Linux. Но я встречал таких же как вы работодателей, которые воротили нос от C, ругаясь на длинные функции и называя их портянками.
А вот такие как вы работодатели погрязли в своём собственном мирке и бредят всякими новомодными финтифлюшками, упуская из виду простой кодинг.
> Java SE это подмножество языка Java предназначенное для написания приложений для рабочего столаНе зачёт. На Java SE ой как пишутся "корпоративные приложения" уже 8 лет как (Spring Boot например), а то и больше.
А EE считайте, утонула, и сейчас её лучшее подмножество реализуют в Quarkus.
>На Java SE ой как пишутся "корпоративные приложения" уже 8 лет как (Spring Boot например)- и что, Вы у себя в Спринге не используете классы из пакетов javax.persistence, javax.annotation, javax.servlet, javax.xml.bind и т д? (полный список спецификаций JavaEE найдете по адресу: https://jakarta.ee/specifications/ )
>EE считайте, утонула
- значит вещь годная, а вот к тому что не тонет стоит относиться осторожно. Мнение большинства всегда ошибочно, ибо большинство людей идиоты © Э.А.По
>EE считайте, утонула
>значит вещь годная
>© Э.А.ПоСлишком толсто - аргументировать спор в софтверной разработке цитатами писателя.
Под утонула - я имею ввиду что EE - спека, её реализации - это Application Server'а, так вот, от разработки с их помощью отказались/отказываются. Не только в российских банках(посмотрите на hh.ru вакансии с Spring Boot), но и сам Red Hat, свой продукт Keycloak уже перевели с WildFly на Quarkus.
Я к тому, что на EE + Application Server обычно разработку в 2023 не начинают. Да и вакансии таке обходят стороной (спросите любого рекрутера, насколько "легко и непринуждённо" им ищется кандидаты на Java EE).
На всякий случай скажу, что я вам не запрещаю их использовать, не пытаюсь переубедить, пишите на чём хотите. Я просто делюсь своим мнением, чтобы случайно зашедший сюда чел, желающий стать Java разрабом не сделал не правильных выводов, что типа "Спринг уже всё". Вот не всё, популярен, не смотрите на комменты, смотрите на вакансии (hh.ru, Хабр Карьера, ...)
>EE - спека- выше я отметил что часть этой спецификации используется в Spring, так что если тонуть, то тонуть вместе)) И похоже кто то плохо её знает))
>её реализации - это Application Server'а ... от разработки с их помощью отказались/отказываются
- а также контейнер сервлетов (Jakarta EE WebProfile спецификации). Если мне не изменяет память, SpringBoot для web-приложений по умолчанию тянет Tomcat как зависимость. Так что без больших натяжек можно сказать что SpringBoot тащит сертифицированный JavaEE Web Profile контейнер. Так то кто там от чего отказывается прозвучало не особо убедительно
>Слишком толсто - аргументировать спор в софтверной разработке цитатами писателя ... спросите любого рекрутера
- а вот это тонко))
>Я просто делюсь своим мнением, чтобы случайно зашедший сюда чел
- просто навязываете свое мнение (не факт что экспертное) и топите за любимый фреймворк, который оброс жиром не хуже чем JavaEE 20-летней давности, но при этом сохранил молодежно-экспериментальный подход к развитию
>смотрите на вакансии
- тогда учите Go, Rust или JavaScript))
> часть этой спецификации используется в Spring, так что если тонуть, то тонуть вместеСугубо опционально. Никто не застнавляет писать Spring Boot приложения с javax.persistence и javax.xml
> можно сказать что SpringBoot тащит сертифицированный JavaEE Web Profile контейнер
Нет, нельзя. Задеплоите ".war" в Spring Boot, который "JavaEE Web Profile контейнер" ?)
> Так то кто там от чего отказывается прозвучало не особо убедительно
у меня нет целей вас убедить
> просто навязываете свое мнение
ну что вы ?) я просто делюсь опытом для
> чтобы случайно зашедший сюда чел, только я пользуюсь спринг бутом (про вас не знаю)
Вот на вашем примере видно, как Java EE спека - это очень хороший маркетинговый запудриватель мозгов, видно как люди не писавшие на охотно верят в силу этой спеки, в переносимость приложений между разными реализациями и транслируют всем остальным. Это хорошо подействовало на ЛПР (лица принимающие решения, читай менеджеров) в ретроспективе, чем обеспечило ёе начальное распространение, затем хейт, затем Спринг Бут как результат. Ну а затем и клоны Спринг Бута подтянулись. Эт оесли вкратце.
>Задеплоите ".war" в Spring Boot, который "JavaEE Web Profile контейнер" ?)- легко, лично я такое делал (исключить ненужные зависимости, в том числе Tomcat, не проблема)
>только я пользуюсь спринг бутом (про вас не знаю)
- в этом и проблема нашей дискуссии: я пользуюсь и JavaEE в разных спецификациях (web - не web) и Spring, и SpringBoot, поэтому могу сравнивать (про Вас не знаю)
>Java EE спека - это очень хороший маркетинговый запудриватель мозгов
- а что Вы думаете о правилах дорожного движения? Они же реально ограничивают возможности молодежи на самокатах и придуманы рептилоидами чтобы трясти бабло с людей!
>видно как люди не писавшие на охотно верят в силу этой спеки
- это Вы мне адресовали? Конечно в силах программиста сделать любое приложение непереносимым, однако спецификации из JavaEE работают и позволяют создавать переносимый (либо требующий минимального изменения в области конфигурационных файлов) код
>затем хейт, затем Спринг Бут как результат
- простите, но я начинал с EJB 2 и еще помню историю развития Spring. Не так всё было. Да и в современности гордиться Спрингу особо нечем - те десятки мегабайт фреймворков которые лежат спокойно в JavaEE контейнере, спринговое приложение тащит при сборке, распухая до тех же десятков мегабайт (под сотню в реальности) плюс бесконечная чехарда с версиями этих зависимостей
>Никто не застнавляет писать Spring Boot приложения с javax.persistence и javax.xml
- приложение без REST/WS и СУБД? Это какой то альтернативный энтерпрайз, хотя конечно сейчас всё больше приложений на Kafka и NoSQL, но как то с внешним миром они должны общаться?
>Задеплоите ".war" в Spring Boot
>легкоЛибо вы троллите, либо у нас разные поняния о "легко". Это не легко. По памяти, без гугла не напишите.
>Java EE спека - это очень хороший маркетинговый запудриватель мозгов
> - а что Вы думаете о правилах дорожного движения? Они же реально ограничивают возможности молодежи на самокатах и придуманы рептилоидами чтобы трясти бабло с людей!Мне нравится ваша аргументация, продолжайте =)
>видно как люди не писавшие на охотно верят в силу этой спеки
>- это Вы мне адресовали?Да
> гордиться Спрингу особо нечем - те десятки мегабайт фреймворков которые лежат спокойно в JavaEE контейнере
Небось и .jar библиотек ручками в контейнер подкладываете ?)
На этом, пожалуй, я и закончу, как писал выше, нет цели вас (пере)убедить или свалиться в срач. Пишите на здоровье на чём хотите. Не любите Spring Boot.
По мне - Spring Boot - хороший современный фреймворк для быстрой разработки современных корпоративных приложений, излеченный от проблем экосистемы Java EE, читай Applicaton Server'ов таких как WildFly, Glassfish, ...
>Spring Boot - хороший современный фреймворк для быстрой разработки современных корпоративных приложений- будем честными в определениях: что такое "современное" и "не современное" корпоративное приложение? Надо ли понимать префикс "современное" - как написанное теми кто знает мэйнстримный на сегодня фреймворк и не сильно беспокоится о дальнейшей поддержке написанного приложения? Почему спецификация Jakarta EE 10, которой еще и года нет, "не современная", а её использование как то замедляет разработку приложения?
>излеченный от проблем экосистемы Java EE, читай Applicaton Server'ов таких как WildFly, Glassfish, ...
- перенос сложности это не излечение. Я уже отметил выше что всё то дерьмо которое в JavaEE пихают контейнер, в Spring тащат в само приложение, причем как в примере с Tomcat который мы можем удалить из автоматически подтягиваемых зависимостей, мы очевидно получаем ненужные нам библиотеки, которые иногда конфликтуют. В общем "магия" которая раньше была заложена в сервер приложений, теперь сидит в SpringBoot. Бинго! Мы пришли к тому от чего хотели уйти. И наоборот, Jakarta EE похудела и появился MicroProfile.
>либо у нас разные поняния о "легко". Это не легко
- либо мы по разному понимаем формулировку "Задеплоите ".war" в Spring Boot" ))
> Надо ли понимать префикс "современное" - как написанное теми кто знает мэйнстримный на сегодня фреймворк и не сильно беспокоится о дальнейшей поддержке написанного приложенияВы либо путаете, либо не замечаете. Spring Boot - это стандарт де факто для написания конпоративных приложений, это не я придумал, это гуглится :)
> перенос сложности это не излечение
Тут я с вами соглашусь. Но опять же, вы снова преувеличиваете.
> Я уже отметил выше что всё то дерьмо которое в JavaEE пихают контейнер, в Spring тащат в само приложение, причем как в примере с Tomcat который мы можем удалить из автоматически подтягиваемых зависимостей, мы очевидно получаем ненужные нам библиотеки, которые иногда конфликтуют.
Gопробуйте Go. В нём культ минимализма, плюс лучшая многопоточка чем в Java(про то что в 21 заезжают виртуальные потоки и может быть preview structured concurrency я в курсе) плюс лучшая чем GraalVM Native Image создание бинарников под платфому.
> Spring Boot - это стандарт де факто- нет, это Вы путаете: "стандарт" должен быть где то описан и JavaEE это как раз "стандарт", а именно достаточно четкая спецификация которую обсуждают и документируют сотни специалистов прежде чем она будет опубликована. А SB это код написанный десятком программистов, который работает так как он работает и это не всегда описано, и который может быть изменен если у разработчиков SB в носу зачешется.
>это не я придумал, это гуглится :)
- это нас возвращает к Эдгару По и миллионам лемингов которые не могут ошибаться. SB появился только в 2014 году, Вы уверенны что все корпоративные приложения написанные до 2014 года переписали на SB? Или что каждое новое приложение с 2014 года пишется на SB? Возможно Вы перепутали Spring и SpringBoot - это не одно и то же, Spring был и бывает без SB, а SB - нет.
>культ минимализма ... создание бинарников под платфому
- не считаю минимализм решающим критерием (это как спорить о преимуществах ассемблера, они есть ... но), а бинарник так и вовсе, по моему, зло в "современном" (алаверды) мире. Однако тут все лично и зависит от решаемых задач, поэтому не вижу смысла об этом дискутировать
> "стандарт" должен быть где то описан и JavaEE это как раз "стандарт", а именно достаточно четкая спецификация которую обсуждают и документируют сотни специалистов прежде чем она будет опубликованаКоторая на деле оказывается совокупностью серых зон с кучей неопределённостей.
А также, порой, бывает очень не просто настроить какую-то низкоуровневую деталь, потому что "сотням специалистов" не хватило ума/времени/возможностей о ней подумать, а разрабы конкретной реализации (читай того же WildFly), не завидя в стандарте чёткого определения - просто забили.
И сидишь, выковыриваешь её рефлексией либо же кастуешь к реализации (что собственно убивает переносимость между реализациями).Вы, правда, переоцениеваете так называемый "стандарт". Как и писал выше -
> Java EE спека - это очень хороший маркетинговый запудриватель мозговJava EE для теоретиков-идеалистов ну и для небольших ненагруженных внутри-корпоративых приложений, где не требуется тонкая настройка.
Хоть один хай-лоад проект на Java EE существует хоть ?)
>Java EE для теоретиков-идеалистов ну и для небольших ненагруженных внутри-корпоративых приложений- я уже писал Выше что JavaEE это набор спецификаций (Вы почему то игнорируете этот тезис), в том числе: JPA, Servlet, JAX-RS/WS, JAXB. Редкое корпоративное приложение обходится без использования этих спецификаций и их имплементаций. И Spring в этом смысле не альтернатива, он тоже реализует часть спецификаций из стека JavaEE
>Хоть один хай-лоад проект на Java EE существует хоть ?)
- мы вроде говорили про корпоративные приложения. Приложения масштаба "Москва", "РФ" есть - практически всё ПО которое в министерствах работает - это Java. Приложения эти бывают вполне себе нагружены. Какой нибудь ЕМИАС - сотни сервисов у которых под капотом JPA, JAX-RS/WS и т д (см выше)
>требуется тонкая настройка
- там где "требуется тонкая настройка" есть проблемы в архитектуре приложения
> - там где "требуется тонкая настройка" есть проблемы в архитектуре приложениясудя по вашим тезисам, вы либо не имели дела с высокими нагрузками, либо троллите :)
тонка настройка требуется, когда тюнишь приложение под нагрузку.>>Хоть один хай-лоад проект на Java EE существует хоть ?)
>- мы вроде говорили про корпоративные приложения. Приложения масштаба "Москва", "РФ" есть - практически всё ПО которое в министерствах работает - это Java. Приложения эти бывают вполне себе нагружены. Какой нибудь ЕМИАС - сотни сервисов у которых под капотом JPA, JAX-RS/WS и т д (см выше)Вот, кажется я теперь и понимаю, почему они так "тормозят". Приходишь такой к врачу, у него тупит комп, который не может прогрузить элеткронную мед карту :)
> я уже писал Выше что JavaEE это набор спецификаций (Вы почему то игнорируете этот тезис), в том числе: JPA, Servlet, JAX-RS/WS, JAXB. Редкое корпоративное приложение обходится без использования этих спецификаций и их имплементаций. И Spring в этом смысле не альтернатива, он тоже реализует часть спецификаций из стека JavaEE
Возможно и вправду мы друг друга не поняли. Я знаю что часть этих спек используется в экосистеме Спринг. Я о классических реализациях Java EE, которые Application Server. Которые ущербны по своей природе и обладают недостатками что я перечислил.
>либо троллите ... тонка настройка требуется, когда тюнишь приложение под нагрузку- мне кажется я довольно четко сформулировал: там где требуется тонкая настройка, есть проблема в архитектуре. Могу пояснить: у каждого приложения есть физический предел производительности (объем памяти, мощность ЦПУ, производительность системы ввода-вывода и т д), это означает что тюнингом JVM, резмеров фетчей из базы, размерами буферов, количеством потоков и т п Вы можете лишь приблизиться к этому пределу, но он всё равно наступит. Поэтому решение проблемы нагрузки лежит не в области тюнинга (который тоже нужен - 10% к производительности помноженные на количество узлов дают миллионную экономию), а в области архитектуры, которая должна учитывать необходимость масштабирования, распределенного кэширования etc. В нагруженных корпоративных приложениях проблемы с нагрузкой решаются тривиальным добавлением нод (архитектура должна предусматривать такую возможность)
>Приходишь такой к врачу, у него тупит комп, который не может прогрузить элеткронную мед карту
- наверное Вы работаете только с идеальными приложениями которые работают в идеальном мире? Сотни сервисов работающих совместно и созданные в разных компаниях - это тысячи программистов которые их писали (иногда с ошибками), девопсов (которые иногда ошибаются), внешние сервисы (которые иногда недоступны), сетевые админы (которые иногда ошибаются или меняют структуру сети). Но конечно каждый из нас знает что сделал бы всё гораздо лучше))
>ущербны по своей природе
- выше я перечислил особенность "природы" Spring: отсутствие спецификаций и разработка "на живую" - код это есть спецификация в Spring. Такая "природа" рождает и очевидную, и предсказуемую проблему - проблемы совместимости версий и проблемы с миграцией приложений нуждающихся в долговременной поддержке (к которым как правило и относятся корпоративные приложения). Вы же мне (как я понял) оппонируете тем что набор спецификаций JavaEE имеет некую "природу" которая мешает производительности и снижает скорость разработки. Но каких то механизмов, как это происходит, не приводите. Поэтому мне сложно с Вами согласиться, так как ни неразрешимых проблем с производительностью, ни проблем со скоростью разработки (наоборот - включение новых сотрудников в проект проходит легко, а наличие спецификаций стимулирует писать чистый и прозрачный код) лично я, при использовании спецификаций JavaEE, не наблюдал.
>>Приходишь такой к врачу, у него тупит комп, который не может прогрузить элеткронную мед карту
>наверное Вы работаете только с идеальными приложениями которые работают в идеальном мире?Наверное, вы не ходите к врачу. Когда я прихожу к врачу, - я (и врач) в роли пользователя, ему и мне начхать на архитектуру, на технологии, нам нужно очень простое - чтобы приложение работало и быстро. Вот с таким подходом, с использованием "проверенный сотней специалистов" спецификаций, помноженных на госзаказ и раздолбайность и получаются такие ЕМИАСы, которые "не идеальны", а если по-русски - то тормозят.
>выше я перечислил особенность "природы" Spring: отсутствие спецификаций и разработка "на живую" - код это есть спецификация в Spring. Такая "природа" рождает и очевидную, и предсказуемую проблему
Писал ниже (или выше), что это не такая большая проблема, если в организации есть процессы. Если процессов нет, или разработка организована как-попало, проблемы будут, и не только с версиями.
>Вы же мне (как я понял) оппонируете тем что набор спецификаций JavaEE имеет некую "природу" которая мешает производительности и снижает скорость разработки.
> мне сложно с Вами согласиться, так как ни неразрешимых проблем с производительностью, ни проблем со скоростью разработки (наоборот - включение новых сотрудников в проект проходит легко, а наличие спецификаций стимулирует писать чистый и прозрачный код)Окей, конечно нет не разрешимих проблем. Вот только ценой исправления будет - смотрим - https://www.opennet.dev/openforum/vsluhforumID3/130661.html#98 - привязывание к реализации, что противоречит самой идее JavaEE.
>лично я, при использовании спецификаций JavaEE, не наблюдал.
А вы пробовали спросить у ваших коллег(будем считать что они есть), их отношение к Java EE ? Судя по дискуссии с вами - вы склонны не замечать неприятные вам доводы, и до последнего цепляться за устаревшую, растерявшую популярность технологию. Это работает до поры до времени, но так не может продолжаться вечно. Тут или коллеги разбегутся, или вас попросят :) Как повезёт.
>Когда я прихожу к врачу, - я (и врач) в роли пользователя, ему и мне начхать на архитектуру, на технологии- это не такая большая проблема, если в организации есть процессы. Если процессов нет, ... проблемы будут. Вот и смотрите: процессы есть, Spring обновился, а Вы сидите у врача и чихаете не по делу ожидая пока последний баг вылезет или ругая власти что врачам денег не платят, все бабки на тестировщиков уходят
>нет не разрешимих проблем ... привязывание к реализации
- смотрим про архитектуру: https://www.opennet.dev/openforum/vsluhforumID3/130661.html#105
>вы пробовали спросить у ваших коллег(будем считать что они есть), их отношение к Java EE ?
- они работают молча
>Судя по дискуссии с вами - вы склонны не замечать неприятные вам доводы
- так получилось что стаж разработки у меня 26 лет (из них на Java больше 20), работал в разных компаниях, видел разные бизнес процессы и разные продукты (внедренные в различных министерствах), поэтому у меня была возможность пользоваться разными фреймворками, наблюдать за их развитием и оценивать проблемы связанные с их использованием. Выводы я изложил ранее, а Вашего аргументированного мнения относительно того как контейнер приложений по своей "природе" тормозит плохих танцоров, так и не увидел. И уверен что не увижу, потому что нельзя рационально обосновать почему либы в контейнере, включающем Tomcat, работают хуже чем те же либы собранные мавеном вместе с тем же Tomcat в стэналон приложение
> сидите у врача и чихаете не по делу ожидая пока последний баг вылезетНе улавливаете сути ;)
> ругая власти
Полно вам выдумывать, я не ругаю власти. Они по сути такие же люди как и мы.
>>вы пробовали спросить у ваших коллег
>они работают молчаУ вас что там, диктатура что-ли ? В любой нормальной софтверной/ИТ компаний нормально когда есть несколько мнений. Выходит, вы запрещаете своим сотрудникам высказывать недовольство Java EE ? Интеллектом их давите ?) Нанимаее только джунов/людей не смогущих с вами спорить ?)
> я изложил ранее, а Вашего аргументированного мнения относительно того как контейнер приложений по своей "природе" тормозит плохих танцоров
раз https://www.opennet.dev/openforum/vsluhforumID3/130661.html#98
два https://www.opennet.dev/openforum/vsluhforumID3/130661.html#102
три https://www.opennet.dev/openforum/vsluhforumID3/130661.html#100
Как я и писал ранее, не имею цели вас в чём-то убедить. Продолжайте на здоровье вашу разработку на Java EE, продолжайте игнор моих доводов и реальности, вместе с "26 годами опыта" и "работающими молча сотрудниками". До Нетфликса с таким подходом - как на раках до Китая, максимум - глючиный ЕМИАС ну и прочая госуха, которая,в отличие от Нетфликса не приносит прибыль => нет требований к перформансу, стабильности, ...
Я тоже знаю ребят, которым потом сдают "это" в саппорт и они это постепенно выправляют, переписывая на что угодно, кроме Java EE (мне известны именно переписывания на Spring Boot и Golang).
>Продолжайте на здоровье вашу разработку на Java EE- последние 10 лет я пишу на Spring с использованием спецификаций (см. выше) Java EE, а теперь Jakarta EE (о переползании на которую и поделился выше своим скромным опытом)
>До Нетфликса с таким подходом
- Нетфликс уже сделан, второй зачем?
>глючиный ЕМИАС
- есть только в Москве, так что не парьтесь - привел только в качестве примера реальной разработки на Java сложных систем большого масштаба
>госуха, которая,в отличие от Нетфликса не приносит прибыль
- не хочу вскрывать покровы, но просто подумайте на чем сделали деньги компании типа EPAM, Luxsoft, Техносерв, Ланит, Ай-Теко и прочие интеграторы с оборотами в десятки миллиардов рублей
>переписывая на что угодно, кроме Java EE ... на Spring Boot
- похоже диалог наш был пустым, доказать Вам что Spring это имплементация части стека JavaEE мне не удалось. Но люди которые пишут на Spring и уверены что отказались от JavaEE вызывают опасение за качество кода
> на чем сделали деньги компании типа EPAM, Luxsoft, Техносерв, Ланит, Ай-Теко и прочие интеграторы с оборотами в десятки миллиардов рублейУвы, их задача как правило - сделал и сдал, на той фигне что попросили "архитекторы" заказчика. Ну или не сдал, продолжаешь страдать с саппортом той фигни что написал :)
> доказать Вам что Spring это имплементация части стека JavaEE мне не удалось.
Я с этим утверджением и не спорил. Смотрим - https://www.opennet.dev/openforum/vsluhforumID3/130661.html#102
> Но люди которые пишут на Spring и уверены что отказались от JavaEE вызывают опасение за качество кода
Ваше право сомневаться, как и моё https://www.opennet.dev/openforum/vsluhforumID3/130661.html#110 %)
> Вот на вашем примере видно, как Java EE спека - это очень
> хороший маркетинговый запудриватель мозгов, видно как люди не писавшие на охотно
> верят в силу этой спеки, в переносимость приложений между разными реализациями
> и транслируют всем остальным. Это хорошо подействовало на ЛПР (лица принимающие
> решения, читай менеджеров) в ретроспективе, чем обеспечило ёе начальное распространение,
> затем хейт, затем Спринг Бут как результат. Ну а затем и
> клоны Спринг Бута подтянулись. Эт оесли вкратце.Да что вы говорите? JSR для Java — это как RFC для Интернета — кто на него наплюёт, тот рано или поздно сгинет.
JSR — это своеобразная"икона стиля", "дух времени" современной ему Java. А вы со своим Spring'ом просто оплёвываете её (вместе с комитетом, работающим над спецификациями).
Слишком толсто, попробуйте потоньше.
> Слишком толсто, попробуйте потоньше.Хорошо. Попроще: "Не плюй в колодец, из которого черпаешь воду для пития".
там выше обсуждали поход к врачу, можно записаться через ЕМИАС
> - тогда учите Go, Rust или JavaScript))я пишу на Go, я же Golangdev =)
на JavaScript тоже пишу> JavaScript
ниже в комментах предлагают TypeScript, что о нём думаете ?)
> Rust
каюсь, не выучил, обленился
>в комментах предлагают TypeScript, что о нём думаете ?)- ничего хорошего, но от холивара на эту тему воздержусь)
Язык программирования один и тот же Java описанный в спецификации JLS.
Java SE - это стандартная платформа языка программирования Java.Java EE - это спецификация и фреймворк(и) для написания корпоративных приложений. Java EE поддерживают сервера приложений Glassfish, Jakarta EE (эталонная реализация), Wildfly, JBoss, TomEE, Geronimo, WebSphere и др.
Spring не следует спецификациям Java EE, поэтому считается нестандартным решением для создания распределённых корпоративных приложений на Java. Тем не менее, на Spring обкатались многие новаторские решения, которые со временем попали в Java EE.
JavaEE в чистом исполнении - некромантия из начала двухтысячных, вы где, кроме легаси возрастом лет в 15 последний раз application server видели. Джава в ынтерпрайзе - это практически всегда спринг. Правда JavaEE пытаются оставить на плаву в эпоху микросервисов через развитие "облегчённой" версии MicroProfile (всякие Quarkus, Helidon), но гуано это ещё то.
> Джава в ынтерпрайзеЭто и есть 15+ летние проекты. Уже лет 10 как никто не пишет стартапы на джаве
> Спринг
Давно протух
> Уже лет 10 как никто не пишет стартапы на джавеТыж знаешь что стартап это проект который в находится поисках метода монитизации?
Java EE со временем второй Java очень сильно развилась на идеях Spring, избавилась от легаси. А Spring в итоге деградировал настолько, что им невозможно стало нормально пользоваться.Java продолжает эволюционировать и избавляться от устаревшего и ненужного.
> Spring в итоге деградировалпруфы "деградации" будут ?
если нет пруфа - то автор бессовестно лжёт, видимо, пишет о том, чем сам не пользуется, строит выводы на кликбейтных статьях.
>пруфы "деградации"- Вы уже перешли со SpringBoot 2 на SpringBoot 3? Боль не испытали? Как там batch не поломался? И еще по мелочи. Это действительно не признак деградации, а признак вечного эксперимента, что для энтерпрайза не очень подходит. А деградацией леминги наверное называют то что раньше казалось легче и проще чем в JavaEE, теперь стало таким же или более сложным - слишком много стало функционала, голова типичного джуна от этого болит
> batchБатч изначально плохо написан, стараюсь его не использовать, максимально жёстко, не кастомизируемо.
По мне это одна из тех вещей, которые плохо сделаны в Spring (Наряду с Spring Cloud, Spring Statemachine).
Не всё хорошо то, что Spring.
> признак вечного эксперимента
Признак эволюции =) разве вы хотите "приклеиться" навсегда к одной апишке, спроектированной 15 лет назад ? Думаю "нет". Если всё же да - обновляейте только патч-версию, не обновляйте минор и мажор.
>Признак эволюции- Вы же понимаете что "легаси" и "эволюция" это антонимы. Мы вроде про корпорастический энтерпрайз говорим и в нем переход на новую версию Java не должен сопровождаться революцией API которая ведет к переписыванию кода, тестированию функционала и прочим радостям ценой в сотни человекочасов
>обновляейте только патч-версию, не обновляйте минор и мажор
- это не всегда возможно. Например поменялось (обновилось) внешнее ПО, чтобы заюзать его нужны актуальные библиотеки с ним работающие, чтобы эти библиотеки заработали надо свежую Java и связанные фреймворки, вот и назрело обновление мажор версии, а с ним и переписывание кода который никто трогать первоначально не собирался (SpringBatch привел как яркий пример проблем на которые никто изначально не подписывался)
>Батч изначально плохо написан
- ну вот его и переписали, эволюция млин, энджой. Дело не в том плох он или хорош, а в том что при использовании Spring в корпоративных продуктах с длительной поддержкой такие проблемы ожидаемы именно потому что такое понятие как "спецификация" этот "молодежный" фреймворк принципиально не приемлет
> ценой в сотни человекочасов
> такие проблемыВы преувеличиваете серьёзность проблем. Как правило, по оптыту, в сравнении с другими "корпорастический" задачами обновление спринг бута как правило одна из самых простых.
Другими словами, если в корпорации нет процессов деливери хотя бы минимально
Аналитика(сбор требований, постановка задач), разработка, код ревью, тестирование, деплой в продто никакие спеки, никакие технологии не помогут.
С другой стороны, если эти этапы в сумме даю сотни человекочасов, это тоже плохо, так быть не должно.
Нужны нормальные менеджеры/лиды в общем.
Нет менеджера - нет процесса.
>Вы преувеличиваете серьёзность проблем- нет. Вроде я даже с примерами всё расписал: SB2 -> SB3 -> Batch (новые таблицы в БД - это документирование и миграционные скрипты, плюс работа DevOps по обновлению стендов, плюс тестирование * на количество задач которые используют Batch). Сотни человекочасов (если считать людьми не только программистов) на пустом месте. А еще неявные проблемы - SB3 -> Hibernate -> те критериа которые раньше работали стали работать иначе, хорошо если есть автотесты и такие проблемы своевременно отловились, иначе либо полное тестирование функционала, либо приветы с прода и баги, баги, баги которые потом еще пол года ловить. Конечно всё зависит от размера приложения (размера в смысле сколько всяких фич задействовано - для "Hello, World!" обновление версии SB это очень легкая задача)
>Вы преувеличиваете серьёзность проблем- нет. Вроде я даже с примерами всё расписал: SB2 -> SB3 -> Batch
я писал выше:
> Не всё хорошо то, что Spring
> А еще неявные проблемы - SB3 -> Hibernate -> те критериа которые раньше работали стали работать иначеHibernate - не лучшая часть Java. Есть более легковесные решения, например jOOQ, Spring Data JDBC, MyBatis. Сам лично использую Spring Data JDBC всегда когда можно.
С другой стороны, вы можете покрывать интеграционными тестами с Testcontainers, они запускают реальную базу, реальный RabbitMQ, ActiveMQ если хотите.
Я к тому - что это нужно делать загодя - покрывать тестами, тогда и обновления МАЖОРНОЙ версии не будут так болезненны.Не используйте Spring Batch, Spring Cloud, Spring Statemachine, Hibernate
> Есть более легковесные решения, например jOOQ, Spring Data JDBC, MyBatis- чем jOOQ лучше Apache Cayenne? jOOQ (словами из "Люди в черном") это новая крутотень, а Cayenne это старая хренотень? Не вижу разницы и оба фреймворка лично мне не нравятся (парадигма не нравится)
- MyBatis, не туда ни сюда, и запросы писать не особо удобно, и маппинг неудобный, и ясной спецификации (как в JPA где есть куча документации) нет, и самопальные кэши вызывающие сильные сомнения (не хочу тут углубляться в детали)
-Spring Data JDBC, Вы серьезно? Это фактически рукоблудие, а значит потеря скорости разработки (за которую Вы раньше радели), сложности в реализации кэширования, маппинга, валидации запросов. Короче отказаться от всех плюшек JPA или Spring Data JPA - это круто, видимо какие то большие сложности возникли. Если нужен native SQL, то JPA это разрешает, да и в Hibernate есть всё необходимое
>Hibernate - не лучшая часть Java.- однако это такой же меэйнстрим как и Spring, и топить за Спринг как за "современный", но отказываться от Хибера, это какая то противоречивая позиция
>Я к тому - что это нужно делать загодя - покрывать тестами, тогда и обновления МАЖОРНОЙ версии не будут так болезненны
- тесты позволят найти часть (100% покрытие тестами и их адекватность это иллюзия) косяков своевременно, но исправлять их всё равно придется (причем проблемы могут быть нетривиальными)
>Не используйте Spring Batch, Spring Cloud, Spring Statemachine, Hibernate
- вот и поговорили) Ранее Вы мне еще не рекомендовали JavaEE) Что осталось? Рукоблудие вместо фреймворков и контейнеров?
> -Spring Data JDBC, Вы серьезно? Это фактически рукоблудиеВы наизусть помните как прописывать маппинги OneToMany ? Посмотрите выступления Jens Shauder, например https://www.youtube.com/watch?v=GOSW911Ox6s https://www.youtube.com/watch?v=DD7U4i51xLI он объясняет мотивацию создания Spring Data JDBC.
Я вас не заставляю на него переходить, не хотите - не нужно, поддерживайте вокруг себя постепенно устаревающую и уходящую в историю вашу зону комфорта, с Java EE и Hibernate, как я понимаю.Вас не смущает, что НИГДЕ, ни в одном популярном сегодня языке кроме Java нет такого монстра как Hibernate, с 3мя (sic!) уровнями кэшей, Lazy loading и OneToMany ?
Эволюция свернула не туда, когда придумывали Hibernate.
> - однако это такой же меэйнстрим как и Spring, и топить за Спринг как за "современный", но отказываться от Хибера, это какая то противоречивая позиция
Просто беру самое лучшее, стараюсь не мыслить однобоко.
> Ранее Вы мне еще не рекомендовали
Не вам. Начишающим разработчикам. Я писал, что я не против вашего выбора, пишите на чём хотите.
> Рукоблудие
Не зацикливайтесь на этом слове, это не улучшает вашу аргументацию.
>Вас не смущает, что НИГДЕ, ни в одном популярном сегодня языке кроме Java нет такого монстра как Hibernate, с 3мя (sic!) уровнями кэшей, Lazy loading и OneToMany ?- нет, это только подчеркивает что Java/JavaEE это язык и спецификация корпоративного уровня. В задачах решаемых на Java часто нужно работать с большими объемами связанных данных, поэтому в JPA описаны требования по кэшированию и его поведение
>Вы наизусть помните как прописывать маппинги OneToMany ?
- да, даже других учил (но это личное), а если чего подзабыл весь Гугл (который не может ошибаться) заполнен туториалами и примерами на эту тему. Но в первую очередь - есть спецификация где всё описано.
>беру самое лучшее
- самое лучшее для конкретных задач и предметной области. В этом смысле JavaEE - плод многолетней шлифовки API под типичные задачи корпоративного сектора
>Не зацикливайтесь на этом слове, это не улучшает вашу аргументацию
- зато хорошо выражает мое отношение к этому процессу
>JavaEE ... спецификация корпоративного уровняэто неплохой такой
* барьер в поиске специалистов
* увеличитель времени на разработку
* увеличитель затрат на поддержку
* источник проблем, мешающих высоким нагрузкам>JavaEE - плод многолетней шлифовки API под типичные задачи корпоративного сектора
попытка создать спецификацию, ветвь эволюции, которая сейчас по сути остановилась и замерла.
За примерами далеко ходить не надо
GlassFish - от разработки которого отказалась Oracle
Keycloak - оин из флагманских продуктов Rad Hat - сам ред хэт перевёл его с WildFly на QuarkusЯ, признаюсь не считаю Quarkus реализацией Java EE (Под Java EE я подразумеваю именно классические App Server'а такие как WildFly, GlassFish, WebLogic, ...), они взяли из неё лучшее, дополнили микросервис-паттернами и назвали MicroProfile, но по сути, мы то знаем, чем они вдохновлялись. (Spring Boot)
>барьер в поиске специалистов- человека который не знает JPA не стоит брать на работу по созданию корпоративных приложений на Java
>увеличитель времени на разработку
- каким способом? Приведите какой нибудь пример, а то я не могу понять
>увеличитель затрат на поддержку
- если пример о переходе со SB2 на SB3 показался Вам не значимым, предлагаю не возвращаться к этому тезису
>источник проблем, мешающих высоким нагрузкам
- а я думал это неумехи программисты пишут кривой код, а оказывается это спецификация JavaEE виновата ...
>GlassFish - от разработки которого отказалась Oracle
- это была хорошая новость, так как Oracle известный "убийца" проектов, а GF (как кстати и NetBeans) продолжает жить и успешно развиваться. Однако пример Вы выбрали неудачный, так как от WebLogic Оракл не отказался, а по Вашей логике это должно означать что технология годная)
>сам ред хэт перевёл его с WildFly
- только не забудем что RedHat купил JBoss (aka WilFly) и продолжает поддерживать и развивать его
>Под Java EE я подразумеваю именно классические App Server'а такие как WildFly, GlassFish, WebLogic, ...)
- об этом я уже писал выше и ссылку давал на стек спецификаций Jakarta EE. То что лично Вы не считаете сервлеты, или JPA, или Jakarta WebProfile, или Tomcat, или etc входящими в экосистему JavaEE, не означает что это так. JavaEE - это набор спецификаций и некоторые из них востребованы и очень популярны, а с некоторыми джун или мидл могут вообще никогда не встретиться
>они взяли из неё лучшее, дополнили XXX-паттернами и назвали YYY, но по сути, мы то знаем, чем они вдохновлялись
- это важно? Если важно, то не забывайте что Spring создали в 2003 году взяв лучшее от EJB2))
>>Java EE - барьер в поиске специалистов
>- человека который не знает JPA не стоит брать на работу по созданию корпоративных приложений на JavaПопробуйте поискать кандидата со знанием Java EE, так и напишите в вакансии - требование - знание Java EE.
> пример о переходе со SB2 на SB3 показался Вам не значимым
я написал выше где-то, что это решается выстраиванием процессов, а не попыткой "прилипнуть" к спецификации.
>источник проблем, мешающих высоким нагрузкам
>- а я думал это неумехи программисты пишут кривой код, а оказывается это спецификация JavaEE виновата ...вы упускаете суть. Ещё раз - написание приложений с использованием Application Server - это помеха высоким нагрузкам. Нормальных примеров хайлоада уровня Нетфликс с Application Server, а не просто г-спади ЕМИАС вы не привели :)
>Попробуйте поискать кандидата со знанием Java EE, так и напишите в вакансии - требование - знание Java EE- весь стек JavaEE обширен и очевидно что людей которые практически работали со всеми его элементами очень мало (даже и в мировом масштабе). Но то же самое можно сказать и про Spring: security, integration - и вот список кандидатов резко уменьшился. А если соискатель заявит что знает всю экосистему, можно только улыбнуться его наивности или дерзости. А возвращаясь к JavaEE - знать JavaEE API это гораздо реальней, чем знать всю экосистему Spring.
>пример о переходе со SB2 на SB3 ... решается выстраиванием процессов
- дословно Вы сообщили о необходимости "тестов" и я на это ответил что это лишь способ обнаружения проблем (причем не 100%), а не способ их предотвращения или устранения
>Ещё раз - написание приложений с использованием Application Server - это помеха высоким нагрузкам
- еще раз: в чём конкретно помеха? В "природе"?
>Нормальных примеров хайлоада уровня Нетфликс
- Нетфликс это штучное решение, а мы, еще раз, вроде про корпоративные (массовые, типичные: РСУБД + WS/RS) решения говорим. Расшифруем аббревиатуру EE: Enterprise Edition - где тут Highload? Откуда в Highload РСУБД и SOAP? Вы хотите от меня чтобы я привел пример когда КамАЗ победил в гонке Формула-1)) Пример того что на стеке JavaEE можно построить большие, масштабируемые системы на примере ЕМИАС я показал. Одноклассники (в далеком прошлом) использовали EJB, т е всё возможно хотя и не типично. Мне когда то попался в руки сайт на сервлетах/jsp/jpa который на 32 Мб хипа JVM на Tomcat легко отдавал 1 млн хитов в минуту - никаких оптимизаций, хитростей: JavaEE WebProfile из коробки
>>Попробуйте поискать кандидата со знанием Java EE, так и напишите в вакансии - требование - знание Java EE
> людей которые практически работали со всеми его элементами очень мало (даже и в мировом масштабе).Не хотите замечать слона в комнате, либо никогда не нанимали Java-разработчиков)
>>пример о переходе со SB2 на SB3 ... решается выстраиванием процессов
>- дословно Вы сообщили о необходимости "тестов" и я на это ответил что это лишь способ обнаружения проблем (причем не 100%)ну так если проблема обнаружена тестами - затем исправлена (до попадания в прод) это же хорошо, не так ли ?
Поменялась мажорная версия, а вы ждёте что ничего не сломается. Так не бывает %) Вангую даже в JEE. Ещё раз - спецификация не заменит вам процессы. Если нет процессов - будут баги, падения, инциденты на проде. На всякий случай напишу, что да, тестирование/процессы не уберёт их все, но, при грамотном применеии сократит до минимума.>>Ещё раз - написание приложений с использованием Application Server - это помеха высоким нагрузкам
>- еще раз: в чём конкретно помеха? В "природе"?
>Нормальных примеров хайлоада уровня Нетфликс
>Нетфликс это штучное решение
>мы, еще раз, вроде про корпоративные (массовые, типичные: РСУБД + WS/RS) решения говоримНет, я не говорю про РСУБД + WS/RS. Я аппелировал к тому, что высоконагруженных приложений построить на JEE нельзя, что вы и сами подтвердили.
> JavaEE в чистом исполнении - некромантия из начала двухтысячных, вы где, кроме
> легаси возрастом лет в 15 последний раз application server видели. Джава
> в ынтерпрайзе - это практически всегда спринг. Правда JavaEE пытаются оставить
> на плаву в эпоху микросервисов через развитие "облегчённой" версии MicroProfile (всякие
> Quarkus, Helidon), но гуано это ещё то.Jetty — вполне себе легковесный движок-сервер приложений (сервлетов), сделанный по спецификации Java EE касательно JSP 3.0/Servlet API 5.0.
>Spring не следует спецификациям Java EE- чего так категорично? javax.xml.bind, javax.persistence, javax.servlet, javax.ws.rs и т п - всё это либо под капотом, либо торчит наружу и у Спринга
Не работает в оффлайне. Имею ввиду, что даже Ant-проект нельзя создать, если Netbeans установлен на компьютер, отключенный от глобальной сети. Проблема наблюдается уже несколько лет, и всем плевать.
Значит не пользуются.
Кроме notepad.exe мне больше ничего не нужно, чтобы писать качественный код.
Дело в объёме кода, который нужно поддерживать и сопровождать. IDE позволяют легко отслеживать изменения и вносить правки в код в многопользовательской модели разработки — в Netbeans интегрированы инструменты Mercurial и Git, позволяющие в редакторе кода видеть историю изменений и делать коммиты, не покидая среду.
ты пытаешься убедить, что экскаватор хорош, человека, которому нужно слегка копнуть землю в хелловорлд-горшке.
Программировать в notepad-е - это мем начала нулевых. В нём пишут разве что скрипты *.bat или VBS.
> в многопользовательской модели разработкиК счастью, разработка далеко не всегда многопользовательская. Соло программистов полно, от фрилансеров, до тех кто имеет свои проекты.
> Кроме notepad.exe мне больше ничего не нужноВ принципе, я тоже сторонник полностью ручного KISS подхода во всём, в т.ч. и в программировании. Но notepad.exe - это слишком примитивно. Нужна хоть какая-то подсветка синтаксиса чтобы визуально в коде не запутаться. Лично для себя остановился на Geany уже лет 10 как. VSCode не переношу, слишком "комбайн", много мусора выдаёт в подсказках.
Настройку профиля в vscode под себя не пробовали? Можете не отвечать, вопрос риторический.
У меня ОКР, большое количество настроек не даст работать.
Пользуюсь им ещё с версии 8.2 исключительно для PHP/JS/CSS. Для меня идеальный продукт. Особенно учитывая то, что когда начинал в 8.2. был русский язык интерфейса и было на много легче осваивать продукт нежели сейчас. Сравнивал его с тем же VSCode, но NetBeans всё таки конкретно для меня лучше и уже наверно "роднее". Очень привыкаешь к грамотному подсказчику, который читает все подключённые классы и показывает доступные подключённые методы в отличии от того же VSCode который кучу хлама показывает. Ну и конечно просто приятно утроена сама среда.
JS? Может уже пора TypeScript?
Может и пора. Вещь популярная, стоит попробовать.
Нетбинс очень недооцененная среда. Я когда-то решил её попробовать, очень был удивлён функционалом и возможностями, про себя подумав зачем это всё кто-то пилит если все равно никто не пользуется.
Версия 8-я была самая лучшая после 6-ой. Всё было очень хорошо пока Sun этим рулил, а потом как-то завяло всё. У Oracle своя IDE уже была, им две не к чему. Повыдёргивали оттуда что смогли и выкинули что осталось.