LINUX.ORG.RU

Java SE 6 Performance White Paper


0

0

Представлен сравнительный обзор показателей производительности и улучшений в масштабируемости Java стандартной версии 6 (Update 2) в сравнении с предыдущей версией платформы Java 5.0.

Java SE 6 включает несколько новых функций и усовершенствований для повышения производительности во многих частях платформы. Улучшения включают:

  • синхронизованные оптимизации выполнения, оптимизации производительности компилятора;
  • новый параллельный уплотняющий сборщик мусора (Parallel Compaction Collector);
  • более эргономичный параллельный низколатентный сборщик мусора (Concurrent Low Pause Collector);
  • ускорение запуска приложений.
Сравнение современной версии Java SE 6 Update 2 ведётся с предыдущей версией платформы -- Java SE 5 FCS.
Так, например, производительность операций ввода-вывода Java 6 в два раза выше, чем у Java 5.0; производительность корпоративных систем по тесту SPECjbb2005 Benchmark возросла на 70%; производительность Java в популярном тесте VolanoMark Benchmark выросла более чем на 40%; скорость запуска приложений увеличилась на 15-20%.

Также приводятся ссылки на материалы, посвящённые отдельным оптимизациям и тестам. В частности, интерес представляет отимизация сборки мусора и уменьшения потребления памяти в отдельной статье "Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning":
http://java.sun.com/javase/technologi...

Другие ссылки приведены по ходу обзора и в его конце.

>>> Подробности

Ответ на: комментарий от NonHuman

Да ты сам походу еще не определился с ориентацией.
То говоришь лучше заменить java на скрипты, то час от этих слов отказываешься.
Иди проспись лучше. Бздун
>Что легче поддерживать 100mb Java кода или 30mb SQL скриптов?
Поддерживать легче то, на что не поленились сделать вменяемую документацию.
>Мои симпатии на стороне Java.
Мля какие еще у тебя симпатии если ты уже от java предложил отказаться.
NonHuman ** (*) (19.11.2007 21:59:28)
> Это спор, по типу
Иди проспись, а то либо пишешь не думая, либо пишешь но то что думаешь.

ilnurathome
()
Ответ на: комментарий от ilnurathome

Да, ещё один юродивый.
Документацию на 100Мб Java я видел.
А ты хоть можешь представить документацю на 30мб SQL скриптов?

>То говоришь лучше заменить java на скрипты, то час от этих слов отказываешься.
Где я отказываля от своих слов? Хоть бы брехать научился, хоть бы доводы привёл. Тупое, бессмыссленное враньё.

>Мля какие еще у тебя симпатии если ты уже от java предложил отказаться.
Мозг видимо атрофировался... Не можешь понять простой вопрос? Какая связь между тем, что я предложил заменть Java на скриптовый язык в случае, если производительность не играет роли
и моим вопросом:
>Что легче поддерживать 100mb Java кода или 30mb SQL скриптов?
Объясни, плиз.
Или непрадиционная организация мышления непозволяет?

>пишешь не думая, пишешь но то что думаешь.
:))))))))))) не понял. Это Дзэн?

NonHuman ★★★
()
Ответ на: комментарий от NonHuman

NonHuman просто убей себя апстену для общества будет лучше
чем компасировать всем мозги призывом отказаться от jee и java и писать "на скриптовом языке и сэкономить на поддержке"

ilnurathome
()
Ответ на: комментарий от ilnurathome

Хахахах....
Прослезился...
Так как я равнодушен к обществу людей с нетрадищионной сексуальной ориентацией, испытывающих влечение к неодушевлённым сущностям, мне насрать на вас и на общество вам подобных.

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

NonHuman ★★★
()
Ответ на: комментарий от gaa

> Без j2ee можно обойтись, несмотря и вопреки всем Вашим "проспись", "убей себя" и т.д.
Так как с NonHuman бесполезно общаться он сам не знает чего хочет, то надо отказаться от java, то спрашивает, что лучше 100мег java или 30 мег sql. (Иногда если применяется объектно-реляционный подход понять что присходит в базе легче чем в кривом java приложении. все зависит от кривизны рук разработчиков.)

Что вы предлагаете взамен j2ee?
Скриты сразу не подходят для обработки больших массивов. Несмотря на мои теплые чувства к perl или python, ИМХО не подходят они для задач скажем анализа данных, где слишком большие объемы.

