Недостатки java?

[Mikhail]

Вот и нет. На LOR на спор провели тестирование. С и JAVA. Задача была сгенерировать 100 лимонов строк, поместить из в список, отсортировать, и выполнить случайную выборку.
Мало того что на JAVA это реализуется меньше чем за час, так еще и С программа (в первой ее реализации) с треском провалилась. Отстала процентов на 30. После оптимизации сравнялась с JAVA реализацией. В старых обсуждениях (год так 2005) можно эту тему найти.

Это показало лишь то, что Вы умеете Яву, а Ваш оппонент не очень умеет Си, не более того...

Добавлено спустя 1 минуту 15 секунд:
да, еще, естественно время разработки на Си будет больше, как правило.

[скалогрыз]

Важный момент для серверов - на Java можно написать демон и удаленно командовать им через CORBA,
а на FPC теперь понимаю что CORBA-поддержку принципиально не делают (хотя уже 100 лет как заявили интерфейсы данного типа).

да почему же?! Поддержку CORBA интерфейсам сделали 99 лет назад. Весь Cocoa widgetset основан на них

[Mirage]

Плюсы:

• Кроссплатформенность. JVM и грамотно продуманные библиотеки отлично абстрагируют от конкретной ОС. Не на 100%, конечно, но лучше я не видел.
• Продуманное API. Хороший пример - коллекции. Прямо стоит брать на вооружение принцип именования. Интерфейс - List, Set, Map etc и реализации - ArrayList, HashSet, HashMap, TreeMap,... И иерархия классов в коллекциях тоже грамотная.
• Модель памяти и вообще хорошая поддержка многопоточности. Без модели памяти эффективное использование потоков малореально, особенно кроссплатформенно.
• Java быстрая - JIT компилятор творит чудеса. Например, может заинлайнить виртуальный метод. А если вдруг что - разинлайнить обратно. А о такой банальности, как использование возможностей конкретного CPU уж и не говорю. Плюс эффективная реализация базовых библиотек. Тормоза Java давно в прошлом.
• Хорошая поддержка web-приложений. Тут тебе и MVC фреймворки, и ORM фреймворки, и встраиваемые web-сервера (в т.ч. реализованные в одном классе), и реализации сопутствующих технологий. И все это между собой еще и неплохо интегрируется.
• Открытость. Куча бесплатных библиотек и инструментов в исходниках. И это правило, а не исключение. Да и сама JVM opensource давно.
• Сборка мусора. Мне непринципиально, но многим нравится.
• Системы сборки и управления зависимостями. Имею в виду прежде всего Maven.
• Поддержка многих языков на уровне JVM. Есть и весьма интересные типа Scala или Kotlin.
• Ну и конечно Intellij IDEA

Минусы:

• Сам язык. Многословен, причем не к месту. Временами многословнее Паскаля, который тоже не сестра таланта.
• Любит кушать память. Есть методики написания маложрущих программ, но это нетривиально и мало кто заморачивается. Да и JVM сама по себе немало кушает.
• Ява Яве рознь. Реализация под Андроид довольно тормозная.
• Легко схватить утечку памяти.
• Пользователям нужно JVM ставить.
• Бенчмарки, в т.ч. для сравнения с другими языками писать сложно. Для этого даже специальный фреймворк есть. Возможно, из-за этого так популярен миф о тормозах. Т.к. обычно в бенчмарках включают и время анализа и модификации JIT-компилятором кода.

По поводу интерфейса: есть Swing (IDEA это Swing кстати), который рисует все сам. А есть SWT (Eclipse), который использует контролы OS.
Конструктор приличный в NetBeans, да и в IDEA неплохой.

1. Ну с... Одна и та же программа с одним и тем же алгоритмом... В лазарусе загружала с данными 85 мегабайт, в C# 120 мегабайт. Явовская версия ни с того ни с сего вдруг захотела 790. Де факто.

