powered by simpleCommunicator - 2.0.38     © 2025 Programmizd 02
Форумы / Java [игнор отключен] [закрыт для гостей] / Java 8 - уже не совсем Java?
25 сообщений из 448, страница 13 из 18
Java 8 - уже не совсем Java?
    #39202315
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton,
толи ещё будет https://habrahabr.ru/post/280188/
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39202318
Фотография Usman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39202328
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Usmanвадя,

var (справочник по C#)
но для написания в ide лучше четко определить - ide будет проще конторолировать.
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39202336
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Почитал. ПОЛНОСТЬЮ плюсуюсь. Человек верно пишет. Все так и есть (((
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39202405
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
http://izm.izvm.net/zhaba/java-a.htm 17) Одно из замечательных изобретений Вирта - перечислимый тип. Жаль, что он от него отказался в Обероне. В каком-то виде этот тип пробрался даже в С. В Жабе его нет, и это очень неудобно. Вместо него - просто целые "константы", которые вовсе и не константы. Никакой проверки типов (которая была бы естественна для "надежного" языка). Иные удальцы применяют классы для этого - то есть передают указатели там, где нужно целое значение, и используют функции там, где нужно число, закодированное этим значением. В итоге программа становится совершенно нечитаемой, и к тому же на пустом месте теряется эффективность.

Я не знаю (еще раз) какой датой датируется эта статья.
Возможно автор апеллирует к спекам 1.4. Кроме того он часто упоминает Microsoft Visual J++.
Проект который уже давно мёртв. Но ключевое слово enum работает начиная с Java 1.5 (5)
и позволяет спокойно описывать перечислимые типы и даже набор методов над ними.

Код: java
1.
2.
3.
enum Days{
   MON, TUE, WEN....
}
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39202406
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
27) Сама библиотека оставляет желать лучшего. Почему, например, для узнавания текущей даты я должен выделять в памяти объект? А вот еще задачка, достойная пера. Напечатать текущую дату в формате

дд.мм.гггг чч:мм:чч.МММ (МММ - миллисекунды).

Ну все сделано, чтобы только сделать это невозможным! Вообще, опыт практического использования библиотеки заставляет подумать, что она была сделана левой ногой пьяного матроса.
Необходимо пересмотреть с учотом Java8 (java.time.*)

Код: java
1.
2.
LocalDate date = LocalDate.now();
String datePrefix = date.format(DateTimeFormatter.ofPattern("yyyy-MM-dd"));



Возможно аллоцирование форматтеров перенесено в пулы и т.п.
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39202409
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Только сейчас получил:

java.lang.Error: Unresolved compilation problem:

Б...! Этот язык компилирующий или что? Какая нафиг compilation problem в момент выполнения?
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39202412
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton
Код: java
1.
2.
LocalDate date = LocalDate.now();
String datePrefix = date.format(DateTimeFormatter.ofPattern("yyyy-MM-dd"));


Возможно аллоцирование форматтеров перенесено в пулы и т.п.
Если следовать логике автора, то immutable объекты это совсем за гранью. Там ведь не просто объект аллоцируется! Он на каждую операцию аллоцируется! А то что производительность GC от количества мусора почти не зависит, это ведь ещё знать надо.
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39202413
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
29) При написании на С много внимания уделяется всяким случаям вроде "А что если функция malloc вернула NULL?" Так вот, в Жабе считается, что память всегда есть. В общем-то никаких оснований для этого нет. А когда память кончится, будет брошена эксепция вроде OutOfMemoryException, которая есть объект и должна быть выделена в куче...
В данном тезисе автор лихо играет софизмами и парадоксами (почеркнуто)
тоесть не по сути.

Аллокация new действительно всегда работает OK и память всегда есть.
Ситуация когда ее нет - не перехватываемая ошибка и с точки зрения
приложения - это авария и на ее решение вобщем-то нет рецепта нигде.

Возможно behaviour систем версии 1.4 был действительно иной.
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39202415
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Blazkowiczmayton
Код: java
1.
2.
LocalDate date = LocalDate.now();
String datePrefix = date.format(DateTimeFormatter.ofPattern("yyyy-MM-dd"));


Возможно аллоцирование форматтеров перенесено в пулы и т.п.
Если следовать логике автора, то immutable объекты это совсем за гранью. Там ведь не просто объект аллоцируется! Он на каждую операцию аллоцируется! А то что производительность GC от количества мусора почти не зависит, это ведь ещё знать надо.
Станно но введение immutable объектов повысило производительность Card-Raytracer.
Можно найти даже конкретный коммит где я оптимизирую Vector добавляя в него
final и переписываю логику таким образом что координаты x,y,z внутри вектора
отдельно не мутируют.
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39202419
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BlazkowiczЕсли следовать логике автора, то immutable объекты это совсем за гранью. Там ведь не просто объект аллоцируется! Он на каждую операцию аллоцируется! А то что производительность GC от количества мусора почти не зависит, это ведь ещё знать надо.
А оно не так?

А производительность GC от количества мусора и размера кучи зависит очень сильно. По крайне мере в 1.6. Очень бы хотелось понять, что за GC алгоритм такой чудесный, что "почти не зависит".

Да и сама по себе инструкция new - конечно очень быстрая (если сравнивать с другими языками), но не мгновенная.
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39202422
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: sql
1.
31) Меня очень раздражает оператор "+" для строк. Не люблю исключений. Вообще, значит, операторы не переопределяются, а вот для строк пожалуйста. При этом, если объект не строка, вызывается специальный метод со специальным именем toString... Ну зачем превращать язык в BASIC? Ясно же, что все так и будут применять этот оператор для складывания строк, плюя на эффективность. Есть класс StringBuffer, а кто им пользуется?


Я наблюдал эволюцию компиллятора. И сегодня мы можем
больше использовать оператор + (к примеру при перегрузке
toString()) и не париться о том что конкатенация будет собрана
через StringBuffer StringBuilder.

Опять-же тезисы автора касались весьма древних компилляторов.
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39202427
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid KudryavtsevА оно не так?
А производительность GC от количества мусора и размера кучи зависит очень сильно. По крайне мере в 1.6. Очень бы хотелось понять, что за GC алгоритм такой чудесный, что "почти не зависит".
Да и сама по себе инструкция new - конечно очень быстрая (если сравнивать с другими языками), но не мгновенная.
GC сканирует и перемещает живые объекты. Мусор при этом целиком и полностью отмирает как единое целое. Хоть его мегабайт был, хоть сто. Не важно. А вот сканирование живых объектов занимает время.
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39202430
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid KudryavtsevДа и сама по себе инструкция new - конечно очень быстрая (если сравнивать с другими языками), но не мгновенная.
Тут надо ставить на обе чаши весов очень много аргументов. new в С++ может
быть в заведомо неблагоприятных условиях. Работать по фрагментированной
куче где free вроде-бы есть но целым экстентом выделить невозможно на данный
момент без каких-то дополнительных действий по уплотнению. В Java - аллокация
идет как на стеке без поисковых операций поэтому накладые могут быть меньше.
Вобщем это уравнение со многими неизвестными. И сравнение стоимостей
new/free надо делать в бенчмарках с возможностью многократного повторяемого
воспроизведения условий.

Я такие бенчмарки не смог создать. Хотя и обещал в части своих тяпничных блогов.
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39202435
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кто нибудь знает этого африканца?

Киньте ему ссылочку сюда если можете.
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39202446
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BlazkowiczLeonid KudryavtsevА оно не так?
А производительность GC от количества мусора и размера кучи зависит очень сильно. По крайне мере в 1.6. Очень бы хотелось понять, что за GC алгоритм такой чудесный, что "почти не зависит".
Да и сама по себе инструкция new - конечно очень быстрая (если сравнивать с другими языками), но не мгновенная.
GC сканирует и перемещает живые объекты. Мусор при этом целиком и полностью отмирает как единое целое. Хоть его мегабайт был, хоть сто. Не важно. А вот сканирование живых объектов занимает время.
Дьявол кроется в мелочах:
1. Eden область: Copy GC
2. Old область: Mark Sweep GC

Выделение объектов ---> больше потребление памяти --> чаще вызов GC. Т.к. copy gc крайне быстро работает, то пофиг

Массивное выделение объектов + частый вызов minor GC + несколько потоков - есть риск, что temporary объекты из Eden области попадуть в old область heap. А вот это уже очень плохо ((( Т.к. мусор в old области в heap - распухание heap и значительно замедление и без того медленного Mark Sweep.

AFAIK

note: в терминах могу ошибаться, но смысл думаю ясен

Blazkowicz...Мусор при этом целиком и полностью отмирает как единое целое. Хоть его мегабайт был, хоть сто...
В реальной жизни ситуации когда из Eden мусор проникает в Old - как грязи, как Eden не выкручивай.

Хотя, на прошлой работе добились того, что при многозадачной работе Oracle Customer Care & Billing mark sweep GC запускался всего 1-2 раза за целый рабочий день предприятия ))) До настройки памяти (default значения) было раз в 1.5 - 2 сек + периодические out of memory.
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39202448
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid KudryavtsevВ реальной жизни ситуации когда из Eden мусор проникает в Old - как грязи, как Eden не выкручивай.

Вот уж не знаю. Мы через ratio сводили это к минимуму.
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39202460
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BlazkowiczВот уж не знаю. Мы через ratio сводили это к минимуму.
А просто Eden задирал до максимуму (1/2 памяти). Остальные параметры читал, но если памяти под Eden достаточно - то и бог с ними, если мало - как мертвому припарка.

Тот же Oracle Customer Care & Billing.

ОДИН И ТОТ ЖЕ код выставления счета, запускаемый из Web-морды (over 300-400 Mb всякого GUI барахла в Heap) и из Batch processing (отдельная VM, в Heap мусора нет) - во втором случае работал в разы (2-3 раза) быстрее.

Но у них при каждом выставлении одного счета по 200-300 Mb temporary объектов (Copy Book) создается. В общем, память гадят знатно
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39202468
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
p.s.
При этом одним временем на GC не объяснимо. Т.к. на GC уходит пусть и больше времени, но не намного. Возможно какие-то скрытые эффекты, типа фрагментации кучи и лучшего использования кэша процессора. Загадочно, но факт.
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39202475
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Только мне кажется, что оптимальный код генерации счетов даст в разы бОльший эффект, чем возня с оптимизацией сборки мусора?
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39202477
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovТолько мне кажется, что оптимальный код генерации счетов даст в разы бОльший эффект, чем возня с оптимизацией сборки мусора?
Всё зависит от трудоёмкости оптимизации этого кода.
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39202496
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Это понятно. Непонятно другое.
Есть проблема.
Есть известный путь решения с некими затратами. Гарантированное решение с, более-менее, гарантированными затратами.
Но есть ещё "эффективный менеджмент", который сразу заявляет: "Это дорого". И начинает неопределённое время сношать мозг и заказчику и самому себе.
Вот чего я не могу понять.
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39202498
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И сама возможность оптимизации.

Код покупной. Гей-архитектор где-то на западном побережье. Код пишут пара сотен манильцев. Кому оптимизировать ? )))

