239

Язык программирования Ява

Если от заголовка поста дернулся глаз - вы по адресу.

Для ЛЛ:
Я пытаюсь построить открытое Java-комьюнити. Ничего не продаю
Ссылка на тг: Дорогу осилит идущий. Java

Мои посты на Пикабу обычно направлены на людей, которые хотят познакомиться с Java или недавно начали ее изучать. В этом отношении ничего не меняется - приходите, я буду рад помочь с материалами, ответить на вопросы или отревьюить код.

Но этот пост рассчитан в первую очередь на более опытных ребят - от Junior-специалистов до матерых сеньоров. Мне не нравится писать продаванскую херь, поэтому постараюсь не лить воду.

В разрабатываемом курсе завершен раздел, посвященный JPA. Кажется, вместе с несколькими предыдущими разделами накопилось достаточно материала, который может быть интересен начинающим и продолжающим специалистам. И я буду рад, если мои статьи окажутся полезными для них.

Кроме того, если вы решили перейти в Java с другого технологического стека или направления - надеюсь, вы найдете как полезные для себя материалы, так и чат, в котором вам помогут с любыми техническими или околотехническими вопросами.

Наконец, я уверен, что здесь есть масса классных специалистов, которым хочется попробовать себя в роли лектора или просто пообщаться в кругу коллег за пределами курилки. Здесь целая пачка вариантов:

  • Есть желание похоливарить или обсудить технический вопрос - супер, у нас плюрализм мнений и совершенно не токсичное сообщество (ага, конечно)

  • Интересно написать статью или организовать вебинар, но не привлекают Medium, Habr и другие площадки - отлично, всегда рады новым лицам и качественному материалу. Заодно поможем с вычиткой и редактурой, если нужно

  • Хочешь поучаствовать в ревью - у нас бывают ивенты для новичков, где одна из ключевых задач - привить привычку писать хороший код

  • Прет от математики или, божеупаси, литкода - это у нас тоже есть, энтузиасты прилагаются

Со своей стороны могу гарантировать, что все это не будет засрано рекламой, ботами, политотой и прочим говном. Больше двух лет все строится на добровольных началах и желании сделать этот мир чуть лучше, чем он есть.

И, конечно, минутка лайкодрочерства: хочется, чтобы пост поднялся повыше и его увидело больше людей

P.S. Показалось, что вкорячить в пост тег "IT-юмор" - охуенная тема (к слову, свинья - тоже охуенная тема). Поэтому - анекдот:

Встретил в поле Иван Царевич Змея Горыныча об одной голове.
Достал он свой меч-кладенец и срубил голову, но на её месте появилось две. Срубил две — выросло четыре, срубил четыре — выросло восемь.
Так рубил Иван Царевич головы, пока не снёс Змею 65536 голов, и сдох Змей Горыныч, ибо был он 16-ти разрядный.

Язык программирования Ява Без рейтинга, IT, IT юмор, Java, Работа, Помощь, Образование, Учеба, Волонтерство, Карьера, Разработка, Благотворительность, Поиск работы, Удаленная работа, Программирование, Консультация, Мат
Вы смотрите срез комментариев. Показать все
1
Автор поста оценил этот комментарий

Java - это язык курильщика. Язык здорового человека называется C# :)

раскрыть ветку (18)
3
Автор поста оценил этот комментарий

Джава это язык который заставляет написать вчетверо больше не пойми зачем. Язык вообще как будто остановился в развитии 30 лет назад.


Прошло лет 20 а до сих пор даже память динамически выделять не умеет. После 5 часов работы программы лаги полнейшие от нехватки памяти.


Самый эпичный фейл это то, что если ему дать больше памяти, то работает ещё хуже.


Вообще на джаве негласный лимит памяти в четыре гига. Выше выдать так виснет.

раскрыть ветку (13)
0
Автор поста оценил этот комментарий
Как минимум сервисы с 12 хипа у меня точно были

Что там не так с динамическим выделением памяти тоже не уловил
раскрыть ветку (6)
0
Автор поста оценил этот комментарий

Всё просто.

2 гб скорость 1

4 гб - 0.9

8 гб - 0.5

16 гб - 0.3


Если сервис один запрос в секунду и считать ненужно, то это неважно конечно.


А с памятью просто, нужно при старте программы указать сколько она ест. Изменился контент, перезапускай прогу. Заказал больше положенного, зависло намертво. Такого идиотизма в нормальных языках нет.

раскрыть ветку (5)
0
Автор поста оценил этот комментарий
Может и ссылка на бенчмарки найдется? Пока звучит мутно и в своей практике такого поведения не помню. При том, что с хайлоад/ лоу-летенси приложениями мне приходилось сталкиваться

Что же до фиксированного размера на запуске - вроде логично. Какой контекст должен изменяться, чтобы кардинально менялось потребление оперативной памяти приложением, я слабо представляю. И это кажется вполне разумной защитой от дурака, честно говоря
раскрыть ветку (4)
Автор поста оценил этот комментарий

