LINUX.ORG.RU
ФорумTalks

Java Gnome


0

0

Помнится мне инициатива для повышения эффективности разработки прикладных приложений для Gnome было перейти на Mono. Тоесть нужно было взять полуоткрытую-полузакрытую технологию .NET от MS, сделать из нее убогий клон, который в жизни не дотянет до уровня .NET, пилить его, а потом пихать это поделие в любимый многими десктоп, здить Столлмана и линуксоидов.

Одновременно существует готовая открытая технология Java, которая работает быстрее практически любой другой платформы (Python, Mono, Perl), разрабатывается серьезной компанией. В ней из коробки такой функционал, что можно выбросить половину библиотек в системе.

В то же время NetBeans работает совсем не шустро, несмотря на то, что Java обгоняет на бенчмарках все пайтоновские программы. И в то же время десктоп программы на Python работают прекрасно (хотя мечтаю увидеть NetBeans на python). Факт остается, Java не идеал для десктопа. Причиной тому супермедленная технология Swing, в которой 100500 абстракций. Что не приложение на Swing, так сразу сьедается куча памяти вся батарея на моем ноуте. Обратите на это внимание, когда запустите Swing поделие на ноуте от батареи. Для очевидности эксперимента запустите NetBeans и поработайте.

Мое предложение: забыть mono навсегда и продвигать инициативу java+gtk. Писал программы - они просто летают, без проблем интегрируются с Gnome L&F. Но одновременно функционал с платформой Java идет такой, что ни Qt, ни Glib & friends не могут конкурировать. Mono благополучно закапывается, Vala остается для разработки библиотек, так как на Java не сделать GObject библиотеку. Идея в том чтобы пользоваться Java без Swing, но с Gtk.

Кто что думает?

★★★★★

Ответ на: Просто не знаю чему удивлятся от kamikadze

Azureus и eclipse смотрятся для меня не менее чужеродно, чем GTK Swing L&F. Все связано с layouts, которые как то не так работают и имеют необычные отступы. Ну а табы в eclipse доставляют.

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

Мощностью библиотеки классов, документированностью, доделаностью и языками типа Scala и Groovy, которые тоже работают на JVM, очень мощные и удобные, а также полностью интероперабельны с java

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

Без хорошей документации и примеров нифига не будет с java + gtk.
Сравни с обилием учебной писанины по java + swing.
Даже по php + gtk доки лучше.

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

Тогда какой вообще смысл от Гнома? Это же уже не гном будет, а просто Java/GTK+ окружение.

Мигель... Не сыпьте соль не рану. Скоро его тру-гномовцы на кол посадят.

А кто вообще Gnome основал в курсе?

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

Мигель... Не сыпьте соль не рану. Скоро его тру-гномовцы на кол посадят.

А благодоря таким как Мигель, зудливая детвора не превратила пока Gnomе во вторые кеды:
http://www.opennet.ru/opennews/art.shtml?num=17008

elipse ★★★
()

К слову о быстродействии

Буквально сегодня сделал тест конкатенации строк на Java:

public class StrBench4 {
    public static void main(String[] arg) {
        final int TEST_COUNT = 10;
        final int COUNT = 1000000;
        final String a = "Маша", b = "мыла", c = "раму!";
        for (int tests = 1; tests <= TEST_COUNT; tests++) {
            StringBuilder sb = new StringBuilder((a.length() + b.length() + c.length()) * COUNT);
            long begin = System.currentTimeMillis();
            for (int cnt = COUNT; --cnt >= 0;) {
                sb.append(a).append(b).append(c);
            }
            long end = System.currentTimeMillis();
            System.out.printf("Тест №%d\nРезультат: %.78s — длина строки %s символов\nВремя выполнения  %d мс.\n", tests, sb, sb.length(), (end - begin));
        }
    }
}
Вывод:
Тест №1
Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов
Время выполнения  84 мс.
Тест №2
Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов
Время выполнения  74 мс.
Тест №3
Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов
Время выполнения  42 мс.
Тест №4
Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов
Время выполнения  42 мс.
Тест №5
Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов
Время выполнения  42 мс.
Тест №6
Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов
Время выполнения  43 мс.
Тест №7
Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов
Время выполнения  42 мс.
Тест №8
Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов
Время выполнения  42 мс.
Тест №9
Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов
Время выполнения  42 мс.
Тест №10
Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов
Время выполнения  42 мс.
$ java -version
openjdk version "1.6.0"
OpenJDK Runtime Environment (build 1.6.0-b17)
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)
% uname -rsm
FreeBSD 8.0-STABLE amd64
% dmesg | grep AMD
CPU: AMD Phenom(tm) II X4 810 Processor (2594.47-MHz K8-class CPU)
  Origin = "AuthenticAMD"  Id = 0x100f42  Stepping = 2
  AMD Features=0xee500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!
Так вот, лучший код на C & Asm, написанный вручную, даёт при экстраполяции на миллион итераций конкатенации строк — 60 и 10 миллисекунд, соответственно, и то — только с полной ручной(!) оптимизацией.

Такая же программа на Mono (приведён пример для 100 тысяч итераций) при экстраполяции на миллион итераций медленнее Java в 15 раз!

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

Разрабатывая на mono получаем переносимость под венду сразу. А на Java + gtk - нет.