Там и так, все в лучших традициях ООП - патерн на патерне и патерном погоняет. Самая крутой патерн - Copy book. Дает работу огромному кол-ву манильцев. Без него, кол-во бедных в маниле было бы намного больше )))
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39202500
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorov...Есть проблема....
Да нет там проблемы.
1 .Решение масштабируемое - купите еще N серверов, считать будет в N раз быстрее.
2. Выставляется счет через интерфейс за 1 сек или за 3 сек - пользователю в целом пофиг.
3. При ситуациях "когда ночной batch процесс не успевает за ночь закончится" ( C ) см. п. 1 Или сервер можно перевезти в Варкуту. Там зимой ночи длиннее )))
...
Рейтинг: 0 / 0
Java 8 - уже не совсем Java?
    #39202632
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonКто нибудь знает этого африканца?

Киньте ему ссылочку сюда если можете.
зачем?

Выбери, чего ты чего на самом деле хочешь:
- узнать, как изменилось его мнение с тех пор
- спросить - почему не оправдались его прогнозы о недолгой жизни обсуждаемого им сабжа
- хочешь, поспорив с ним по каким-то конкретным деталям, опровергнуть его взгляд в целом
?

Последнее, имхо, бессмысленно.

Прими в расчет следующее:
- тот сайт литературный , и предложенные тобой заметки, по сути,
являются литературным произведением для программистов.
- На том сайте последнее сообщение размещено в 2008 году, а обсуждаемые заметки я склонен отнести по косвенным признакам к 2000-му году, т.е. ко времени jdk 1.3
- (имхо) в целом, сам по себе текст Африканца в техническом плане весьма приличного качества. Но, писался в , как мне кажется, несколько второпях, преследуя больше литературные цели, чем цель последовательного "опровержения" языка.
Его литературная задача мне понятна - заявить, что вместе с явой в мир программирования
громко и напористо приходит агрессивный непрофессионализм, активно порождающий собственный мир не просто заявляющий право на существование, а претендующий на абсолютное заполнение всего пространства программирования.
(Это умом объять невозможно - говорят, что в мире уже 19 миллионов java-программистов, а скоро станет 25.
Т.е. уже больше 2.5 java-программистов на каждую 1000 душ населения Земли.
Для сравнения: в 1904 году в городах Западной Европы в среднем было 4 извозчика на 1000 городских душ.
В России, правда, заметно больше - от 3.38 в Лодзи с пригородами (это ровно как если бы уже сейчас было 25 миллионов java-программистов в расчете на 1000 ныне живущего на Земле населения) до 18.8 в Москве.
)
По технике его замечания касаются синтаксиса, быстродействия, пригодности к созданию "больших проектов". По части синтаксиса - это больше "вопросы вкуса", даже там, где это касается простоты или сложности или "наивности" предполагаемого компилятора.
По части всего остального - общий ответ примерно такой - java никогда (до сих пор) не
позиционировалась как средство создания критичных по производительности систем или систем реального времени. Уж как минимум - не позиционировалась так создателями языка.
Для задачи доставки компактных аплетов в браузер клиента в ней с самого начала всего достаточно. И вряд ли стоит упрекать создателей в том, что у языка фактическая жизнь оказалась и дольше, чем можно было бы ожидать, и, в конце концов, совсем другого
назначения. Решения сорта жить или умирать принимаются не ими.
Даже если это кому-нибудь обидно (например - Вирту).

PS
Все сказанное выше исключительно "по моему скромному мнению".
Кто такой Африканец я не знаю.
...
Рейтинг: 0 / 0
25 сообщений из 448, страница 13 из 18
Форумы / Java [игнор отключен] [закрыт для гостей] / Java 8 - уже не совсем Java?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]