бенчмарки этого не покажут никак. Просто потомучто там нет десятков тысяч постоянно спавнящихся объектов как в реальной программе и накопительного эффекта. Можно запустить их, и они покажут что нет разницы.


Хайлоад у когото это десяток в снкунду запросов, а лов латенся под 50 мс. Без конкретных цифр и типов запроса это ниочем не говорит.


А что по ограничению памяти, так это просто глупость разработчиков Джавы, не осиливших ни динамически память подгружать, ни сборку мусора нормально сделать.


Получается что на джаве нельзя сделать редактор изображений, просто потому, что нельзя заранее узнать какую картинку откроет пользователь.


Плагины в минус тоже. Итд.


Зато адепты микросервисов точно рады будут получить такой аргумент к своей глупой архитектуре, типо на нашем языке такое вообще нельзя.


Ах да, у ОС выделение памяти выставляется при запуске приложения, и если кому надо то прописать туда пару гигов не проблема.

раскрыть ветку (3)
1
Автор поста оценил этот комментарий

бенчмарки этого не покажут никак. Просто потомучто там нет десятков тысяч постоянно спавнящихся объектов как в реальной программе и накопительного эффекта. Можно запустить их, и они покажут что нет разницы.

Бенчмарки покажут то, что ты в них заложишь в тех условиях, которые заложишь. Не нравится термин - замени на нагрузочное тестирование. Уверен, можно нагуглить пачку подобных тестов в паблике, где одна и та же апликуха гоняется с разными настройками jvm - от размера хипа до выбор gc и количества cpu


Хайлоад у когото это десяток в снкунду запросов, а лов латенся под 50 мс. Без конкретных цифр и типов запроса это ниочем не говорит.

Это хреновый аргумент, ибо ты не приводишь свои выкладки, а пытаешься доебаться. Или мне так кажется.
Я в данном случае говорю как минимум про истории с 6к tps (запись в пг + блокирующий http-запрос) как средний показатель на инстанс и спайки до 22к tps. И там как будто можно было бы и больше, если бы постгря не помирала
Альтернативно - апликуха (все также речь про одну ноду), которая почти целиком хранит горячие данные инмемори. Коммуникация по ws, до 20к+ открытых коннектов в моменте, активная двусторонняя коммуникация по всем, включая броадкаст на всех 10 раз в секунду. Тут точнее по метрикамне скажу, но как будто тоже не 10 rps получается.


В обоих описанных случаях и ряде других, с которыми я так или иначе знаком, хип был совсем не 4гб и становилось плохо чему угодно - sql-бд, редису, брокеру - но заметной деградации именно Java-апликухи не наблюдалось


И тем интереснее мне услышать вводные, при которых описываемая деградация наблюдалась


А что по ограничению памяти, так это просто глупость разработчиков Джавы, не осиливших ни динамически память подгружать, ни сборку мусора нормально сделать.

Можно подискутировать и с чем-то я мб даже соглашусь, но точно не в таком огульном описании


Получается что на джаве нельзя сделать редактор изображений, просто потому, что нельзя заранее узнать какую картинку откроет пользователь.

Честно говоря, не понял сути проблемы. Если вопрос к размеру изображения - какая разница, на чем написана прога и какая роль памяти в этом? Если проблема в чем-то другом - в чем? Именно передать файл в апликуху не выглядит сколь-либо значимой проблемой. Другой вопрос, что это выглядит десктопной историей, а десктоп на Джаве в целом не в почете. Если же смотреть в разрезе мобилок - уверен, абсолютное большинство редакторов под Андроид будут именно Java/другом языке того же семейства


Плагины в минус тоже. Итд.

Смотря о каких плагинах речь


Ах да, у ОС выделение памяти выставляется при запуске приложения, и если кому надо то прописать туда пару гигов не проблема.

Так и выставить размер хипа впритык к ram машины не проблема. Зато вполне очевидная защита для ситуаций, когда на одной ВМке крутится не одна апликуха и лучше отстегнуть что-то одно по факту OutOfMemory, чем дать охуеть всей машине


В целом, кажется достаточно странной тактикой хуесосить в фундаментальных вещах любой язык, который держит позиции в топе длительное время. Не потому что у такого языка нет недостатков. А потому что достаточно очевидно, что эти недостатки недостаточно критичны в области применения языка, чтобы от него отказаться

раскрыть ветку (2)
Автор поста оценил этот комментарий

Если хочется конкретных примеров на приложении: https://fractalsoftworks.com/forum/index.php?topic=8726.0 You should never exceed 8GB or you will experience stutters, freezes or even crashes


Такаяже история и с другими, при попытке выделить Джаве более восьми гигов всё подвисает.


>Это хреновый аргумент, ибо ты не приводишь свои выкладки, а пытаешься доебаться. Или мне так кажется.


Ты не приводишь свои выкладки, я не привожу свои.


> с 6к tps

