OpenOffice.org написан на C++ и прекрасно работает вообще без жабы.
Правда? А сколько в памяти занимает soffice.bin без открытых документов?
компонент Base (который недавно появился и активно рекламируется сейчас), движок JavaScript, целый ряд мастеров и визуальные эффекты accesibility. SDK тоже на Java рассчитано. К чему бы это?
А для редактирования текстовых документов кому-то и фара достаточно.
Я пробовал работать в Eclipse под GNU/Linux и FreeBSD на четвёртом пне с 512 МБ мозгов. Тормозит, но работать можно.
Очень интересное предположение. Обязательно проверю в ближайшее время. Странно всё это.
Но в Qt Designer я работал и на третьем пне 533 МГц со 128 МБ мозгов! Попытки запустить на аналогичном комьютере Eclipse успехом не завершились - просто виснет при запуске. IntelliJ IDEA запускается, но страшно лагает.
Про JVM под фрю и подобные оси уже всё понятно.
Единственное свойство жабы, имеющее отношение к кроссплатформенности. Но кому оно надо? Для свободного софта переносимость бинарного кода ничего не даёт, а коммерческий частенько ограничивается Windows, Linux и Mac, и живёт себе счастливо.
И что? Разве речь идёт о методиках разработки свободного софта? Jambi вроде так же входит в коммерческую версию qt, и тролли рассчитывают, что jambi будет приносить прибыль за счёт java-разработчиков. Open source версия qt существует в первую очередь для рекламных целей.
Что же касается библиотек, то тут проблема не в их наличии (тут C кого хошь переплюнет), а как раз в кроссплатформенности.
Так что же такое кросплатформенность?
Если как язык жаба заметно уступает кроссплатформенности тому же C++ (что следует хотя бы из того, что половина самой жабы написана на C++),
конечно же уступает в кросплатформенности в общем, и как язык в частности :-)
то с библиотеками у неё дело обстоит очень хорошо.
Sun постарались, безусловно.
Потом, если использовать Qt, например, то библиотеками, использующими, к примеру, для строк что-то отличное от QString, становится просто неудобно работать. То есть жаба тут хороша не только и не столько обилием библиотек, сколько их переносимостью и, что самое главное, интегрируемостью!
так она же не кросплаторменная?
А без QString работать не так уж и неудобно. Нужно просто уметь работать с char*.
Насчёт простоты не согласен. Я писал в IntelliJ IDEA, на Swing и на C++/Qt. Код, написанный на Qt, более изящен и компактен. И эффективен.
Ну вы бы код привели? Слабо верится :-)Насколько я знаю, в IDEA интерфейс рисуется в редакторе и код скрыт. А если интерфейс писать руками, так и Qt Designer ни к чему.
И о многочисленных подпроцессах не приходится париться. Впрочем, главное тут всё же быстродействие. Swing был бы вполне удобен, если бы не его дикие тормоза.
с подпроцессами в swing париться нужно, чтобы загрузку организовать и живучесть интерфейса при исполнении длительных операций, если же простой диалог, никаких подпроцессов там не надо.
Отсутствие дистрибутивов JVM для FreeBSD (точнее, их запаздывающий выход) - подтверждение тому, что в Sun не умеют писать под Unix.
Лучше таких вещей никому не говорить :-)
Правильно написаный код вообще работает почти в любом юниксе без проблем, тем паче в FreeBSD. Как они умудрились сделать жабу только под Линукс (а также сделать отдельные версии для Linux и Solaris) - это вообще чудо какое-то. Специально старались, что ли?
Если писать на станартном CRT, так ещё и в винде этот код будет работать без проблем
Вам приходилось сталкиваться с различиями Sparc Solaris и Power Linux? :-) К сведению: в каждой JVM сидит JIT компилятор и транслирует байткод в нативный машинный код процессора и запуски системных функций. Вот поэтому JVM для всех разные.
Тот же Qt ведь имеет единый исходный код для всех разновидностей Unix/X11 и оно прекрасно всюду компилируется и работает.
потому что это единство и рассчитано на X11 и CRT :-)
И код очень хорошо написан - понятно, обозримо. И процесс сборки такой же прозрачный. В отличие от жабы, которая при сборке жрёт пару гигов пространства, причём по большей части на создание копий одного и того же в чуть разных вариантах с разными именами, а также многочисленных архивов.
это kaffe-то? :-) спасибо за подсказку, ни в жизни теперь этим заниматься не буду
)
О простоте. Я изучал и жабу, и C++. С поверхности - оба языка достаточно простые (C++ изучал три дня со знанием C, жабу - где-то неделю).
Т.е. вы хотите сказать, что ни то ни другое вы не знаете совсем? Собственно я так и полагал. Тогда к чему высказывать свои суждения (в большинстве случаев неверных в данном случае) таким количеством эмоциональных необуманных реплик?
В глубине же - чёрти-что и сбоку бантик. Достаточно почитать Java Language Specification, чтобы убедиться. Другой разговор, что ни там, ни сям большая часть наворотов никому не нужна.
Замечательный документ, на самом деле. Просто он как и вариацонное исчисление - не для всех.
Тут всё-таки дело во-первых в быстродействии графических компонентов, а во-вторых, не в том, что сделать можно и нельзя, а в том, что сделать проще и что проще отладить, то есть в высокоуровневости жабы как языка программирования.
С отладкой в Java всё значительно проще - бинарник везде одинаковый :-)
Во всяком случае, я до сих пор не видел ни одной задачи, решённой на жабе, которую нельзя было бы решить быстрее, проще и лучше на чём-то другом.
по секрету: проблема не в быстроте разработки, а в сложности "переделки" :-)
Кое-чего стоит и то, что в FAQ Trolltech написано, что основной причиной создания Qt Jambi послужили многочисленные пожелания клиентов иметь нечто подобное.
не могу понять пока, куда это можно прилепить.
Что касается питона, то я его только начал изучать, но вообще понятие компиляции и байт-кода там есть. И вообще любопытно, что о нём я слышал только хорошее и только от профессионалов. Изящный язык, заслуживающий внимания.
а на ПХП весь мир этот веб программирует без проблем :-)
По поводу FreeBSD: я же сказал, выходит с запозданием на два года. То есть таки выходит! Сертифицированная жаба 1.5.0 под FreeBSD есть.
сертифицированная-то она на поддержку Pure Java 1.5, это не значит, что она работает как Sunовская или IBMовская. Отсуствие jvm под эту ось у передовых производителей JVM говорит о том, что BSD поддерживать никто не собирается.
ЗЫ: по поводу скорости графических компонентов: AWT устарел и его использование не оправдано. Давно существует SWT, который избавляет UI от тяжести Swing, никак при этом не отличаясь в использовании. И построен SWT как Qt: под винду на Win32 API, под мак - на карбоне, а под X11 на gtk! Вот на него и грешить надо.
