Здравствуйте, igna, Вы писали:
I>Какие недостатки есть у Java/SWT по сравнению с другими комбинациями язык/библиотека для программирования под Windows? Хочу, чтоб поругали.
Список недостатков (ИМХО):
SWT базируется на Java, отсюда очевидный недостаток — SWT зависит от Java
SWT сравнительно молодая библиотека. Разработчик, который использует эту библиотеку "по крупному" обречен хоть раз запостить баг в багрепорт Eclipse комьюнити. Если посмотреть на баг-листы SWT можно заметить, что абсолютное большенство багов и рассуждений в новостных рассылках SWT от разрабочиков крупных продуктов на основе этой библиотеки (тот же Azureus проект или SWT Designer). Итак вторая проблема — это баги, из-за молодости библиотеки. Многие пофишены, но все-равно они есть еще. Вы не управляете развитием библиотеки. Формально библиотека открытая, фактически — есть сообщество, планы которого задокументированы на год вперед. Из-за этого ваши идеи, пусть и революционные — идут в мусорку. Ограниченая функциональность. Вы огранчены рамками SWT. Все что выходит за рамки библиотеки, придется писать самим. Иногда это обходится "дорого", так как приходится писать на JNI для множества предполагаемых систем. Вы привязаны к "платформе". Это значит, что если какого-либо native-компонета нет в системе — ваша программа будет работать без него (Например, Eclipst до сих пор не может подружить версии SWT с Motif).
Здравствуйте, 0rc, Вы писали:
0rc>SWT базируется на Java, отсюда очевидный недостаток — SWT зависит от Java
Со всем согласен, но вот это философское утверждение не понял, можно разжевать?
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, 0rc, Вы писали:
0rc>>SWT базируется на Java, отсюда очевидный недостаток — SWT зависит от Java R>Со всем согласен, но вот это философское утверждение не понял, можно разжевать?
Я имел ввиду JVM, так например есть тот же MFC, он не привязан к JVM, в этом смысле MFC "лучше" SWT так как не требует предустановленной JRE.
Здравствуйте, 0rc, Вы писали:
0rc>Я имел ввиду JVM, так например есть тот же MFC, он не привязан к JVM, в этом смысле MFC "лучше" SWT так как не требует предустановленной JRE.
Да, вот это интересно. Некоторые считают зависимость от JVM (или CLR) недостатком, некоторые нет. В чем конкретно ты видишь недостаток?
Здравствуйте, igna, Вы писали:
I>Здравствуйте, 0rc, Вы писали:
0rc>>Я имел ввиду JVM, так например есть тот же MFC, он не привязан к JVM, в этом смысле MFC "лучше" SWT так как не требует предустановленной JRE.
I>Да, вот это интересно. Некоторые считают зависимость от JVM (или CLR) недостатком, некоторые нет. В чем конкретно ты видишь недостаток?
Сейчас я бы не назвал это большой проблемой, хотя до недавнего времени (как сейчас не знаю) существовали платформы, для которых не было JRE.
Здравствуйте, igna, Вы писали:
I>Да, вот это интересно. Некоторые считают зависимость от JVM (или CLR) недостатком, некоторые нет. В чем конкретно ты видишь недостаток?
Здравствуйте, 0rc, Вы писали:
0rc>Сейчас я бы не назвал это большой проблемой, хотя до недавнего времени (как сейчас не знаю) существовали платформы, для которых не было JRE.
До недавнего времени SWT было только для Windows. Сейчас кажеться ситуация изменилась, но я не уверен.
cvetkov wrote: > 0rc>Сейчас я бы не назвал это большой проблемой, хотя до недавнего > времени (как сейчас не знаю) существовали платформы, для которых не было > JRE. > До недавнего времени SWT было только для Windows. Сейчас кажеться > ситуация изменилась, но я не уверен.
SWT с рождения поддерживала Linux.
Здравствуйте, cvetkov, Вы писали:
C>До недавнего времени SWT было только для Windows. Сейчас кажеться ситуация изменилась, но я не уверен.
Cyberax истину глаголет — с Linux-ом SWT дружил всегда. А теперь вот это многообразие:
SWT:
Windows.
Windows (x86/WPF).
Windows (x86_64).
Linux (x86/GTK 2).
Linux (x86/Motif).
Linux (x86_64/GTK 2).
Linux (PPC/GTK 2).
Linux (s390/GTK 2).
Linux (s390x/GTK 2).
Solaris 8 (SPARC/GTK 2).
AIX (PPC/Motif).
Mac OSX (Mac/Carbon)
eSWT:
Windows Desktop.
Windows Mobile 2003/5.
WinCE 5.0 Professional.
Nokia Series 80.
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, cvetkov, Вы писали:
C>>До недавнего времени SWT было только для Windows. Сейчас кажеться ситуация изменилась, но я не уверен. R>Cyberax истину глаголет — с Linux-ом SWT дружил всегда. А теперь вот это многообразие:
R>[list=1]SWT:
0rc>Список недостатков (ИМХО):
0rc>SWT сравнительно молодая библиотека. Разработчик, который использует эту библиотеку "по крупному" обречен хоть раз запостить баг в багрепорт Eclipse комьюнити. Если посмотреть на баг-листы SWT можно заметить, что абсолютное большенство багов и рассуждений в новостных рассылках SWT от разрабочиков крупных продуктов на основе этой библиотеки (тот же Azureus проект или SWT Designer). Итак вторая проблема — это баги, из-за молодости библиотеки. Многие пофишены, но все-равно они есть еще.
Не все так страшно, библиотека не настолько молодая, и на ней написан не один крупный проект.
0rc>Вы не управляете развитием библиотеки. Формально библиотека открытая, фактически — есть сообщество, планы которого задокументированы на год вперед. Из-за этого ваши идеи, пусть и революционные — идут в мусорку.
Хм.. а ситуация с MFC, Winforms, QT или Swing лучше?
0rc>Ограниченая функциональность. Вы огранчены рамками SWT. Все что выходит за рамки библиотеки, придется писать самим. Иногда это обходится "дорого", так как приходится писать на JNI для множества предполагаемых систем.
Это цена кросплатформености. Если проект только под Windows — JNI кодa не намного больше чем расширяя MFC.
0rc>Вы привязаны к "платформе". Это значит, что если какого-либо native-компонета нет в системе — ваша программа будет работать без него (Например, Eclipst до сих пор не может подружить версии SWT с Motif).
Обратная сторона really-native-look-and-feel.
Если не заморачиваться на естественных ограничениях возникающих при выборе кросплатформенной библиотеки, остаются только возражения по дизайну.
Встречал мнение: требование SWT, чтоб все операции с виджетами проходили в одном потоке в, это плохо.
Можно поругать SWT за то что вместо асинхронных делегатов как в Winforms, многопоточность реализована через метод Display.[a]syncExec...
Но это все не мое IMHO. По мне так SWT+Jface рулят.
-- Главное про деструктор копирования не забыть --
Здравствуйте, 0rc, Вы писали:
0rc>>>SWT базируется на Java, отсюда очевидный недостаток — SWT зависит от Java R>>Со всем согласен, но вот это философское утверждение не понял, можно разжевать?
0rc>Я имел ввиду JVM, так например есть тот же MFC, он не привязан к JVM, в этом смысле MFC "лучше" SWT так как не требует предустановленной JRE.
С таким же успехом можно сказать, что "SWT не привязан к windows, в этом смысле SWT лучше MFC так как не требует предустановленной windows". В конце концов любой gui от чего-то зависит, так что имхо совсем не аргумент
Здравствуйте, igna, Вы писали:
I>Не прими за занудность, но почему это недостаток? Чем это хуже случая, когда программа использует некую библиотеку, dll которой нужно установить?
Ничем, если размеры и усилия при установке библиотеки и JRE сопоставимы.
Я же не говорю, что это огромный минус. Но это отнюдь не достоинство, и иногда это надо учитывать. Я скорее скачаю программку на 5 мегабайт, чем на 50, если функциональность у них схожая. И мне абсолютно по барабану насколько удобно было разработчикам её разрабатывать.
Здравствуйте, lomeo, Вы писали:
L>Ещё мегабайты.
~9Mb, с размером встроенного .NET, кстати, несравнимо, как впрочем и по простоте установки.
L> Возможно, из-за размера потенциальный пользователь откажется это качать.
Так сделать два инсталлятора. Это проблема распространения приложения, а не проблема самого приложения.
Здравствуйте, rsn81, Вы писали:
L>> Возможно, из-за размера потенциальный пользователь откажется это качать. R>Так сделать два инсталлятора. Это проблема распространения приложения, а не проблема самого приложения.
Я к тому, что сколько инсталляторов не делай, а JRE пользователю нужно. Если его нет, то его надо качать и ставить. Как он это будет делать — качать отдельно или встроенный — неважно. Это дополнительные телодвижения. А дополнительные телодвижения достоинством назвать трудно.
Здравствуйте, lomeo, Вы писали:
L>Я к тому, что сколько инсталляторов не делай, а JRE пользователю нужно. Если его нет, то его надо качать и ставить. Как он это будет делать — качать отдельно или встроенный — неважно. Это дополнительные телодвижения. А дополнительные телодвижения достоинством назвать трудно.
Грамотно распространяемое ПО позволяет пользователю:Выбирать для скачивания один из инсталляторов: с включенной средой исполнения или без.
Во время установки инсталлятор определяет наличие среды исполнения (в случае .NET это кроме прочего и предшествующее определение наличия следующего ПО требуемой версии: IE, Windows Installer и прочее), и в случае ее отсутствия:
инсталлятор со встроенным сопутствующим ПО автоматически устанавливает его, пользователь, в принципе, может и не заметить этого;
"легкий" инсталлятор предлагает автоматически загрузить соответствуюшее ПО из Интернета;
Таким образом, пользователю достаточно жимкнуть OK в диалоге: ПО будет при необходимости загружено и установлено.
Телодвижения при грамотном распространении приложения минимальны — нажать OK в соответствующем диалоге. Проблема вовсе не в самом факте существования сопуствующего ПО, среда исполнения управляемых платформ в этом отношении ничем не отличается от используемой в программе конкретной библиотеки, БД и прочего. Проблема в том, как это сопутствующее ПО поставляется. Если программист не заботится о телодвижениях пользователей, то проблемы будут без вариантов.