Программу в студию! Это больше похоже на проблемы конкретного программиста, а не языка.

[azsx]

1. Ну с... Одна и та же программа с одним и тем же алгоритмом... В лазарусе загружала с данными 85 мегабайт, в C# 120 мегабайт. Явовская версия ни с того ни с сего вдруг захотела 790. Де факто.

также интересно глянуть программы. Просто спрошу, не может ли c# врать для системы мониторинга? Просто программы для net (которые я видел) - это ппц. Нагрузка на старых процах большая. Память оперативную ест пачками. И что не новая программа, то ей нужна какая то иная версия фреймворка.

[SSerge]

Программу в студию! Это больше похоже на проблемы конкретного программиста, а не языка.

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

Мне все любопытно "текст в студию". Вы ж понимаете, что при таком объеме данных, пихаемых в память, текст отнюдь не ограничивается "одним экранчиком". И кто в здравом уме и по доброй воле будет в нем отлавливать косяки нерационального применения того или иного? В лучшем случае, бегло взглянув, будет высказано нечто типа "а вот в этом месте я использовал бы stringBuilder, потому что тогда будет быстрее и экономнее. После тщательного анализа, возможно, выяснится, что именно это место - как раз никакого влияния на быстродействие и экономичность не оказывает. Ага, щас кто-то скажет - с таким количеством данных - нужно использовать СУБД! Особенно те, кто СУБД использует когда надо и когда не надо. Что ж, еще одно направление, в некоторых случаях способное инициировать замедление обработки в десятки, а то и в сотни раз. Так что текста в студию не будет. В том случае был чисто индивидуальный интерес "а вот ради практики, почему бы не сделать". Был взят оригинал на C# и прямо по тексту из спортивного интереса переписан на яву. Надо сказать, довольно хорошо переписывается, почти 1:1, доставляли только строковые функции взятия сегмента, где в параметрах не как у всех - позиция начального символа сегмента, его длина, а довольно странная выдумка: позиция начального символа, позиция первого символа, не входящего в выбираемый сегмент. Обратно с явы на сишарп, imho, все переписаывется гораздо хуже из-за обычного широкого использования в оной встроенных неименованных классов и всяких фишек инициализации "на лету", которые в сишарпе используются куда реже, а самое главное - по другому.

Добавлено спустя 6 минут 44 секунды:

Нагрузка на старых процах большая

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

Желаете замедлить С#... Кроме рекомендаций выше, вам поможет mono for linux. Чертовски медленно и неэффективно работает. Чем старее, тем хуже. А самое новое mono - как уже говорил - только на SUSE и нигде более.

[debi12345]

но использовать, что С, что яву на постоянной основе...

А куда от них деться ? Например нужно написать расширение для PostgreSQL, а там все API построено на С-ных макросах.
Или уже упомянутая CORBA - реализована только на Java/C++.
Жизнь заставляет "плакать, колоться но все-таки жрать кактус".

Добавлено спустя 6 минут 2 секунды:

да почему же?! Поддержку CORBA интерфейсам сделали 99 лет назад. Весь Cocoa widgetset основан на них

Нужен не только стиль объявления интерфейсов, но и регистрация и координация через брокер, диспетчеризация вызовов, сетевой обмен, шифрование,.. - то есть полноценная большая библиотека.
Вот пример из реальной жизни когда FPC не выручил : LINUX-демон репликации, одновременно залогиненный в PostgreSQL-DB и Oraclе-DB, и управляемый (инициация репликации, проверка соединений, получение статуса, статистика, выполнение произвольных SQL-команд,..) консольными утилитами), дружащий с юникодом и кириллицей в LINUX-консоли и имеющий юникодые драйвера под обе БД. Реально (все перерыл) не нашел иных вариантов, кроме как сам демон - Java-прога (ессно запускающая JVM),а управляющие утиллиты - C++.

[hinst]

