Posts Tagged → Java

Миф о Java

Про языки с автоматическим управлением памятью в целом и про Java в частности существует один довольно забавный миф – приложения с автоматическим управлением памяти не текут или текут редко. Бугагашеньки.

Берем известное и крайне популярное среди Java-разарботчиков приложение Intellij IDEA. Открываем в этом приложении большой проект (на мелком не так в глаза бросается) и работаем. Ближе к концу второго-третьего дня работы приложения, объем используемой памяти вырастает с изначальных 300 мегабайт до 700 и IDEA начинает ощутимо тормозить. Полагаю, что дальше будет только больше, лично мне на 700 это дело надоело, и я перезапустил приложение.

Что вобщем-то и требовалось доказать, напортачить можно даже на том языке, где создатели выдали тебе специальный не снимаемый памперс – было бы желание.

Как перейти из C++ разработки в Java.

Работа – штука занятная. Бывает что пишешь в течении 10 лет на плюсах, знаешь их довольно хорошо, и, вдруг, херась, и ты стал ведущим Java-разработчиком. Причем, ты даже не хотел переквалифицироваться, т.к. работодатели разрывали на куски, да и вообще инструмент нравился. Но, раз уж ввязался, не разрывать же контракт из-за такой мелочи как новый язык программирования.

Тем не менее, после такой неожиданной «переквалификации», остро встает вопрос вхождения в тему. Да, языки похожи, но библиотеки имеют мало чего общего, да и вообще, надо бы понимать что ты делаешь. Конечная цель в моем случае, выглядит приблизительно так: сетевая низкоуровневая разработка + безопасность + немного WEB-морд (Spring + JSP).

Так как долгая разработка сетевых и распределённых приложений на плюсах дает довольно хороший бэкграунд, то, в качестве «Ведения в Java» пришлось прочесть/пролистать не так уж и много. Самое полезное, что я нашел:

  1. The Structure of the Java Virtual Machine. Глупо работать с инструментом, не имея представления о его внутреннем устройстве. Так что начать надо именно с этого.

  2. Memory Management in the Java HotSpotTM Virtual Machine. Терпеть не могу работать с каким-то языком, не зная как же язык обращается с памятью. На мой взгляд, это одно из основных знаний о любом языке программирования

  3. Java for C++ Programmers. Небольшое введение в язык. Все основные вопросы рассматриваются, писать код можно начинать сразу после прочтения.

  4. Effective Java , Second Edition . Joshua Bloch. Чем-то напоминает книги «Эффективное использование C++». По большому счету, чтобы понять Java после C++ этого полностью хватает.

  5. Java Network Programming . Elliotte Rusty Harold . Книга довольно бестолковая, тем не менее это лучшее что я нашел по сетям в Java. Читать не стоит, а пролистать — очень даже.

  6. Java Concurrency in Practice. Brian Goetz, … . Аналогично предыдущей. Читать много и муторно, но пролистать надо.

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

Java + Ant + сетевой диск

Java – наверное самая уродская платформа из всех, с какими я имел дело. Ну и Ant не дальше ушел.
Итак, дано: Linux, сетевой диск с парой гагабай исходников, ant, java, gcc. Простейшая команда ant clean приводит к исключению java.lang.OutOfMemoryError. Перепробовал все найденные в интернете способы изменения объема используемой памяти и прочих шаманских действий – не помогает.
Стал эксперементировать дальше, выяснил, что падает только на сетевых шарах(!!!). Скопировал локально – полет нормальный. Спрашиватся, ну какого хера ошибка OutOfMemoryError, а не что-то подходящее в данной ситуации?!
Вобщем, осталось только процесс копирования автоматизировать.

Альтернативы

Открыл для себя древнюю, но крайне полезную утилитку update-alternatives. Эта утилитка просто незаменима если приходится работать c кривыми не совсем удачными сборочными файлами.
Небольшой пример. У нас есть куча проектов, которые необходимо собирать разными JDK. Что-то собирается при помощи 1.5, что-то 1.6 и вообще ничего нельзя собрать OpenJDK. При переключении с проекта на проект надо либо каждый раз пересоздавать линки на нужный компилятор, либо можно воспользоваться update-alternatives. Continue reading →

Что не так с Java?

Меня долгое время мучил вопрос, почему приложения на Java такие тормозные? Если верить синтетическим тестам на The Computer Language Benchmarks Game, то в среднем приложения на Java работают всего-то в 2 раза медленнее при использовании памяти в 10 раз больше по отношению к C++ приложениям. В принципе, это не такой уж и большой разрыв. Хотя в этих тестах нет приложений на Objective-C, я думаю что результат для был-бы приблизительно тем же, ну может памяти тратилось бы не в 10, а в 5 раз больше, а ведь c приложениями на Objective-C можно нормально работать. Так в чем же дело?

Ответ пришел нежданно-негаданно. Заинтересовавшись Andoid, а как всем известно, приложения для него пишутся именно на Java, я похоже наткнулся на ответ. Как это ни печально, дело в программистах. Разработчики Java живут в мире неограниченных ресурсов – бесконечной памяти, бесконечного дискового пространства и бесконечной производительности процессора. И в результате мы имеем очень сильное усложнение ПО с потерей производительности в угоду читабельности и простоты разработки. И если такая стратегия работает для корпоративного ПО, где пользователь будет работать с тем что ему дали (как бы то г-но что ему дали не работало), а мощность серверов действительно высока, то десктопное ПО, и уж тем более мобильно ПО начинает сталкиваться с серьезными проблемами.

Изучая примеры Open Source приложений под Android просто диву даешься, насколько безграмотно они написаны с точки зрения ограничения используемых ресурсов. Куча бесполезных абстракций, нагромождение паттернов (привет не понимаю зачем была создана GoF) и совершенно бездумное использование памяти. Достаточно показательный момент – основные советы разработчикам под Android сводятся к тому, что надо плодить меньше сущностей, больше думать о сложности используемых алгоритмов и менее фанатично относиться к ООП. Создается ощущение что появление GC, упрощение разработки и отдаление от проблем среды исполнения вызвало сильнейшую деградацию разработчиков.

Одно радует, теперь понятно почему на десктопах количество приложений написанных на C# или Java ничтожно мало