Что остается только нативные языки?

ilnurathome
()
Ответ на: комментарий от ilnurathome

s/Что вы предлагаете взамен j2ee? / Что вы предлагаете взамен j2ee? И обработки данных на стороне сервера ДБ?

ilnurathome
()
Ответ на: комментарий от ilnurathome

> Что вы предлагаете взамен j2ee?

Прямо так в общем случае и расписать? Увы, панацей не существует.

> Скриты сразу не подходят для обработки больших массивов.

Почему, очень даже подходят. Например тем, что можно обрабатывать массив последовательно(mysql $query | grep hedgehog), а не вытягивать сразу весь список результатов, а потом по нему ходить(em.createQuery(query).getResultList). Или я что-то пропустил и в j2ee появились серверные курсоры?

> Несмотря на мои теплые чувства к perl или python, ИМХО не подходят они для задач скажем анализа данных, где слишком большие объемы.

Если Вам надо быстро проанализировать большие данные, не стоит ли обратиться к нативным языкам? java, подозреваю, на огромных объёмах данных с нетривиальной обработкой будет тормозить не слабее того же перла

gaa ★★
()
Ответ на: комментарий от gaa

> mysql $query | grep hedgehog

и не надо мне орать, что я не знаю про WHERE :)

gaa ★★
()
Ответ на: комментарий от gaa

> Если Вам надо быстро проанализировать большие данные, не стоит ли обратиться к нативным языкам? java, подозреваю, на огромных объёмах данных с нетривиальной обработкой будет тормозить не слабее того же перла
Нативные языки подходят (и вообщем-то следует признать, что лучший вариант, но только) если твоя программа работает только внутри фирмы или ограниченном круге, стоит тебе начать ее распространять, как начинаешь спотыкаться. Один под линукс другой под виндоус, третий под солярис, а если у него aix.
Это под все платформы надо делать бинарники, а где тестировать. Это все возможное оборудование надо сначала скупить? А что больше делать нечего? Уж лучше потратить свободное от тестирования на все возможном железе на оптимизацию алгоритма. Ведь часто уже только зачет улучшения алгоритмов, можно существенно повысить производительность.
Или как вы предлагаете?

ilnurathome
()
Ответ на: комментарий от ilnurathome

/s/потратить свободное от тестирования/потратить свободное время от тестирования

ilnurathome
()
Ответ на: комментарий от ilnurathome

> Это под все платформы надо делать бинарники, а где тестировать.

В любом случае надо тестировать под все платформы. Как минимум на всех системах придётся обкатывать инсталлятор. Да и неплохо бы иметь представления о том, что на всех платформах работает одинаково хорошо, а не случается такой ситуации, что летает на window$/i386, и тормозит на solaris/sparc64.

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

> Уж лучше потратить свободное от тестирования на все возможном железе на оптимизацию алгоритма.

Может оказаться, что нативный алгоритм не надо будет оптимизировать ;)

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

gaa ★★
()
Ответ на: комментарий от NonHuman

> Советую посмотреть на Spring. весьма популярный контэйнер. Достаточно интересны так-же AspectJ и Pico

Не совсем понял, к чему это было сказано...

gaa ★★
()
Ответ на: комментарий от gaa

>Например тем, что можно обрабатывать массив последовательно(mysql $query | grep hedgehog), а не вытягивать сразу весь список результатов, а потом по нему ходить(em.createQuery(query).getResultList). Или я что-то пропустил и в j2ee появились серверные курсоры?

Вообще-то, серверные курсоры никогда из JEE и не исчезали - их поддержка есть в JDBC.

В Hibernate тоже есть поддержка в рамках StatelessSession.

>Если Вам надо быстро проанализировать большие данные, не стоит ли обратиться к нативным языкам?

Не стоит. Разница в скорости будет _максимум_ раза в два. А трудозатраты различаться будут раз в 5 минимум.

>java, подозреваю, на огромных объёмах данных с нетривиальной обработкой будет тормозить не слабее того же перла

Сама по себе Java тормозить не может. Могут тормозить реализации алгоритмов. При прочих равных - Перл сливает, причем сильно сливает из-за отсутствия нормального GC (там ссылки считают и на циклах объектов все загибается).

