Java полностью свободна под лицензией GPL

разработчики программ не хотят раздавать по GPL свои проги - в большинстве случаев. вот виндопользователи будут пользоваться ими, а мы - нет. или пускать их в Wine (как например foobar2000 и ImgBurn).

>The wxWindows Licence is essentially the L-GPL (Library General Public Licence)

НЕНАДО нам wx. насмотрелись на глюки VLC и amule.

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

> через 30 лет после возникновения накатали [полу]проприетарный кроссплатформенный (вроде бы реально с 4-ой версии) тулкит силами коммерческой компании. есть чем хвалиться языку

Я не хвалю плюсы. Я показываю, что утверждение из PR-истерики сана, которое ты бездумно повторял ("про перенос C/C++ программы с GUI с платформы на платформу вообще разговора нет"), на самом деле ложно.

Повторюсь... критикуй плюсы по делу -- я буду благодарный слушатель. А если хочется доказать "ява круче всех" -- не прокатит.

> правда кроссплатформенность ещё не используется реально насколько я понимаю. просто помогает портировать проги под unix.

и из под юникса (например vlc -- линукс, винда, мак). и на другие архитектуры -- например моя нокия 800. И почему-то весь гуек -- не ява...

>про перенос C/C++ программы с GUI с платформы на платформу вообще разговора нет

> НЕНАДО нам wx. насмотрелись на глюки VLC и amule.

Раз вы насмотрелись на глюки, так может быть речь "про перенос C/C++ программы с GUI с платформы на платформу" все-таки идет? Особенно в случае QT? И неважно, за бабло он или нет, но все-таки компилится на куче архитектур?

Или продолжим некритично подвыв^W повторять PR-истерику сана?

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

Sidrian (*) (21.06.2008 11:02:51)

Жаба выполняется стандартно путем компиляции в байткод, который затем интерпретиируется. Это по определению медленнее чем выполнение на процессоре. В современной жабе при выполнении байткода(методы типа jit компиляции) может происходить частичная компиляция кода (отдельных методов). Только откомпилированный код нигде не хранится и выбор метода происходит при каждом выполнении программы путем поиска наиболее часто используемых методов, что очень нерационально, тк тратится время процессора при каждом запуске программы на компиляцию. И кроме того тратится дополнительная память.

Странно что те, кто много лет разрабатывает эту технологию, не предусмотрели таких элементарных вещей. Распараллеливание это все фигня. Это важно может быть для серверов.

В результате джава с такими штуками всегда будет хуже по использованию ресурсов чем тот же С++. Вот и пишут все на С++, а не на джаве. Конечно джава сама по себе медленнее, но странно что такие вещи не предусмотрены. Я понимаю на мобильниках, где 100кб памяти и диск есть не всегда.

Джава получила широкое распространение на мобильных устройствах, где используются разные процесссоры(все-таки байткод дает переносимость программы в откомпиленном виде, что значительно удобнее срр, программы на котором пришлось бы собирать отдельно под каждую архитектуру), еще на серверах-пишут сервлеты, но на десктопах, где монополия винды и интел-совместимых процессоров софт пишут на с++. Кому нужны приложения занимающие 60мб оперативки вместо 20 или выполняющиеся медленнее? Сейчас может быть их стал бы кто-то использовать, но не лет 5 назад. Вот и пиcали весь софт всегда на mfc или borland c++. В результате потеряны возможности распространения технологии. И сейчас на джаве под десктоп практически невозможно найти пример сколько-нибудь распространенного приложения кроме самой жабы и среды разработки netbeans.

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

> разработчики программ не хотят раздавать по GPL свои проги - в большинстве случаев. вот виндопользователи будут пользоваться ими, а мы - нет. или пускать их в Wine (как например foobar2000 и ImgBurn).

Я не понял, к чему это...

Какую либку этим разрабам юзать? 1) qt - за бабло 2) wx - на халяву 3) gtk - вроде тоже на халяву (если не прав, поправьте)

не знаю что там пеарил сан - но делали они именно кроссплатформенную платформу. если у вас то, что слова у Sun совпадают с делом, плохо - ну уже не знаю что сказать.

переноса C++ программ с GUI с платформу на платформу - действительно нет. исключения - это результаты (единичные) неимоверных усилий разработчиков программ. и такая программа не совсем кроссплатформенная. она портированная.

ява круче всех - я не писал. я просто отбивался от крикунов.

>и из под юникса (например vlc -- линукс, винда, мак). и на другие архитектуры -- например моя нокия 800. И почему-то весь гуек -- не ява...

