Java и большие проекты

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

Владимиру Малюху:

Мы в нашей группе пишем на С++ под Windows. Текст набираем в notepad или еще в каком-нибудь любимом редакторе, используя только библиотеки API. Ресурсы редактируем в Borlad Workshop. Транслируем, линкуем и собираем весь проект, используя nmake. Так что новая среда разработки не пугает. Можно использовать привычную.

А пугает вот что (далее следуют грустные мысли, навеяные изучением языка) :

В С++ всякие "утечки" памяти и других ресурсов мы изживаем, активно используя свойства конструкторов и деструкторов. Допустим, если в конструкторе что-то открыл или захватил, то в деструкторе закрыл или отпустил. А так как точно известно, когда сработает конструктор, а когда - деструктор, то никогда никаких утечек!

А в Java же finalize (т.е. деструктор) сработает тогда, когда "уборщица" соизволит заняться делом. Такое положение дел делает написание деструкторов в Java бессмысленным занятием и заставляет программиста освобождать захваченные ресурсы вручную.

Кроме того, "уборщица" просыпается тогда, когда уже начинает чувствоваться дефицит свободной памяти. Это означает, что в какой-то момент программа начнет жутко тормозить, т.к. каждая очередная операция создания объекта будет ждать освобождения памяти. К тому же создается дефицит памяти для других приложений, работающий в системе. Наратает интенсивность свопинга. Тормозит уже вся система. :(((

Может, я не прав? Может, этот апокалипсис мне только привиделся?

=KRoN=>Анализы и мне не попадались. Но когда я возился с Java (на любительском, признаюсь, уровне) в эхах и форумах по Java вопрос мусорщика всплывал постоянно. А вот в эхах по Perl/PHP такого не видел ни разу. Вот и думаю, к чему бы это?

Есть у меня гипотеза. На джаве в основном все таки больше профи пишут, чаще с си перешедшие, мусорщик для них новинка, вот и вопросы, понять хотят. Мне так кажется, что по задумке он производительность повышать должен. Память освобождается когда у программы других дел нет, а это в каждом конкретном случае виртуальной машине виднее, чем программисту (если он конечно загрузку проца все время не мониторит). Если проге считать надо, то пусть сперва досчитает, а потом вспомогательными вещами занимается. Что-то типа отложенной записи на диск в общем. Ну а если памяти так уж мало, что все время освобождать надо, то это как ни крути нехорошо,добавить надо. Вообще то эффективность таких вещей тестируется запросто.

А на Perl/PHP видимо в среднем народ более неприхотливый - заработало и ладно, зачем еще о мусоре беспокоиться. Вон visual basic программеры тоже редко о высоком говорят.

Олег>Мы в нашей группе пишем на С++ под Windows. Текст набираем в notepad или еще в каком-нибудь любимом редакторе, используя только библиотеки API.

Совершенно искренне потрясен до глубины души.

Олег>А в Java же finalize (т.е. деструктор) сработает тогда, когда "уборщица" соизволит заняться делом. Такое положение дел делает написание деструкторов в Java бессмысленным занятием и заставляет программиста освобождать захваченные ресурсы вручную.

Ну надо же хоть чуть-чуть доверять разработчикам мусорщика виртуальной машины, они же тоже головой думают. (Или ваши тесты показали обратное? Тогда извините.) Иначе надо и компилятор Си самому переписывать, а вдруг там тоже что то нехорошо сделано. А уж в самих то функциях API и утечки есть и ошибки, их просто обязательно надо переделать.

=KRoN=>Меня вот что поражает - почему в Java народ постоянно утыкается в сборщика мусора?

А что значит утыкается? Мне вот как-то пока не попадались серьезные анализы его эффективности/неэффективности. Где то есть?

Олег>Мы в нашей группе пишем на С++ под Windows. Текст набираем в notepad или еще в каком-нибудь любимом редакторе, используя только библиотеки API.

KRoN>Если не пробовали, то порекомендую встроенный редактор FAR'а с плагином Colorer. Плюсы - родной text-mode, удобная работа с вертикальными блоками, интеллектуальная раскраска (вплоть до раскраски синтаксических ошибок), куча прелестей типа быстрого перехода на парную фигурную скобку и т.п. Всё это для нескольких десятков языков и форматов.

ab>Совершенно искренне потрясен до глубины души.

Средства разработки выбирались исходя из задачи. Дело в том, что setup с новой версией программ наши клиенты получают во время связи с ценральным сервером. Часто для этого используются модемы. Число клиентов измеряется тысячами. Все это диктует жесткие требования к объему программ. Нам удалось решить эту задачу: клиентовская программа (весьма сложная Windows-аппликация с пользовательским интерфейсом на 3-х языках) и сервер клиентовской (локальной) базы данных занимают менее 300 кб.

KRoNу - спасибо за совет.


Олег>А в Java же finalize (т.е. деструктор) сработает тогда, когда "уборщица" соизволит заняться делом. Такое положение дел делает написание деструкторов в Java бессмысленным занятием и заставляет программиста освобождать захваченные ресурсы вручную.

ab>Ну надо же хоть чуть-чуть доверять разработчикам мусорщика виртуальной машины, они же тоже головой думают. (Или ваши тесты показали обратное? Тогда извините.)

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

ab>Иначе надо и компилятор Си самому переписывать, а вдруг там тоже что то нехорошо сделано. А уж в самих то функциях API и утечки есть и ошибки, их просто обязательно надо переделать.

Достаточно знать недостатки и ошибки используемых средств разработки и уметь обходить их. А переделывать и переписывать - эта кустарщина.

KRoN>Может, от указателей в java отказались как раз из-за того, что корректную сборку мусора с ними не придумали?

Нет, Java с объектами работает как раз только через указатели. Но эти указатели "статические", их нельзя двигать. Поэтому они называются не указатели а референции. Статичность референциий обеспечивает безопастность java-программ в том смысле, что программа в принципе не всостоянии "дотронуться" до чего-либо, кроме своих переменных и своих данных. "Статичность" референций на объекты также привела к отказу от множественного наследования, что дало замечательный эффект: одна и та же референция указывает на сам объект и одновременно на всех его "предков". Проблема же не в том, чтобы освободить память из-под объекта, а в том чтобы надежно и оперативно освободить захваченный объектом ограниченный системный ресурс. Особенно это становится актуально в свете инкапсуляции, когда нам не известны детали реализации класса. Мы можем не знать или, зная, не иметь доступ к захваченному ресурсу. А "уборщица" вприципе не может ничего знать о таких ресурсах. Есть возражения?

ab>Есть у меня гипотеза. На джаве в основном все таки больше профи пишут, чаще с си перешедшие, мусорщик для них новинка, вот и вопросы, понять хотят.

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

На самом деле идея "мусорщика" проста и понятна. Мусорщик освобождает память из-под более не используемых объектов. При этом выполняется finalize. Но как быть, например, с закрытием файлов или сокетов? Эти ресурсы в системе ограничены. Если их не закрывать вручную, а ждать "мусорщика", то очень скоро программа будет заниматься только обработкой exception. Я прав? Или нет?