anonymous
()
Ответ на: комментарий от anonymous

> Вообще-то, серверные курсоры никогда из JEE и не исчезали - их поддержка есть в JDBC. В Hibernate тоже есть поддержка в рамках StatelessSession.

Примерчик для hibernate можно?

> Не стоит. Разница в скорости будет _максимум_ раза в два. А трудозатраты различаться будут раз в 5 минимум. Сама по себе Java тормозить не может. Могут тормозить реализации алгоритмов. При прочих равных - Перл сливает, причем сильно сливает из-за отсутствия нормального GC (там ссылки считают и на циклах объектов все загибается).

Ох уж эти объектноориентированные жабисты... Советую вылезти из танка, осмотреться и увидеть, что не для всех задач нужно ООП. Соответственно и преимущества жабы уходят, а вот ооп-мусор остаётся. Представьте, например, что в базе лежат некоторые данные, для которых надо провести статистический анализ.

gaa ★★
()
Ответ на: комментарий от gaa

>а не вытягивать сразу весь список результатов, а потом по нему ходить(em.createQuery(query).getResultList).

Каменный век, 20000 лет до нашей эры. Поручик Ржевский, где вы набрались такого, сейчас даже в школах рабочей молодежи так не учат. Строишь QueryObject, и БД тебе выборку отрабатывает. САМА.

>а не случается такой ситуации, что летает на window$/i386, и тормозит на solaris/sparc64.

Java гарантирует оптимизации для каждой target-платформы. Для сопли свои, для икс86 свои. А такой код на C, который будет летать и на сопле и на икс86 ты напишешь за очень большое время->очень дорого

anonymous
()
Ответ на: комментарий от anonymous

>> а не вытягивать сразу весь список результатов, а потом по нему ходить(em.createQuery(query).getResultList).

> Строишь QueryObject, и БД тебе выборку отрабатывает. САМА.

наконец-то дельный пример!

>>а не случается такой ситуации, что летает на window$/i386, и тормозит на solaris/sparc64.

> Java гарантирует оптимизации для каждой target-платформы. Для сопли свои, для икс86 свои.

Не читайте на ночь маркетинговых сказок. Может для ынтырпрайз-проекта уровня "хелл оф ворлд" разницы в быстродействии и нет, а вот потом она проявляется. Знаете-ли, разные платформы(ос/процессор/база данных) работают по-разному, разные настройки и твики имеют.

> А такой код на C, который будет летать и на сопле и на икс86 ты напишешь за очень большое время->очень дорого

Прежде чем придираться, советую прочитать более одного сообщения в теме. Хотя чего ждать от анонимуса...

gaa ★★
()
Ответ на: комментарий от gaa

> осмотреться и увидеть, что не для всех задач нужно ООП.

Не надо путать Java и ООП. Например, примитивные типы, массивы и финальные методы - это совсем не ООП.

dave ★★★★★
()
Ответ на: комментарий от gaa

>Примерчик для hibernate можно?

http://www.hibernate.org/hib_docs/reference/en/html/batch.html - ищи по слову StatelessSession.

>Ох уж эти объектноориентированные жабисты... Советую вылезти из танка, осмотреться и увидеть, что не для всех задач нужно ООП.

Причем тут ООП? Ты видел, чтобы я где-то сказал хоть слово о паттернах или объектной декомпозиции?

>Соответственно и преимущества жабы уходят, а вот ооп-мусор остаётся. Представьте, например, что в базе лежат некоторые данные, для которых надо провести статистический анализ.

Представил. У меня подобные задачи были - я не вижу в чем у меня должны быть фундаментальные трудности.

anonymous
()
Ответ на: комментарий от gaa

> Ох уж эти объектноориентированные жабисты...
Чет не понял, а что у перла и питона или у руби уже отменили возможности для ООП. С такой логикой их тоже получается на свалку надо, а также все языки которые так или иначе потдерживают ООП. А как же ваше предложение писать на скриптах? Противоречие на лицо.
В итоге у вас остается только C etc?

Причем тут ООП вообще? не вижу логики.

ilnurathome
()
Ответ на: комментарий от anonymous

> Причем тут ООП? Ты видел, чтобы я где-то сказал хоть слово о паттернах или объектной декомпозиции?