а кто тебе сказал что VLC из под юникса на венду пришёл?

> Вывод - или разработчики неквалифицированные, или договорились с кем-нибудь, с мс скажем.

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

>Какую либку этим разрабам юзать? 1) qt - за бабло 2) wx - на халяву 3) gtk - вроде тоже на халяву (если не прав, поправьте)

и gtk "нахаляву". но народ хочет писать на плюсах (почему то).

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

> а кто тебе сказал что VLC из под юникса на венду пришёл?

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

Вот лично я юзал libsdl. Это не гуи, а просто канвас. Так вот я из одного мейкфайла (и одного исходника без дефайнов) делал под линуксом сразу 2 бинарника -- под линукс и под винду :-)

> и gtk "нахаляву". но народ хочет писать на плюсах (почему то).

бери плюсовую обертку

>Раз вы насмотрелись на глюки, так может быть речь "про перенос C/C++ программы с GUI с платформы на платформу" все-таки идет? Особенно в случае QT? И неважно, за бабло он или нет, но все-таки компилится на куче архитектур?

надеюсь что уже компилится. правда я не помню есть ли кроссплатформенные программы работающие на qt (проги типа оперы - под виндой не под qt, они портированы на разные платформы: os/2, unix под qt и тд). и если это и случается - то только с совсем недавнего времени. а графический GUI у программ появился еще до возникновения самого C++.

>бери плюсовую обертку

я не помню всей истории, но что то там не так этим всё хорошо. и с gtk под вендой, и с "плюсовой" обёрткой gtk. могу ошибаться.

да и вообще лень мне тут "истории успеха" повторять для gtk, wx или qt. Суть в том, что не одна только Великая Ява переносимая вместе с гуем. Кстати, о tcl/tk слышал? его энтузиасты даже на winCE портировали.

> я не помню всей истории, но что то там не так этим всё хорошо. и с gtk под вендой,

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

вообще qt я не ругаю. вот оперу я без проблем поставил со статической qt4. в отличии от firefox3 и нового amule (под wx). это мне надо систему ломать чтоб их поставить.

>> Вывод - или разработчики неквалифицированные, или договорились с кем-нибудь, с мс скажем.

>Они видимо хотели снизить "порог вхождения" программеров, что конечно правильно.

www_linux_org_ru (*) (22.06.2008 1:26:23)

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

>Кстати, о tcl/tk слышал? его энтузиасты даже на winCE портировали

ага. меня tcl приводит в такое уныние, что радости от кроссплатформенности не наблюдается :)

> ага. меня tcl приводит в такое уныние, что радости от кроссплатформенности не наблюдается :)

Скажем, меня его синтаксис тоже не очень вдохновляет. Однако это не повод говорить, что Все Велосипеды Впервые Были Сделаны Санками Во Время Выпуска Великой Явы.

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

он не на плюсах. и этот проект сколько лет на платформу windows загоняли? пиля при этом сам gtk+ под винду.

> он не на плюсах.

из плюсов прекрасно вызывается

> и этот проект сколько лет на платформу windows загоняли?

ты меня утомить решил? как это связано с тем что "про перенос C/C++ программы с GUI с платформы на платформу вообще разговора нет" ?

> пиля при этом сам gtk+ под винду.

ты меня правда утомил... вон на моей нокии 800 -- гтк. и перенесли быстро, не рассыпались...

иди читай "истории успеха" http://www.gtk.org/commerce.html (в том числе о С++ обертке)

Я забыл кстати про NeroLinux... тоже gtk

>Концептуально правильно, но будет ли это быстро работать?

Заповеди гласят: "Do the simple thing that will most likely work" / "Умный программист тупейшим кодом решает сложные проблемы, а не наоборот". Поэтому в первую очередь я бы сделал хэш вида [пара классов]->[обработчик]. С вероятностью 90% это было бы приемлемым решением дающим приемлемый перформанс. Если бы было неприемлемым, то остается подход как у Александреску - два виртуальных вызова getIndex(), выфетчивание обработчика из двухмерного массива, виртуальный вызов обработчика. В Яве это делается точно также.

>ты меня утомить решил? как это связано с тем что "про перенос C/C++ программы с GUI с платформы на платформу вообще разговора нет" ?

единичные случаи + титанические усилия.

>Я забыл кстати про NeroLinux... тоже gtk

пример можно было бы приводить будь NeroWin32 под GTK. Это не кросслатформенный код.

>ты меня правда утомил... вон на моей нокии 800 -- гтк. и перенесли быстро, не рассыпались...