Если жаба не тормозит то почему в ОС Android перешли начиная с версии 5 с VM Dalvik на компилятор ART ? Потому что разработчики поняли что жаба тормозит и попытались сделать её быстрее, разработав компилятор ART "Android Runtime" на замену имеющейся VM. Только это не очень-то помогло! Стало быстрее, но не намного.

Если жаба не занимает много памяти то почему Lazarus тратит 200 МБ RAM; а Intellij тратит 700 MB RAM ?

Добавлено спустя 6 минут 22 секунды:
Почему для того чтобы жаба работала быстро, потребовалось 20 лет на её оптимизацию? Потому, что концепция VM была тормозная с самого начала

Добавлено спустя 29 минут 20 секунд:
Да, сейчас она теперь быстрее. Но это балин всё равно что установить реактивный двигатель на КАМАЗ чтобы он ехал так же быстро как BMW. Стартует всё рано дольше и памяти тратит всё равно больше

[debi12345]

Стартует всё рано дольше и памяти тратит всё равно больше

JAVAC генерит удобно оптимизируемый байт-код - и эффект от этого будут все время увеличиваться с внедрением в виртуальный машины оптимизации на SSE/AVX-инструкции. Уже сейчас на некоторых (векторизуемых) операциях Java обходит C.

Добавлено спустя 4 минуты 19 секунд:

а Intellij тратит 700 MB RAM ?

Хорошая прога должна брать по максимуму ОЗУ и процессорные тики, если это ускоряет ее работу - ессно при этом не жадничая если паралелльно с ней работают ее "коллеги".

[vitaly_l]

Java обходит C.

Это технически невозможно, т.к. в работе процессора нет: ни Java ни С ни Pascal... Соответственно это программисты на JAVA более грамотно пишут код нежели программисты на С.

[Лекс Айрин]

Соответственно это программисты на JAVA более грамотно пишут код нежели программисты на С.

скорее тут лучше говорить о создателях компиляторов.

[debi12345]

Java обходит C.

Это технически невозможно, т.к. в работе процессора нет: ни Java ни С ни Pascal... Соответственно это программисты на JAVA более грамотно пишут код нежели программисты на С.

Возможно, если один из "конкурентов" полнее задействует много-операторные (векторные или DSPшные) инструкции современных процов. В Java это сделать легче, так как есть промежуточная runtime-стадия (байт код) - все зависит от инттелекта JVM

[Mikhail]

Возможно, если один из "конкурентов" полнее задействует много-операторные (векторные или DSPшные) инструкции современных процов. В Java это сделать легче, так как есть промежуточная runtime-стадия (байт код) - все зависит от инттелекта JVM

Любой оптимизирующий компилятор сначала генерирует промежуточный код. И главное, у оптимизатора нет никаких ограничений на время оптимизации, в отличие от JIT-компилятора. Что касается сбора статистики в runtime, то такие возможности есть и у обычных компиляторов.

[vitaly_l]

есть промежуточная runtime-стадия (байт код) - все зависит от инттелекта JVM

Что касается сбора статистики в runtime, то такие возможности есть и у обычных компиляторов. И главное, у оптимизатора нет никаких ограничений на время оптимизации, в отличие от JIT-компилятора.

Это ещё раз доказывает: именно некомпетентность С программистов, т.к. они даже при таком громаднейшем плюсе и форе, как "время оптимизации" - умудряются проиграть JAVA по скорости, у которой нет этой форы и времени на оптимизацию.


.

[Mikhail]

именно некомпетентность С программистов

Это лишь показывает некомпетентность некоторых программистов (и не только на Си).
Некоторые почему то считают что написание программы на Си или ассемблере автоматически делает ее быстрой и малоресурсной.

[debi12345]

Любой оптимизирующий компилятор сначала генерирует промежуточный код. И главное, у оптимизатора нет никаких ограничений на время оптимизации, в отличие от JIT-компилятора. Что касается сбора статистики в runtime, то такие возможности есть и у обычных компиляторов.

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