вот причём: цитата: "Перл сливает, причем сильно сливает из-за отсутствия нормального GC (там ссылки считают и на циклах объектов все загибается)." Как получить проблемы с распределением памяти без использования ООП я не знаю.

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

> У меня подобные задачи были - я не вижу в чем у меня должны быть фундаментальные трудности.

Трудностей нет. Но в чём тут преимущество Java над perl или даже awk?

gaa ★★
()
Ответ на: комментарий от gaa

Да и вообще, "объектноориентированные жабисты" - это для меня синоним просто жабистам. Если Вам так приятнее, то читайте "Ох уж эти жабисты"

gaa ★★
()
Ответ на: комментарий от gaa

>вот причём: цитата: "Перл сливает, причем сильно сливает из-за отсутствия нормального GC (там ссылки считают и на циклах объектов все загибается)." Как получить проблемы с распределением памяти без использования ООП я не знаю.

Мда. Детский сад, ясельная группа. Берешь тупое дерево, в котором в узлах есть ссылки на родительский узел - и всё, приехали. Кольцевые ссылки и утечка памяти в Perl'е. Ну или еще проще: double-linked list.

> Трудностей нет. Но в чём тут преимущество Java над perl или даже awk?

С AWK Java даже сравнивать смешно. Возможности на пару-тройку порядков отличаются.

anonymous
()
Ответ на: комментарий от anonymous

>> вот причём: цитата: "Перл сливает, причем сильно сливает из-за отсутствия нормального GC (там ссылки считают и на циклах объектов все загибается)." Как получить проблемы с распределением памяти без использования ООП я не знаю.

> Берешь тупое дерево, в котором в узлах есть ссылки на родительский узел - и всё, приехали. Кольцевые ссылки и утечка памяти в Perl'е. Ну или еще проще: double-linked list.

Узел дерева - не объект? Лист - не объект? И прям таки в каждой задаче нужны сложные структуры данных?

>> Трудностей нет. Но в чём тут преимущество Java над perl или даже awk?

> С AWK Java даже сравнивать смешно. Возможности на пару-тройку порядков отличаются.

А в рамках задачи "проанализировать кучу вещественных чисел(например, найти среднее геометрическое)"?

Я не спорю, что java - монстр на котором можно написать всё. Но не в каждой задаче нужны все его возможности. Даже так: есть ли хоть одна задача, требующая все возможности жабы?

gaa ★★
()
Ответ на: комментарий от anonymous

> Берешь тупое дерево, в котором в узлах есть ссылки на родительский узел - и всё, приехали. Кольцевые ссылки и утечка памяти в Perl'е. Ну или еще проще: double-linked list.

Короче говоря, структура данных "граф". Подразумевает циклы, рекурсию и прочие прелести жизни.

dave ★★★★★
()
Ответ на: комментарий от gaa

>Узел дерева - не объект? Лист - не объект? И прям таки в каждой задаче нужны сложные структуры данных?

Нет, не обязательно объект. Достаточно голой структуры данных (без методов). В общем, RTFM Lisp.

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

>А в рамках задачи "проанализировать кучу вещественных чисел(например, найти среднее геометрическое)"?

Ты еще предложи их в качестве задачи сложить. Среднее геометрическое (арифметическое, квадратичное отклонение и т.п.) считаются прямо в виде запросов к базе.

>Я не спорю, что java - монстр на котором можно написать всё. Но не в каждой задаче нужны все его возможности. Даже так: есть ли хоть одна задача, требующая все возможности жабы?

Есть ли задача, требующая все возможности AWK, включая backreference'ы в regex'ах? Нет? Значит, AWK не нужен и идет фтопку.

Твоя же логика.

anonymous
()
Ответ на: комментарий от dave

>Короче говоря, структура данных "граф". Подразумевает циклы, рекурсию и прочие прелести жизни.

Если быть точным - направленый граф объектов с циклами.

Рекурсия, кстати, тут ни при чем.

anonymous
()
Ответ на: комментарий от anonymous

> В общем, ничерта ты настоящие программы не писал. И писал в последний раз в школе на Паскале.

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

gaa ★★
()
Ответ на: комментарий от anonymous

Рекурсия заключена в самой математической сущности этих объектов. То есть, она присутсвует всегда по определению. Но это не значит, что методы должны быть рекурсивными. Есть прекрасный пример "правопоточных" (right-threaded) деревьев для одностороннего обхода :)

dave ★★★★★
()
Ответ на: комментарий от dave

Многие доказательства для графов делаются по индукция. Вот, это и есть проявление рекурсивной сущности.

dave ★★★★★
()
Ответ на: комментарий от gaa

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

Мой email и ник на RSDN в этой теме я написал (Cyberax, Alex.Besogonov _на_ gmail _точка_ com). Хочешь померяться знаниями - добро пожаловать на форум "Священные войны" на RSDN.

Но с твоими утвержденяими, что циклы в графах - это удел только ООП, я что-то сомневаюсь, что ты там появишься.

anonymous
()
Ответ на: комментарий от anonymous

> Но с твоими утвержденяими, что циклы в графах - это удел только ООП, я что-то сомневаюсь, что ты там появишься.

Я такого не утверждал, не надо мне приписывать свои домыслы. А на RSDN я действительно ходить не собираюсь.

gaa ★★
()
Ответ на: комментарий от anonymous

Если быть точным, то наш коллега полагает, что такая сложная структура данных как циклические графы - это удел энтерпрайзных аппликух. Может быть, и так. Тогда это тешило бы мое самолюбие, поскольку в нашем приложение столько графов, и на самых разных уровнях... вычислительные графы, графы графических объектов и прочая :)

dave ★★★★★
()
Ответ на: комментарий от dave

> Если быть точным, то наш коллега полагает, что такая сложная структура данных как циклические графы - это удел энтерпрайзных аппликух.

Увы и ах, приставка "ынтырпрайз" относилась опять же к java.

gaa ★★
()
Ответ на: комментарий от gaa

>Я такого не утверждал, не надо мне приписывать свои домыслы.

Это твои слова: "Узел дерева - не объект? Лист - не объект? И прям таки в каждой задаче нужны сложные структуры данных?" ?

>А на RSDN я действительно ходить не собираюсь.

Так ничего другого я не ожидал..

anonymous
()
Ответ на: комментарий от anonymous

>> Я такого не утверждал, не надо мне приписывать свои домыслы.

> Это твои слова: "Узел дерева - не объект? Лист - не объект? И прям таки в каждой задаче нужны сложные структуры данных?" ?

Мои. И каким боком из них следует "что циклы в графах - это удел только ООП"? Я, конечно, догадываюсь, что это выведено через lisp, т.к. слово "lisp" проскакивало, да вот только perl, awk, shell или tcl - это немного не lisp.

Ещё я краем глаза заметил, что меня записали в ООП-ненавистники("Чет не понял, а что у перла и питона или у руби уже отменили возможности для ООП. С такой логикой их тоже получается на свалку надо, а также все языки которые так или иначе потдерживают ООП."), правда это был уже не анонимус. Это не так. Но глупо использовать ООП ради ООП я не намерен.

gaa ★★
()
Ответ на: комментарий от gaa

> perl, awk, shell или tcl - это немного не lisp.

"Tcl is Lisp on drugs" (c) 8)

tailgunner ★★★★★
()
Ответ на: комментарий от gaa

>Мои. И каким боком из них следует "что циклы в графах - это удел только ООП"? Я, конечно, догадываюсь, что это выведено через lisp, т.к. слово "lisp" проскакивало, да вот только perl, awk, shell или tcl - это немного не lisp.

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

anonymous
()
Ответ на: комментарий от anonymous

> Какие еще есть возражение про отстойную систему управления памятью в Perl?

Никаких. Я вообще не перловод, так что не разбираюсь, какие там проблемы с памятью.

Так в чём всё-таки преимущество java при последовательной обработке данных из базы перед любым другим языком, в т.ч. скриптовым?

gaa ★★
()
Ответ на: комментарий от gaa

>Никаких. Я вообще не перловод, так что не разбираюсь, какие там проблемы с памятью.

Ну вот. Т.е. советуешь то, о чем сам нормально не знаешь.

>Так в чём всё-таки преимущество java при последовательной обработке данных из базы перед любым другим языком, в т.ч. скриптовым?

"Обработка бывает разная: черная, белая, красная..." (c) почти песня.

Суть в том, что тупой обработки типа "выбрать все ряды, а потом пройтись по ним grep'ом" я в нормальных приложениях еще не видел. Это обычно делается сразу внутри БД средствами самой БД.

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

Но даже и сложная потоковая обработка (обычно это нужно для составления отчетов) в большинстве случаев - это лишь часть приложения.

Ты никогда не задумывался откуда беруться данные, чтобы их потом обрабатывать?

anonymous
()
Ответ на: комментарий от anonymous

>> Никаких. Я вообще не перловод, так что не разбираюсь, какие там проблемы с памятью.

> Ну вот. Т.е. советуешь то, о чем сам нормально не знаешь.

Перл появился в дискуссии не от моего имени.

>> Так в чём всё-таки преимущество java при последовательной обработке данных из базы перед любым другим языком, в т.ч. скриптовым?

> Суть в том, что тупой обработки типа "выбрать все ряды, а потом пройтись по ним grep'ом" я в нормальных приложениях еще не видел. Это обычно делается сразу внутри БД средствами самой БД.

А если нет нужных функций в БД? Приведу уж совсем высосанный из пальца пример: БД отдаёт координаты точек комплексной плоскости, над ними проводятся некоторые итерации до тех пор, пока число по модулю не превысит заданное, а количество шагов запоминается. Этакий фрактал Мандельброта.

> А для сложной обработки - есть все преимущества Java (статическая типизация, лучшие в мире IDE, куча тулзов).

Смешно. Давно IDE стал частью языка? Надеюсь, Вы не из тех людей, которые превозносят сишарп из-за того, что им удобно работать в ms vs?

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

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

gaa ★★
()
Ответ на: комментарий от gaa

>А если нет нужных функций в БД? Приведу уж совсем высосанный из пальца пример: БД отдаёт координаты точек комплексной плоскости, над ними проводятся некоторые итерации до тех пор, пока число по модулю не превысит заданное, а количество шагов запоминается. Этакий фрактал Мандельброта.

Нет функции - добавляем: http://www.postgresql.org/docs/current/static/sql-createfunction.html , в Oracle, MySQL, Firebird, Sybase, DB2 - есть аналогичные вещи. Ну и ради такого случая можно и на [b]JIT-компилируемой[/b] Java написать код, если скорости хранимок (сравнимой со скоростью стандартных скриптов) не хватает.

>> А для сложной обработки - есть все преимущества Java (статическая типизация, лучшие в мире IDE, куча тулзов). >Смешно. Давно IDE стал частью языка? Надеюсь, Вы не из тех людей, которые превозносят сишарп из-за того, что им удобно работать в ms vs?

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

>Данные можно засовывать в базу хоть жавой. Я не брезгую пользоваться разными языками для разных частей задачи.

Текущее мое приложение: 830 таблиц, в общей сложности 6175 столбцев. Как будем данные пихать-с?

Или писать систему сбора данных на Java, графический клиент на Java, веб-клиент на Java, отчеты на Java, и непонятные "фильтры" с помощью awk? Самому не смешно?

anonymous
()
Ответ на: комментарий от anonymous

>> А если нет нужных функций в БД?

> Нет функции - добавляем:... Ну и ради такого случая можно и на [b]JIT-компилируемой[/b] Java написать код, если скорости хранимок (сравнимой со скоростью стандартных скриптов) не хватает.

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

>>> А для сложной обработки - есть все преимущества Java (статическая типизация, лучшие в мире IDE, куча тулзов).

>>Смешно. Давно IDE стал частью языка? Надеюсь, Вы не из тех людей, которые превозносят сишарп из-за того, что им удобно работать в ms vs?

> Во-первых, где я утверждал, что IDE - это часть языка?

Оно упоминалось как преимущество java. Интересно, чем преимущество IDE отражается на конечном продукте? Да и тулзы, которые используются в разработке для конечного пользователя не видны.

> Во-вторых, так уж получилось, что для Java сейчас самые лучше IDE (почему так получилось - другой вопрос). И вот это само наличие IDE является плюсом при выборе Java.

Это не плюс языка java или платформы java. Это скорее минус: для отладки приложения оказывается недостаточным ясности, которую даёт язык и приходится использовать дебаггер.

>Данные можно засовывать в базу хоть жавой. Я не брезгую пользоваться разными языками для разных частей задачи.

> Текущее мое приложение: 830 таблиц, в общей сложности 6175 столбцев. Как будем данные пихать-с?

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

> Или писать систему сбора данных на Java, графический клиент на Java, веб-клиент на Java, отчеты на Java, и непонятные "фильтры" с помощью awk? Самому не смешно?

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

Единственное преимущество java перед другими языками, которое я вижу - только то, что можно нанять десяток легкозаменяемых обезъянок, которые знают java и только её и заставить их написать.

gaa ★★
()
Ответ на: комментарий от anonymous

>Текущее мое приложение: 830 таблиц, в общей сложности 6175 столбцев. Как будем данные пихать-с?

Позволь поинтересоваться, это ТВОЕ приложение, ты сам, один пишешь столько? Или просто участвуешь в команде? Тогда проще, можно несколько таблиц одному разрабу отдать, несколько другому

anonymous
()
Ответ на: комментарий от anonymous

> Позволь поинтересоваться, это ТВОЕ приложение, ты сам, один пишешь столько? Или просто участвуешь в команде? Тогда проще, можно несколько таблиц одному разрабу отдать, несколько другому
При коммандной игре ИМХО лучше сразу определить все правила как писать и на чем писать, а то потом тяжко будет спровождать, если среди участников "текучка" начнется или ключевые моменты захотят переделать.

ilnurathome
()
Ответ на: комментарий от gaa

>Да пишите сколько влезет. Но зачем использовать комбайн вместо узкоспециализированного языка - непонятно.

Так проблема со скриптами типа AWK - как раз в их узкой специализации. А если писать что-то серьезное (например, на Python) - то вылезут уже другие проблемы (необходимость стыковки с основной системой и т.п.)

>Оно упоминалось как преимущество java. Интересно, чем преимущество IDE отражается на конечном продукте? Да и тулзы, которые используются в разработке для конечного пользователя не видны.

Преимущество выражается в том, что с хорошей IDE программисты более продуктивны (у меня есть для этого статистика по моим проектам). Для пользователя это значит: а) более быстрое внесение изменений, б) лучшее качество продукта.

>Это не плюс языка java или платформы java. Это скорее минус: для отладки приложения оказывается недостаточным ясности, которую даёт язык и приходится использовать дебаггер.

Причем тут дебаггер? Посмотри на досуге IntelliJ IDEA. Статические инспекции и рефакторинг оттуда - просто killer features.

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

А я вижу. Ради узкой задачи мне придется решать проблемы с подключением еще одного языка. На кой мне это надо, если то же самое я могу сделать кодом на Java?

Да, его будет в 3 раза больше по объему. Да, это будет тупой код. Но его будет НЕМНОГО в абсолютном масштабе проекта.

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

>Единственное преимущество java перед другими языками, которое я вижу - только то, что можно нанять десяток легкозаменяемых обезъянок, которые знают java и только её и заставить их написать.

Это фантастика. Обезьянки могут работать над какими-нибудь тупыми задачами типа составления отчетов в Crystal Report (где они даже теоретически не могут навредить остальным). Но стоит их допустить к основному коду - и проект начинает лететь вниз.

Кстати, почему ты считаешь кодеров на каком-нибудь AWK/Python априори НЕ обезьянами?

anonymous
()
Ответ на: комментарий от anonymous

>Позволь поинтересоваться, это ТВОЕ приложение, ты сам, один пишешь столько? Или просто участвуешь в команде? Тогда проще, можно несколько таблиц одному разрабу отдать, несколько другому

Сначала я его писал как один из команды, потом стал архитектором.

Все таблицы поименно я, конечно, не знаю - но общую организацию модулей и принципы работы каждого модуля я прекрасно понимаю.

Кстати, в этом еще очень сильно ORM помогает, но это уже другой разговор...

anonymous
()
Ответ на: комментарий от anonymous

>> Позволь поинтересоваться, это ТВОЕ приложение, ты сам, один пишешь столько? Или просто участвуешь в команде? Тогда проще, можно несколько таблиц одному разрабу отдать, несколько другому

> Сначала я его писал как один из команды, потом стал архитектором.

Не смеши, Архитектор. Может на rsdn такие штучки и прокатывают, но тут нет. На ЛОРе все равны, а хвальба тем, что нельзя проверить не поощряется.

P.S. учи эквивалентные бесконечно малые

gaa ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.