ты приводишь в пример и кроссплатформенный код и портированные проекты. да, есть немного кроссплатформенных. но иногда их качество ужасно (особенно под wx).

про gkt+ - на ней и под unix то особо не хотят писать, пусть с обёртками под плюсы. под win32 народ совсем хочет писать под gtk+. gimp не показатель. вспомним что вообще есть gtk+

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

про wx - глюч. под любыми платформами.

А я __второй__ раз повторю.

Меня тут интересует НЕ ТО КАК КРАСИВО ОФОРМИТЬ вирт. дв. дисп.

Поставлю даже более простую задачу:

1. контекст: защитники явы уверяют, что можно что-то там медленно работающее переписать на С.

2. задача: допустим, у вас медленно работает ОБЫЧНАЯ виртуальная диспетчеризация; допустим, известно, что виртуальный метод -- ровно один; ну-ка, без патча JVM (но с использованием С) попробуйте виртуальную диспетчеризацию ускорить!

И я утверждаю, что затраты на вызов С-функции в результате сведут выигрыш от "оптимизации" к 0 или минусу.

В отличие от С++. Где при условии "ровно один виртуальный метод" и при условии, что компилятор до этого сам не догадается, можно устранить одну индирекцию (т.е. хранить не адрес vtbl, а саму vtbl прямо в объекте)

ничего медленно работающего в java нет. реальные примеры программ показывают что java программы работают быстро и стабильно, ненагружая систему. желающие оптимизировать пусть делают это на C+асм.

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

все. сдаюсь. ты победил количеством постов :-)

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

На Си приходится скорее писать системно-зависимые части. Типа как в SWT или JCurses.

>допустим, у вас медленно работает ОБЫЧНАЯ виртуальная диспетчеризация; допустим, известно, что виртуальный метод -- ровно один; ну-ка, без патча JVM (но с использованием С) попробуйте виртуальную диспетчеризацию ускорить!

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

> Если скорость виртуального вызова не устраивает, то скорость работы остальной логики вообще не войдет ни в какие рамки.

Вообще-то правда. А жаль... пропадает пример, когда хрен ты в яве соптимизируешь, даже имея доступ к С.

Хотя мне кажется, что ява 10% времени занимается виртуальным вызовом... или хотя бы 5.

> И я утверждаю, что затраты на вызов С-функции в результате сведут выигрыш от "оптимизации" к 0 или минусу.

> В отличие от С++. Где при условии "ровно один виртуальный метод" и при условии, что компилятор до этого сам не догадается, можно устранить одну индирекцию (т.е. хранить не адрес vtbl, а саму vtbl прямо в объекте)

Да, Джаву не имеет смысла оптимизировать на си, потому что она и так достаточно быстра. JNI нужен не для "оптимизации", а просто для вызова стороннего нативного кода.

Что касается "ускорения виртуальной диспатчеризации", то и ускорять там нечего, потому что в java нет множественного наследования и "виртуальный метод" (абстрактный метод, в терминах Джавы) находится в наследнике базового абстрактного класса, метод которого ты вызываешь. И который можно получить по getClass().

Если уж тебе совсем хочется извратиться, то стоит использовать java.lang.Proxy, получая класс, имплементирующий заданный набор интерфейсов. При создании передается хэндлер, обрабатывающий вызов метода у данного класса. Потом берешь инстанс этого класса и вперед.

Вообще я впервые слышу, чтобы кто-то утверждал, что у джавы есть какие-то проблемы с абстрактными методами. Все там отлично.

> Хотя мне кажется, что ява 10% времени занимается виртуальным вызовом... или хотя бы 5.

Чушь.

>> И чё ты к сиплюсплюсу-то придрался?

> потому что дали ссылку на сравнение Java с GNU C++

Сыылка была на сравнение множества различных реализаций. А уж если ты выудил отттуда java vs C++, то это из-за особенностей сохнания.

> не буду. я непонимаю зачем это и кем и для чего написано.

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

> а плюсы - нет. потому что Java это в первую очередь платформа, а c++ просто язык который уже и без надстроек ввиде шаблонов и тп жить не может, и своих тулкитов не имеет.

Ой, а что это за странные строчки в начале программы на яве: "import java.lang.String". Наверно это подключение какой-то библиотеки?

> плюс такие тулкиты как qt - платные. это не способствует переносу программ с той же windows на unix.

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

> ну и пиши на плюсах. под одной платформой. в линукс и бинарники часто непереносимы.про перенос C/C++ программы с GUI с платформы на платформу вообще разговора нет.