Предположу что там нет каких либо рассчетов связанных с запросом, только исполнение действия. У Джавы начинаются проблемы когда именно расчеты идут. Выражается это в провисаниях на 500 мс раз в 10 секунд на сборке мусора. Вот примерно так: https://www.reddit.com/r/RLCraft/comments/14f6szj/how_do_i_g...


> Именно передать файл в апликуху не выглядит сколь-либо значимой проблемой.


Вот у меня есть изображение. Большое десятки тысяч пикселей в ширину и высоту. На диске оно примерно 10 гб, при открытии оно под 100 гигов весить начинает.


Тот же пейнт нет откроет его. А вот Джава не сможет. У нее лимит по памяти.


> десктоп на Джаве в целом не в почете.


Потому и не в почёте, что разработчики не осилили нормально сделать работу с памятью.


> Если же смотреть в разрезе мобилок - уверен, абсолютное большинство редакторов под Андроид будут именно Java/другом языке того же семейства


К тому же скрипту или C# претензий нет, там подобных эпичных фейлов нет.


> Так и выставить размер хипа впритык к ram машины не проблема.

Только пока менее 4гб на машине, Если я выставлю 256 гб, то всё рухнет.


И при выставлении максимума Джава почемуто решает, что надо занять полнностью до него, а мусор чистить только по его достижению.


> В целом, кажется достаточно странной тактикой хуесосить в фундаментальных вещах любой язык, который держит позиции в топе длительное время.


Не держит, а сдает их год за годом, от того что разрабы языка и не собираются исправлять его проблемы. И это не какие то мелочи с синтаксисом, а кардинальные в самом языке. Пока Шарп развивается, Джава нет.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий
За ссылки спасибо, покурю.

Из текста комментария предполагаю, что основная претензия к stop-the-world (мб содержимое ссылок меня переубедит в этом), но с ним-то как раз много лет пытаются в более оптимальные решения. И пока есть ощущение, что речь в первую очередь про совсем седую древность вроде serial/parallel gc

Что до файла на 100гб и остальных аргументов - как будто можно подискутировать, но, откровенно говоря, лень. Да и далековато от моей специфики, чтобы быть полностью уверенным в понимании 100% нюансов
0
Автор поста оценил этот комментарий

Я думал, что я один такой ебанутый. Ломбок должен умереть!!!!

0
Автор поста оценил этот комментарий

Поэтому адекватные человек потихоньку сползают на Kotlin.

Серьезно, в последнее время я вижу хороший прогресс в этом плане в бэкенд-разработке, тот же Spring взять.

Лет пять назад Котлин в спринг приходилось впиливать, а сейчас оно работает из коробки, некоторые либы уже пишутся целиком на котлине (что впрочем не мешает использовать их из жавы), да и в доке спринга рядом с примерами жава кода почти всегда даётся и Котлин.

Я уважаю жаву как платформу (в конце концов она подарила нам Spring, ИМХО лучший бэкенд-фреймворк из существующих). Но кажется самое время сдвинуть ее в пользу того же Котлина

раскрыть ветку (4)
0
Автор поста оценил этот комментарий
Так у человека претензии в первую очередь к JVM, а не к Java:) что котлин, что скала там будет в сорсах - все едино
раскрыть ветку (3)
0
Автор поста оценил этот комментарий

Ну, у Котлина есть натив, в конце концов

Пока-то он конечно инвалид с весьма ограниченным применением, но хочется верить что это не навсегда

А проблему с "писать вчетверо больше чем надо" Котлин вполне себе закрывает

раскрыть ветку (2)
0
Автор поста оценил этот комментарий
Кажется, я отстал от жизни. Надо про натив почитать. Если не сложно: там своя vm или сразу бинарь собирается?

Если второе, то как с отладкой дела обстоят? Насколько знаю, похожие телодвижения в джаве (GraalVM) довольно болезненные
раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Там бинарь через llvm собирается.

Насчёт отладки не подскажу - крайний раз когда я трогал натив, он был довольно инвалидным, так что мне не подошёл.

Инвалидным он был в том смысле, что был жутко медленным, медленнее в несколько раз чем тот же код на жвм. Но тогда вроде он только недавно появился

Автор поста оценил этот комментарий

Язык виндового наркомана? А чо дотнет мелкософт портировал под фсё? Или тока cli и вебсервисы писать? Ааа десктоп приложухи на вайне можно запускать? А вебсервисы можно и на го делать. Нафиг нужен с нуля такой рудимент из другой вселенной как си Шарп? Уж тогда на яве.

раскрыть ветку (3)
5
Автор поста оценил этот комментарий

Что за шизовысер? 90% софта энтерпрайза это cli и веб. Остальные 10% можно на авалонии делать.

1
Автор поста оценил этот комментарий

Когда я на C# писал, с mono его на Linux запускал.

Но потом пришёл Python.

раскрыть ветку (1)
3
Автор поста оценил этот комментарий

Сейчас .net core стал стандартом - очень круто, работает под линухи тоже.

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку