Демо: использование Eclipse & Java-GNOME

Народ, не то чтото с этим роликом. примерно когда показывают как реально код писать, firefox начинает жрать 100% проца, а минут через 5 кернел вообще пише "Out of Memory, Killed process 1145 - firefox-bin"

Таки сан впрыгивает в уходящий поезд.

Ктобы мог подумать, что гну опенсорс даст возможность выживать этому монстру.

Эээ... наверное это линукс?

>Ктобы мог подумать, что гну опенсорс даст возможность выживать этому монстру.

Я. ;-) Год назад я писал, что единственный шанс жабы на второе дыхание - это gjc. Но это о выживании жабы. А вот выживет ли Сан - я не уверен. Да и неинтересно это.

s/gjc/gcj, конечно же.

а почему бы и нет? чем этот монстр хуже других, цепляющихся за спасательный круг опенсорса? ;-)

Вау, вот он - Visual Studio для Linux. Но флэш ролик зае314сь - аж 10 метров в холке.

>Вау, вот он - Visual Studio для Linux

Ага - только vs (шестой ессесно) - не так тормозит... Может у меня тачка конечно не очень (1200AthlonThunderbird 256Ram) - но с эклипсом работать просто невозможно... все с какими-то раздражающими задержками, напечатанный текст появляеться после где-то секунды... И ладно бы только это - у меня и покруче косяки бывали - запустишь проект из-под консоли - все ок , а в эклипсе - глючит (правда это не с жабой было, а с перловым плагином - какая-то хрень там у меня выходила с переменными окружения... но поскольку он меня уже дико бесил после дня работы с ним - я даже разбираться не стал - я что-то не настроил, или баг - просто стер его нафиг) в общем фтоппку... вим рулит!!!

Это он под лялихом тормозит, под Win32 все окей :)

>Я. ;-) Год назад я писал, что единственный шанс жабы на второе дыхание - это gjc.

ИМХО, бред. Что Java от этого приобретет? Потеряет JIT и, что еще обиднее, HotSpot?

Было бы полезнее, если бы они байт-код побогаче сделали бы.

>какая-то хрень там у меня выходила с переменными окружения... что-то не настроил, или баг - просто стер его нафиг)
не настроил. переменные надо было прописывать для всей X-сессии т.к. bash запущенный как шел локальные профили не читает, к примеру для гнома это делается в .gnomerc

>не настроил. переменные надо было прописывать для всей X-сессии т.к. bash запущенный как шел локальные профили не читает, к примеру для гнома это делается в .gnomerc

Ага - и переменную $ENV{ 'HOME' } - он тоже должен показывать как undef???

P.S. - у меня не гном, к тому-же иксы запускаються не с помощью gdm/kdm/xdm - а простой записью в .bash_profile строчки if [ ! -f /tmp/.X0-lock ]; then xinit fi - так что с переменными все в порядке.

> к тому-же иксы запускаються не с помощью gdm/kdm/xdm - а простой записью в .bash_profile

А вот это - не запускать xdm - неправильно.

Жаль только что это будет работать только на продуктах от RedHat,
и чтоб прикрутить это к примеру к SUSE или Mandrake придется поработать напильником.
А лично мне нравится писать на Pure Java,
а потом отдовать клиентам, и программа будет одинаково хорошо работать какая бы не была ОС у пользователя и без дополнительных настроек.

Совершенно не понятно чем им SWT не угодила. лучше бы уж потратили время и деньги на доработку SWT/GTK а тормозит так что начинаешь задумываться что тормозит именно GTK :)

PS. Если сравнивать VS + C# и Eclipse + Java то пробукция MS магко говоря отдыхает :) просто есть опфт одновременного использования в разных проектах.

> Я. ;-) Год назад я писал, что единственный шанс жабы на второе дыхание - это gjc. Но это о выживании жабы. А вот выживет ли Сан - я не уверен. Да и неинтересно это.

И попали пальцем в небо.

Java - это Cobol нового века. Язык, позволяющий быстро и качественно делать BP/TP automation. Особенно с учетом J2EE, а так же решений сторонних производителей (Hibernate, апачевские решения и т.д.).

От других решений, направленных на тот же сегмент, Java и всю линейку связанных технологий отличает именно прямота. По-крайней мере, ошибок уровня студента-стажера, коих так много в .NET Framework в этих API исчезающе мало.

А всяких сопливых студентов я попрошу расслабиться. Java-программист - это отнюдь не всегда индус, кодящий по спецификации. Если мы говорим о серьезной индустрии, а не о вшивых оффшорах, то разработчик на Java - это как правило высококвалифицированный специалист, хорошо знающий предметную область, досконально знающий свой инструмент (Java, контейнеры, API, спецификации). Бывают, конечно, и дурни-кодеры, но, смею вас заверить, их намного больше в мире Delphi, 1С, VS и прочих виндовомайкросовых поделий.

ARia

>Совершенно не понятно чем им SWT не угодила. лучше бы уж потратили время и деньги на доработку SWT/GTK а тормозит так что начинаешь задумываться что тормозит именно GTK :)

А разве это не так?

>Это он под лялихом тормозит, под Win32 все окей :)

w2k P4-1700 512M - начиная с 3.01 с эклипс работать практически невозможно. Вроде и жрет для жабской приблуды немного максимум у меня было ~250М, а тормозит отвязно. Хотя может я просто VS-7.1 избалован...

> w2k P4-1700 512M - начиная с 3.01 с эклипс работать практически невозможно. Вроде и жрет для жабской приблуды немного максимум у меня было ~250М, а тормозит отвязно.

Дык хотите. чтобы все было быстро и безглючно, Emacs + JDE всегда к вашим услугам

ARia

>А разве это не так?

можно ли вас понять так, что если бы скажем гном был сляпан на жабе, то он работал бы быстрее/отжирал меньше ресурсов?

>>Это он под лялихом тормозит, под Win32 все окей :)

> w2k P4-1700 512M - начиная с 3.01 с эклипс работать практически невозможно. Вроде и жрет для жабской приблуды немного максимум у меня было ~250М, а тормозит отвязно. Хотя может я просто VS-7.1 избалован...

Зря это вы, мессир, про тормоза. Да, Эклипс не vi, но на приличной машине - вполне юзабельно.

Athlon 2.6Hz/512Mb, ASP 9.2, KDE, JDK 1.5.0, Eclipse 3.0.1 - 3 проекта, в сумме ~700-800 классов - Ok, ест ~70-80Mb.

P4, 2.4Hz/512Mb, WinXP, Eclipse 3.1M4, JDK 1.4.2 - 15-20 проектов, в сумме ~5-6 тыс. классов - Ok, ест ~120-150Mb.

AFAIK, наиболее критичен объем памяти. Если оной хватает, попробуйте запускать как $ECLIPSE_HOME/eclipse -vm $JAVA_HOME/bin/java -vmargs -Xmx256M

>>Совершенно не понятно чем им SWT не угодила. лучше бы уж потратили время и деньги на доработку SWT/GTK а тормозит так что начинаешь задумываться что тормозит именно GTK :)

> А разве это не так?

Скорее всего, тормоза на уровне SWT-шных оберток. По крайней мере, такое впечатление создалось после просмотра треда в эклипсовской багзилле, посвященного тормозам GTK-порта: https://bugs.eclipse.org/bugs/show_bug.cgi?id=76804

btw. ИМХО, под Линухом Эклипс, пущенный на JDK 1.5 работает заметно шустрее, чем под 1.4.х...

Всё нормально, поставь последний флеш-плугин.

> Дык хотите. чтобы все было быстро и безглючно, Emacs + JDE всегда к вашим услугам

вы уж там определитесь. А то, то знающий досконально не индус, то вдруг сразу emacs, чтобы безглючно :)

> вы уж там определитесь. А то, то знающий досконально не индус, то вдруг сразу emacs, чтобы безглючно :)

А в чем противоречие ?

ARia

> А в чем противоречие ?

в глюках :)

> в глюках :)

Ню ню, глюки они только у пользователей форточек бывают ;)))

ARia

>можно ли вас понять так, что если бы скажем гном был сляпан на жабе, то он работал бы быстрее/отжирал меньше ресурсов?

Нет, я такого не говорил. ИМХО, в связке SWT/GTK тормозит именно GTK. Вот что я имел ввиду. SWT/Motif работает на порядок шустрее (хотя и без фич GTK).

> ИМХО, в связке SWT/GTK тормозит именно GTK.

Или отдельно взятый gtk-шный engine. Если сравнить какую-нибудь разукрашенную Ana с артом в больших xml^H^H^H svg и простой thinice - разница будет в разы.

тормозит сама связка swt-gtk, вот шустрая но еще не стабильная альтернатива: http://swtfox.sourceforge.net/

>>единственный шанс жабы на второе дыхание - это gcj.

>ИМХО, бред. Что Java от этого приобретет? Потеряет JIT и, что еще обиднее, HotSpot?

Зачем нужен JIT, да и HotSpot, если ты все компилишь до конца?

>Было бы полезнее, если бы они байт-код побогаче сделали бы.

Можно будет сделать всё. Но потеряется обратная совместимость...

>И попали пальцем в небо.

>Java - это Cobol нового века.

Вы противоречите себе, а не мне. Само собой, в том виде, в каком она сейчас, Java представляет собой Кобол. Пожалуй, даже очень хороший Кобол. Но, что же в этом хорошего? Вы знаете много людей писавших на коболе ПОСЛЕ 2000 года?

Если Java не будет развиваться, то она совершенно точно повторит судьбу Кобола. А сейчас, нет ничего более быстро эволюционирующего, чем открытый софт.

Так, что извините, Возвращаю вам ваши слова про пальцем в небо. ;-)

>Java-программист - это отнюдь не всегда индус, кодящий по спецификации.

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

>Зачем нужен JIT, да и HotSpot, если ты все компилишь до конца?

Марш читать про HotSpot! Ключевые слова: HostSpot, Smalltalk, можно еще добавить C++, performance.

HotSpot, например, может сделать такую штуку:

a) нет оптимизации:

p->func(); // виртуальный вызов, через таблицу (стандартное решение в C++)

b) набрали статистику, оптимизируем. Оказалось, что в этом коде в 90% случаев попадается FrequentClass:

if(p->getClass() == FrequentClass)) { p->FrequentClass::func(); // вызов напрямую } else { p->func(); // вызов через таблицу }

Оптимизация идет за счет того, что вызов через таблицу - жутко неоптимальная операция, поскольку процессор вынужден сбросить конвейер. В данном случае в 90% вызовов ему это делать не придется - ветвление неплохо предсказывается.

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

Впервые это было сделано для Smalltalk-а.

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

Так что единственное, что ты выиграешь - это время запуска (ну и время, уходящее на оптимизации/перекомпиляцииhttp://www.smalltalk.ru/articles/cpp-is-faster.html), зато проиграешь в скорости работы (при толковой реализации JIT/HotSpot). Потому как никаких принципиальных преимуществ у gcj нет, он не может сделать ничего такого, что не мог бы сделать JIT/HotSpot.

>Можно будет сделать всё. Но потеряется обратная совместимость...

Знаешь, у себя в гараже, конечно, много чего можно сделать... Но реальная поддержка Java - это IBM.

P.S. Вот, кстати, статья: http://www.smalltalk.ru/articles/cpp-is-faster.html

> Вы противоречите себе, а не мне. Само собой, в том виде, в каком она сейчас, Java представляет собой Кобол. Пожалуй, даже очень хороший Кобол. Но, что же в этом хорошего? Вы знаете много людей писавших на коболе ПОСЛЕ 2000 года?

Абсолютно необоснованное утверждение.

BTW, я таких людей знаю, их мало и они очень дефицитны.

Под Коболом в данном случае я подразумевал язык для бизнес-приложений. Честно говоря, мне сейчас представляется сомнительным, чтобы в ближайшее время какой-либо язык занял нишу Java. Вот оффтопик попытался, но с размаху сел в лужу, что и предсказывалось.

ARia

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

Абсолютно необоснованное утверждение. Аргументируйте plz. Какие именно языковые особенности Java позволяют это делать ?

ARia