Ой, а почемуй-то у меня программы, написанные с использованием того же qt работают на 3 разных архитектурах и 2 разных платформах? Наверно, тебя забыл спросить, чтоб ты объяснил, что это невозможно :о)

> а на gtk покажите популярные проги не под unix.

gimp :)

> и gtk "нахаляву". но народ хочет писать на плюсах (почему то).

кастую гика, чтоб он ткнул тебя в gtkmm

> Вот как только жаба тормозить перестанет, тогда можно смотреть. А пока - в печь

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

Что касается сабжа: ну пожалуй соглашусь что впихивание classpath'a это вредительство и выпуск недоджавы, да ещё на официальном уровне - это тоже очень плохая практика.. эдак будет не "write once - run anywhere", а "write once - debug anywhere" :)

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

Мы Все Любим ГипноЖабу... Мы Все Любим ГипноЖабу... Мы Все Любим ГипноЖабу...

> желающие оптимизировать пусть делают это на C+асм.

Тебе уже ни раз и ни два сказали, куда полетит после этого вся явовская кроссплатформенность.

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

Тебе показали реальную программу. Кстати, может для тебя это и будет новостью, но программа -- это набор алгоритмов.

> Ой, а что это за странные строчки в начале программы на яве: "import java.lang.String". Наверно это подключение какой-то библиотеки?

Нет. Это указание чтобы можно было писать в коде String. Если это не написать, то везде в коде придётся писать что-то типа java.lang.String.

import сам по себе ничего не подключает, а если не знаете, то не говорите.

Что касается тормознутости, то я уже ответил выше.

>> Ой, а что это за странные строчки в начале программы на яве: "import java.lang.String". Наверно это подключение какой-то библиотеки?

> Нет. Это указание чтобы можно было писать в коде String. Если это не написать, то везде в коде придётся писать что-то типа java.lang.String.

Да-да, а "uses crt;" -- это заголовок программы на паскале, который тоже ничего не подключает.

> import сам по себе ничего не подключает, а если не знаете, то не говорите.

Прочитай хоть какую-нибудь быдлокнижку про жабу, Великий Программист.

> Что касается тормознутости, то я уже ответил выше.

Что ответил? Пересказал своими словами очередную статью про Божественную Яву?

нет, это не то же что uses. Не путайте, а сначала разберитесь как JVM работает. Быдлокнижки не читаю и вам не советую (вы-то видимо знаете о них много, раз мне советуете).

> Что ответил? Пересказал своими словами очередную статью про Божественную Яву?

Ссылку в студию откуда.

> Ой, а что это за странные строчки в начале программы на яве: "import java.lang.String". Наверно это подключение какой-то библиотеки?

Эта строчка - воплощенный пиздец. Пакет java.lang уже автоматически импортирован. Поэтому если автор программы пишет "import java.lang.String" - он ни хрена не понимает в Java.

>> желающие оптимизировать пусть делают это на C+асм.

> Тебе уже ни раз и ни два сказали, куда полетит после этого вся явовская кроссплатформенность.

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

Ну извините. Я это просто процитировал в качестве примера.

Это вовсе не значит что именно так и надо делать.

Просто кое кто пытается мне рассказывать как import работает и советует что-то почитать. Я не один год работаю с явой и знаю как она работает. А если gaa не интересовался, то я не виноват.

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

Вы это себе по утрам перед зеркалом каждый день повторяете? Весь мой опыт показывает обратное. Есть ли ява программы для обработки потокового видео? А почему, если она не тормознутая? Тут выше писали, что на яве игры не пишут, на самом деле был опыт, никто повторять не хочет - "Ил2 Забытые сражения". На конференции разработчики говорили, что ява это круто потому что утечек памяти нету, читай программить можно хоть жопой - все равно заработает. И боттлнеки они на С писали, правда сами же сказали, что передача данных из/в яву очень накладный процесс. На тот момент игра поражала своей тормознутостью, особенно в сравнении с первой частью "Ил2 Штурмовик" написанным на плюсах. Я задал разрабам тогда вопрос: ну вот 90% кода у вас на яве, остальное на С, графика через огл, так когда на линукс портируете? Те закатили глаза и стали что то бормотать, что это очень тяжело и вот так просто jni с платформы на платформу не перенести.

>желающие оптимизировать пусть делают это на C+асм.

А идиотизм с невозможностью подключения одной внешней библиотеки двумя класслоадерами уже пофиксили? А танцы вокруг java.library.path куда денете? В винде это что то вроде "C:\stupid_bitch\biblioteki" в никсах "/usr/local/lib/stupid_bitch"