Есть портируемая библиотека SWT, которая представляет собой оболочку над системными вызовами к нативным виджетам тулкитов и графическим оболочкам Windows и Unix, соответственно. Для систем компилируется «своя» SWT, а наше приложение на java работает лишь с Java-интерфейсом, который предоставляет эта библиотека. Таким образом получаем переносимое приложение с необходимостью использования нативной библиотеки.

Для сравнения: приложение «Hello World» на SWT с единственным окном занимает в памяти порядка 30-32МБ.

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

На Java Gnome было совсем мало. Сейчас не скажу, чтобы не соврать. Точнее скажу позже

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

Для сравнения: приложение «Hello World» на SWT с единственным окном занимает в памяти порядка 30-32МБ.

Hello world на java-gnome занимает около 10 метров.

a3
()

мое имхо:

1)контраргументы против велосипеда:

а) у явы есть определенные проблемы с нативными вызовами. «Нативный» SWT по производительности на линуксе проигрывает свнигу. В яве 7 обещали сделать рендеринг виджетов свинга нативными гткшными => ускорение, нативный внешний вид

б) тормознутость NetBeans - следствие нерационального планирования сборки мусора. В яве 7 сборщик мусора другой => отзывчивость UI улучшится

вывод: логичнее пилить яву + свинг + гтк-биндинг, переспектив еще полно

2)>Но одновременно функционал с платформой Java идет такой, что ни Qt, ни Glib & friends не могут конкурировать.

Как раз-таки Qt (имхо) представляет собой целостную платформу, чего нельзя сказать о Яве без Свинга

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

а) у явы есть определенные проблемы с нативными вызовами.

Начиная с Java 6u10, нативные вызовы (JNI) оптимизировали насколько вообще возможно.

«Нативный» SWT по производительности на линуксе проигрывает свнигу.

У меня другое наблюдение. Swing-приложения заметно на глаз быстрее работают на Windows, чем на FreeBSD. С SWT-приложениями наоборот: RSSOwl, например, я пользуюсь и там и там, оно вообще не тормозит на FreeBSD — запуск, реакция на клик и выделение элемента/открытие вкладки мгновенная; на Windows заметна латентность SWT-интерфейса, некая «вальяжность» — как у Swing-приложений на FreeBSD.

В яве 7 сборщик мусора другой => отзывчивость UI улучшится

Как думаешь, стоит поменять OpenJDK6 на OpenJDK7?

вывод: логичнее пилить яву + свинг + гтк-биндинг, переспектив еще полно

Gtk-биндинг и есть SWT. Сделать лучше — не получится, так как Gtk2 API у биндинга не везде последней версии (пробовал на FreeBSD Gtk-биндинг — сильно устаревшая версия в портах).

Как раз-таки Qt (имхо) представляет собой целостную платформу, чего нельзя сказать о Яве без Свинга

Java не бывает без Swing'а, Swing включена в JRE. Qt4 сама по себе очень толста по сравнению с 15МБ JRE.

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

Конечно есть смысл подождать полноценной Java 7 и потом думать, вдруг будет десктоп-конфета.

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

Я тоже собирал из сорцов, в дистрах обычно старый байндинг

vertexua ★★★★★
() автор топика
Ответ на: К слову о быстродействии от iZEN

Такая же программа на Mono (приведён пример для 100 тысяч итераций) при экстраполяции на миллион итераций медленнее Java в 15 раз!


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

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

>Для сравнения: приложение «Hello World» на SWT с единственным окном занимает в памяти порядка 30-32МБ.

4.2 - У меня - 10 мегабайт.

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

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

Неужели все так боятся сегфолтов?

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

>Скорость разработки

Берешь куты, получаешь скорость разработки. ИМХО, даже проще чем свинг. продвинутым с++-кодером быть не обязательно. конечно, скриптовые языки зарулят, жаба сильно ускорит дело только если совсем быдляцкий код писать

Скорость выполнения

у нативных выше

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

>у нативных выше

Скорость std::hash_map vs java.util.HashMap на строках я приводил (напомню, джавовская реализация выигрывала в 10 раз на поиске). Так что зависит не столько от язык.

жаба сильно ускорит дело только если совсем быдляцкий код писать

Авторитетненько.

Берешь куты, получаешь скорость разработки

На с++ нет и не будет много того что есть под джаву. Например Eclipse RCP.

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

>и слава богу

Ну и программируйте по 10 раз одно и тоже с тормозами и ошибками.

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

Ну я лично ничего сейчас не мерял. Почему вы отвечаете вопросом на вопрос? Померяйте, пожалуйста, свое приложение и выложите, пожалуйста, скриншот. Пустое окно на SWT.

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

Я имею ввиду скриншот с окном и с памятью, чтобы видно было. Я почему прошу это сделать, потому что есть разные методы мерять. И как вы сделаете, так же померяю и я java gnome окно. Ведь разные параметры бывают. У меня Ubuntu 32 бита.

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

>Разрабатывая на mono получаем переносимость под венду сразу. А на Java + gtk - нет.

Почему если разговор о программах для Gnome, сразу встает вопрос портирования на офтопик?

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

>Разрабатывая на mono получаем переносимость под венду сразу. А на Java + gtk - нет.

Зато в Java (Sun JRE 6u10, OpenJDK 6b18) есть свинговый Nimbus Look&Feel, который «из коробки» выглядит одинаково волшебно на Windows и на Unix. А вы со своей Моной всё время будете работать с тем, что дают, вечно отставая от .NET. :))

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