Java как язык создания приложений. Насколько популярен??

Сразу оговорюсь, на данном языке я не программирую, но азы его приблизительно знаю. Много чего есть там привлекательного для программистов, хочу и сам как-нить попробовать что-нить забацать.
Но смущает то, что я не видел каких-либо распространённых приложений, которые были бы написаны на Java. Это мой косяк или действительно так?

Если всё-таки мой, какие известные линуксовые приложения базированы на Яве?

Один факт кроссплатформенности уже сколько всего даёт...! Но интерфейсы приложений на Яве, честно говоря, отвратительные. Может мне такие уж попадались..

Я вот знаю OpenFire

Я вот знаю OpenFire (бывший Wildfire) - Jabber-сервер, еще есть Spark (jabber-клиент на java)...
_________________
Gentoo Linux 2007.0, kernel-gentoo-2.6.20-r4; KDE 3.5.6

Есть еще

Есть еще кроссплатфокменный mucommander [url]http://www.mucommander.com/ [/url]. Вещь хорошая, но пока в альфе. А так основной недостаток явы на клиенте - неумеренное рассходоваие ресурсов. На сервере же ява хорошо маштабируеться, например возмем расход памяти, на 1 клиенте расход моего (потолочного) явасервера составлят 100 мб, а на 5000 120 мбайт.

вот например на яве программа

Azureus BitTorrent Client

Приложения:*

Приложения:
* OpenOffice - частично на Java
* Eclipce
* Idea
* JEdit
* SQL клинтов несколько есть, один из них называется типа - белка, на англ. не очень помню написание.
* Jake - квава 2-я на java
* NetBeans
* Замечательные веб сервера - WebLogic, JBoss, Tomcat

По поводу интерфейса - для джавы есть много UI, можно к своей программе любой подключить, и будет выглядеть как родная прога определнной платформы.
Если хочется прелести джавы только помаксимуму использовать возможности какойто оси можно native функции юзать, +под генту можеш глянуть с чем её связать можно так - eix -S 'Java bindings'

Я JavaTech и всеми вещами с этим связанными занимаюсь уже 4-ый год, но всё таки считаю что standalone приложения писать на ней не очень хорошо, медленно они работают.. не то чтобы очень, но неудобно.

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

ИМХО, java идеальна для серверов, для приложений со сложной бизнес логикой, она позволяет сосридоточиться на цели а не на особенностях реализации.

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

Если писал раньше на другом ООП языке, то не обольщайся, нигде так строго не соблюдаются его принципы как джаве, советую обязательно прочитать - Брюс Эккель, Философия Java, это библия языка.
_________________
- Desktop: core: p4-3.0, video: Nvidia 7900 GT, hard: 4x250 Gb (baracuda 9 series) & 80 Gb WD, mem: 2 G, Audio: Creative X-Fi
- Portable: Asus U5A (915 chipset, centrino 1.73 Donath, 1.5 Gb mem, 160 Gb hard, e.t.c)

Сорри, а что за

Сорри, а что за "standalone приложения"?

>> лучшие java приложения, это приложения для создания джава приложений.
а почему прослеживается такая тенденция?

Мне просто интересно реально ли на яве писать сложные приложения, которые требуют больших вычислительных затрат. Приложения реализующие всякие математические/физические модели.
Не берусь утверждать, но мне кажется, что приложения на Яве расходуют заметно больше ресурсов, чем аналоги написанные например на Си.
Если это так (чего ж там на мат. модели останется?(-: ), понимаю, что за всё нужно чем-то и как-то платить.
Но что же получаешь взамен от Явы? жертвуя ресурсами.

Спасибо за указание книги. Попытаюсь найти её на полках.

standalone -

standalone - запускаемые в обычном системном окружении, не серверные приложения использующие j2ee. написанные с помощью только sdk. Т.е практически всё кроме вёб приложений и аплетов.

Писать сложные приложения на джаве очень даже можно, скорость математических расчётов ни чуть не меньше чем в остальных языках, скорость работы именно с объектами и реализация ООП даже быстрее чем в С++. Лажает swing, т.е окошки, элементы управления и тп., создавать всё удобно, но ради кросплатформенности они уж очень раздутые в плане событий и деталей реализаций внутри jsdk.
И прошу заменить, проблемы перформенса не именно графики, а элементов интерфейса польователя. Просто рисование 2д, и тем более 3д через OpenGl работает очень быстро, сравнимо по скорости с С++. Над ними минимальная обёртка сделана, поэтому всё так замечательно.

Т.е ИМХО такое - писать серьёзные приложения с тяжолой бизнес логикой можно и даже нужно на java, но большинство таковых реализуются в серверном варианте. Писать же серьёзный юзер интерфейс на джава будет тормознуто (именно изза самого интерфейса), в остальном скорость на высоте, если и такой будет мало, то есть JIT компиляторы, которые способны создавать родное приложение для определённой платформе на основе байткода, что даёт ещё небольшой выигрыш в производительности.

PS. ещё вспомнил - авиасимулятор на джаве написанный - ИЛ штурмовик, чтото в этом духе.

Книгу на книжной полке пожалуй уже не найдёш (если только в штатах), поищи в инете, есть и на русском и на англ.

Понятно. Ну

Понятно. Ну звучит вполне даже очень убедительно.
Если тормозит только графический интерфейс, так это и не всё так плохо. А если в остальном язык не остаёт от остальных, то значит он их превосходит. (-:

Графику, ессно, отрисовывать, если буду, то через OpenGL.
А тормозной граф. интерфейс... а чего он тормозной-то такой, что его переделать не могут на что-то более приемлемое? (или он там слишком наворочен, что переделывать огого по трудозатратам и времени)

В этой теме во втором посте написано:

Цитата:
А так основной недостаток явы на клиенте - неумеренное рассходоваие ресурсов.

Мне возможно прийдётся разрабатывать и клиент-серверные приложения, поэтому хотелось бы узнать, как у Явы здесь обстоят дела?
"Неумеренное расходование ресурсов" с чем связано? В чём это выражается? Какие именно ресурсы расходует, насколько интенсивно?

В целом меня Ява очень привлекает. Просто изначально хочется продумать все "пути отхода" (-: Чтобы не попасть "в просак". Так начну что-нибудь прогить и окажется, что здесь непомерно ресурсов берёт и вообще в приложении (клиент-серверном) работать невозможно..

Эффект

Эффект неумеренного расходования ресурсов (а также и тормознутости) создаётся из-за двух вещей в основном:
1) Когда запускается java приложение, обычно ещё jvm в память не подгружена и необходимо некоторе время чтобы этот процесс завершился, соответственно и памяти она сразу отъест немало. Когда jvm один раз загрузилась в память - все последующие запуски java приложений будут быстрее, т.к используется один экземпляп vm (virtual machine) для исполнения всех программ.
2) Молодые програмисты наслушаются о том что джава это круто и в ней нет утечек памяти и т.п, юзать ресурсы можно как угодно ни о чём не задумываясь, писать удобнее и быстрее чем в других языках, есть куча средств hi-end уровня для создания кода, которые позволяют одной рукой код набирать и расслабляются. Расходуют ресурсы по чём зря. А и в джаве есть memory лики, надо просто разобраться как что работает, как проиходит выделение памяти при работе в теми или иными коллекциями, массивами, как работает gc (garbidge collector) и тп. Книжек по этому нет только нормальных (бывает там слово скажут, там два ..), надо по технической документации лазить и статьи по теме искать.

Вобщем магических расходов памяти непонятно куда не будет, всё вполне объяснимо, большой объём сама java машина занимает, конкретно программы не очень много. Процессор сильнее не используется.

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

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

Quote:к примеру - в

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

В случаек с С или С++ (да и любым другим языком), занулением занимается ОС когда выделяет еще оперативной памяти. Это чтобы данные одного приложения не попадали в неинициализированный буфер другого.

Речь идёт о

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

MySQL на целых 3%

MySQL на целых 3% написан на Java

Где-то полтора

Где-то полтора года занимаюсь написанием апплетов и ещё немного jsp.
Касательно сферы применения: это у нас в php является лидером по построению динамических страничек с админовскими панельками и т.д. и т.п. А вот в США, например, от этого уже во многом отказываются и у них большей популярностью пользуется jsp. Кроме того оттуда же идет большой заказ на серверные приложени как раз на java. Какой бы с моей точки зрения не был плохой пример (американцы) но специфику запросов на java-программистов он отражает хорошо.
Это в принцыпе отражает те сферы в которых java показывает себя очень хорошо. А кроме того никт он езапрещал писать апплеты для сайтов, какие-нибудь приложения, которые даже могут выполнять довольно низкоуровневые функции - как бы Майкрософт не пыжевалась наличием native-кода в С#, но java тоже позволяет довольно глубоко опускаться и писать близкие к realtime приложениям, только не все об этом знают.. И даже приложения для мобильных телефонов. :)
С интерфейсом у него так же вполне даже всё нормально - было конечно ещё в 1.1 и 1.2 ужасное отобржаение на сером фоне. Но теперь оно вроде как кануло в лету. И теперь у java довольно красиво выглядят окошки и все элементы. Довольно хорошо дело обстоит с графикой в приложениях.
Да и в пользу применения java говорит наличие целой ОС в основе которой ледит фактически идеологи java - Solaris. Там кстати есть оконные менеджеры написанные на java - не шибко быстрые правда :(.
Вот касательно скорости, то тут штука двоякая - есл иписать какие-либо серверное приложение, мат. расчеты, то скорость ещё ого-го какая. Да и для тех же мат расчётов есть замечательная штука Decimal (длинные числа). А вот скорость работы swing (как уже писалось) не слишком высока, да и загрузка java virtual machine не способствует повышению быстродействия. Но опять же - она хоть и проигрывает по скорости запуска откомпилированным приложениям, но зато потом на отрисовке графики может ещё вполне даже потягаться со стандартными api той же Windows отчего может поспорить в скорости с приложениями, которые компилируется хорошими компиляторами, а не транслируются. Да и со временем по моим наблюдением java начинает бегать шустрее и шустрее.

Quote:Да и в

Цитата:
Да и в пользу применения java говорит наличие целой ОС в основе которой ледит фактически идеологи java - Solaris

Как могла технология которой ещё не существовало в то время, когда появился солярис служить идеологической для него основой? :) Sun просто кузница в которой много чего создаётся.

Вобщем стандартное заблуждение, ОС на которую сильно влияет джава НЕТ, все попытки написать таковую провалились из-за слишком большой тормознутости и из-за серьёзных ограничений (сама идея это сделать была на мой взгляд абсурдна...). Что отнюдь не говорит о том что язык плохой, просто сфера применения его в дургом.

Зато ОС конкретная ещё как может влиять да джаву, из-за ограничений одной страдаюсь все.

PS.
WXP, думаю этот источник будет тебе полезен
http://ru.wikipedia.org/wiki/Java
там и ссылка на русского Эккеля есть.

GrAndSE, наверное ты об этом говорил в солярке - http://ru.wikipedia.org/wiki/Java_Desktop_System
весьма любопытно, к сожалению не имел возможности попробовать.

Популярность java

Сам долго мучался, на кой я 3 года на обучение потратил?
Потом как-то зарегился на явабле (форумы), теперь до сих пор пару раз в месяц приходят предложения на ява-девелопера. (самое прикольное - 5000$ + пансион семьи в Киеве на должность руководителя).
А тормоза в GUI - исключительно косяки в его написании. Очень часто используются готовые элементы, с кучей примочек по умолчанию. Золотое правило - создал объект swing'a - отруби всё лишнее.
А ещё Ява - самый классный язык для дома и самопальных сетей. Очень удобно, можно писать всякую фигню, которая даже при самом минимуме отладки работает хоть как-нить, юзать пару недель и забивать, когда станет ненужна. По сравнению с сями, написание+отладка в экстренные сроки проходят на ура.

З.Ы.: а ещё как-то видел какую-то игрушку, написанную ещё для 1.2, писана была какими-то прибалтами...

А вот если

А вот если скажем стоит такая задача. Написание программы для администрирования компьютеров в локальной сети. Т.е. на одном компе ты видишь "скриншотинг" другого компа. (Другой вещает "скриншотами" на твой. Возможно пожимая каждый скриншот + выделяя разницу.)

В одной из книжек по Яве я вычитал, что можно приложения даже компилировать в машинный код (не в байт-код). Получается, что раз в машинный код можно, то собсно Ява с т.з. производительности ничем ни хуже С++?? хотя как-то смешно звучит, если честно (-:

Насколько потянет такой проект Ява?

По поводу

По поводу реализации - то что ты описал возможно сделать, средствами стандартных библиотек.

По поводу байткода - соблазнительно, но есть некоторые проблемы, в частности с Windows решениями для создания exe.
http://itc.ua/article.phtml?ID=27747&IDw=33&pid=52

Как уже не однократно говорилось выше, производительность вычислений в джава давно уже на уровне c++, работа с элементами ООП:
- создание экземпляров классов
- выполнение перегруженных методов
и тп быстрее чем в ++.

Уже достаточно в этой тебе вроде сказали про технологию.
Ты пиши давай :) поменьше вопросов побольше дела.

((-: Спасибо! Ну

((-:
Спасибо!
Ну тогда приступаемс..!

А вот если

А вот если скажем стоит такая задача. Написание программы для администрирования компьютеров в локальной сети. Т.е. на одном компе ты видишь "скриншотинг" другого компа. (Другой вещает "скриншотами" на твой. Возможно пожимая каждый скриншот + выделяя разницу.)
Был где-то текст про то, как пишут hello world различные люди. Так вот самый мега unix гуру пишет hello world путем сборки примера hello world, входящего в поставку gcc. Это я к тому, что таких программ уже очень и очень много.

>>Один факт

>>Один факт кроссплатформенности уже сколько всего даёт...! Но интерфейсы приложений на Яве, честно говоря, отвратительные. Может мне такие уж попадались..

От таки с кросплатформенностью у жабы, (ИМХО) как бы хуже чем у того же перла. Бо перл он и в африке перл. А движков явы уйма, и каждый со своими тараканами. Имхо единственное что на яве легко "кроссплатформировать" так это программу уровня хелловорд.

неправда, очень

неправда, очень даже всё с этим в порядке.
Sun не позволяет ни кому выходить за рамки строго оговоренные спецификацией.

Если использовать стандартные библиотеки, программа 100% кросплатформенна, даже перекомпилировать не нужно.

Замечательно пишуться на ней кросплатформенные web-сервера и работающие на них j2ee приложения. Так что для определённой предметной области уровень очень неплохой.

>>неправда,

>>неправда, очень даже всё с этим в порядке.
Угу. Именно поэтому все джентушники до сих пор юзают закрытые движки от айбием и сана. Вместо заявленного пару лет назад свободного и открытого dev-java/kaffe. При всем при том что интерпретаторы на сях писать одно удовольствие.

ЗЫ.
Да, хелловорд на каффе идет на ура. Он у меня до поры до времени штатным движком стоял.

Quote:все

Цитата:
все джентушники до сих пор юзают закрытые движки от айбием и сана

- во первых я не юзаю от ibm и blackdown, все программы которые я писал на джава работали без нареканий под sunjdk на разных платформах. (blackdown ставил чисто ради интереса)
Во вторых у sun в плане java - другой принцип, не надо сравнивать её с OSource & Платным софтом. Здесь закрытость проекта сделана для того, чтобы он не был испорчен обилилием растущих как грибы компиляторов и jvm.

Мне бы к примеру не хотелось ни чуть, чтобы получилось и с этим языком так же как и с C++, .. он когда то как кросплатформенный позиционировался. И далеко ушёл он в эту сторону благодаря тысячам дополнительных библиотек и компайлеров? Зато уж компиляторы под него все кому не лень делали, всем раздолье было + проявляя себя библиотеко-писатели добили в конец кросплатформенность.

Некросплатформенность джава - чушь, sun надавала по рукам microsoft которая хотела в .NET сделать свой диалект, и остальным надаёт если будут лезть.

Творения же от ibm, bea (jrockit насколько я помню) и им подобных создаются специально для определённых целей, как правило для своих серверов: вёбсфера и weblogic в частности, для них компании разработали собственные jdk, чтобы сделать свой сервер как можно быстрее, выжать всё что только можно из виртуальной машины/оборудования на котором она работает.
И даже не смотря на это! web приложения базирующиеся на технологии j2ee почти всегда запускают именно в окружении сановской машины, т.к другие не проходят сертификацию, и время на разбирательство в их багах никто тратить не хочет. (исключение пожалуй, иногда составляет IBM)

Это я всё говорю к тому, что есть одна единственная сертифицированная jvm, которая гарантированно будет работать на той платформе для которой она портирована, и причём везде одинакого, соответственно для кода скомпилированного под неё выполняется 100%-е правило переносимости на уровне байткода.

Товарищи, к чему обычному юзеру ibm, blackdown, bea jdk?
Чем Sun не угодила? вы не платите денег за продукт, уже давно как fetchrestricted сняли, даже лицензию читать не надо перед закачиванием, исходники прикладных интерфейсов идут с каждой jdk (они аж 16 метров весят в архиве), что ещё нужно то?
Мне будет безумно сложно поверить, что у кого то возникнет реальная необходимость править ядро jvm, смысл какой? это не прикладной софт, это виртуальная машина, поправив баг в ней у себя вы уберёте проблему только у себя. Это ни как не поможет вашей программе работать на чужом компьютере.

Давайте не отвлекаться от темы топика и не говорить пустых мыслей вслух.

PS. Вобщем сейчас насколько я понимаю всё идёт к тому чтобы полностью открыть исходных код.

>>Все программы

>>Все программы которые я писал на джава работали без нареканий под sunjdk на разных платформах

:))

Это потому, что для жава платформа и есть jvm. Во всей этой кросплатформенности есть одно слабое звено - вы не управляете всем миром. А следовательно не знаете на чем будет крутится ваша программа Ситуация та же что и с жаваскриптом, и в ближайшее время вряд ли изменится к лучшему. Каждый норовит исполнить код по-своему.В результате разработка реалного кроссплатформенного (с т.з явы - работающего на разных жвм) приложения ничуть не проще чем работа под куте или wxgtk. Реально получается что я могу легко писать на жаве только внутри своего предприятия. Но тут мне, увы, кроссплатформенность не нужна, бо винда + intel.

PS
Ежели бы это было так просто, опытный жавакодер помер бы с голодухи, однозначно.

Я не понимаю с

Я не понимаю с чем ты спориш.

Есть sun-jvm & sun-jsdk & sun-j2ee.
Они есть под огромное колличество платформ, распостраняются бесплатно. Являются стандартными инструментами для выполнения/разработки программ на соответствующем языке.

Поясни какие есть причины их не юзать?

Хочу напомнить, что я ни разу не упомянул что java это повсеместно здорово!
Я сказал сразу, что для определённого вида задач технология очень удобна, а для больших web приложений просто жизненно необходима зачастую, т.к позволяет сосредоточиться на реализации очень сложной бизнес логики не увязая в деталях.

Цитата:
Во всей этой кросплатформенности есть одно слабое звено - вы не управляете всем миром

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

Возможно уважаемый будете утверждать что анализ строковых данных проще на с++ делать чем на perl? а для хранения данных надо вообще использовать текстовые файлы который тоже замечательно можно создавать и аналазизировать средствами с++, вместо хранения в СУБД? и что задачи по типу 8-ми ферзей на С++ проще решать чем на prolog?

У каждого языка, у каждой технологии есть своя область применения, не надо искать недостатки в java применяя его в качестве языка для создания системных утилит. Возможно недостатки стоит искать в головах тех людей которые язык так применяют?

>>Я не понимаю с

>>Я не понимаю с чем ты спориш.

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

>>Есть sun-jvm & sun-jsdk & sun-j2ee.

По причине закрытого кода движок от сана не используется повсеместно, основная фишка явы так и осталась "добрым намерением". Ситуация c переностимостью явы имхо хуже чем с яваскриптом. Какой движок в телефоне вашего ваш соседа? А в вашем сотовом телефоне? А в телефоне вашей подруги? Поставте им санжывыем - ежели сможете.

>>У каждого языка, у каждой технологии есть своя область применения

Согласен на сто. На перле проще из мусора инфу тянуть. На пыхпе проще всего текстовики динамить. Кстати задачу по типу восьми ферзей вам придется решать именно на том языке, который существует для определенной заказчиком платформы. Хоть на асме ежели более ничего нет. Одно не понятно - гдеж такая обасть в которой нужно нечто:
1)не особо кроссплатформенное
2)не особо шустрое
3)безобразно прожорливое

ЗЫ
Яву по возможности стараюсь не применять никак. Особенно для системных утилит.

Похоже на то

Похоже на то что у тебя был не приятный опыт общения с j2me, либо знакомые негодавали, в этой области действительно ситуация не очень хорошая.

Но тема про приложения для десктопов, я на этом и основываюсь говоря о кросплатформенности, в этом смысле она 100%-ая в пределах jvm, а учитывая то, что я говорил выше - об отсутствии каких либо адекватных причин помимо религиозных, заставляющих не юзать творение от sun на десктопе и сервере - этого вполне достаточно.

Цитата:
1)не особо кроссплатформенное
2)не особо шустрое
3)безобразно прожорливое

По поводу всего выше перечисленного я уже писал в этом посте достаточно, повторяться не буду. Отнюдь не всегда то что ты указал является истиной.

По поводу же

Цитата:
Одно не понятно - гдеж такая обасть в которой нужно нечто ..

- область приложений уровня крупного предприятия, с очень серьёзной бизнес логикой, и высокой ценой ошибки. Предприятия настолько серьёзного что есть возможно покупать 20-ти процессорные машины именно для подобных приложений.

QT

у явы есть какие-нибудь преимущества перед C++/QT ?
В QT библиотека классов огромная. пишется все с полпинка.
проблем с указателем значительно меньше чем при использовании чистого си или C++. соответственно время на отладку минимальное.
родные интерфейсы. никаких тормозов. полная переносимость на уровне исходного кода на Win, Unix, Mac.
Так что я не вижу у Java никаких преимуществ перед QT/C++.

Преимущества

Преимущества есть. Не то, чтобы какие-то резковыделяющиеся, но:
- С++ это всё-таки С++, к программисту он куда менее дружественен, даже по сравнению с С, не то что с Java
- С++ нужно компилировать, и везде по-разному. У меня, например, куча проблем была с компиляцией qt4-opensource-win32 с помощью MinGW. А чтобы компилировать не MinGW, нужно покупать qt-commercial ($6000 всё-таки). И даже в этом случае проблемы с компиляцией не исчезают :)
- Qt нужно перекомпилировать под каждую платформу, для которой выпускается продукт. Порой приходится это делать у заказчика.
- Размер qt приложения даже с shared либами (10-20 метров минимум)

Java (преимущества для десктопов, с веб qt бесполезна):
- язык... не даст вам простой возможности сделать всё через ж. Даже если у вас это получится - исправить недолго. Даже в клипсе есть куча тулзов по рефакторингу джава-кода.
- компилировать вам это надо всего 1 раз. На своей банке.
- получаете весь продукт максимум в 1мб-1.5мб (не включая ресурсы и прочую лабуду).
- JVM на десктопе встречается гораздо чаще, чем qt, а дистрибутив сейчас занимает 12 мб под винду (любой юзверь скачает)

Quote: С++ нужно

Цитата:
С++ нужно компилировать, и везде по-разному. У меня, например, куча проблем была с компиляцией qt4-opensource-win32 с помощью MinGW. А чтобы компилировать не MinGW, нужно покупать qt-commercial ($6000 всё-таки). И даже в этом случае проблемы с компиляцией не исчезают :)

ничего не надо покупать... http://sourceforge.net/project/showfiles.php?group_id=49109

Цитата:
язык... не даст вам простой возможности сделать всё через ж. Даже если у вас это получится - исправить недолго. Даже в клипсе есть куча тулзов по рефакторингу джава-кода.
- компилировать вам это надо всего 1 раз. На своей банке.

Ну почему, Почему? OpenOffice при компиляции требует jdk-1.4?

Re: Quote: С++ нужно

ArtSh написал(а):

ничего не надо покупать... http://sourceforge.net/project/showfiles.php?group_id=49109

ну, учитывая то, что это не разрабатывает не Trolltech, а sf.net используя qt-opensource, просить денег за приложения сделанные на этом не получится. Ну и supportа никакого не получить.

ArtSh написал(а):
Ну почему, Почему? OpenOffice при компиляции требует jdk-1.4?

а этому парню java нужно просто отрезать. Это пережиток прошлого (специально посмотрел, для чего там java - accessibility и ещё какие-то приблуды). При этом он в оперативе сжирает +60Мб просто так. Работал под виндой и работаю под гентой без этой опухоли.

Quote: просить

Цитата:
просить денег за приложения сделанные на этом не получится. Ну и supportа никакого не получить.

Если Вам это необходимо, сперва найдите деньги на платную версию Qt, где всё это есть.

Цитата:
а этому парню java нужно просто отрезать.

А как же преимущество джавы для десктопов? Или преимущество есть, но не для ОО? И тем более не понятно зачем отрезать, если "язык... не даст вам простой возможности сделать всё через ж. Даже если у вас это получится - исправить недолго. "

Re: Quote: просить

ArtSh написал(а):
Если Вам это необходимо, сперва найдите деньги на платную версию Qt, где всё это есть.

Или использовать java, что гораздо дешевле :)

ArtSh написал(а):
А как же преимущество джавы для десктопов? Или преимущество есть, но не для ОО? И тем более не понятно зачем отрезать, если "язык... не даст вам простой возможности сделать всё через ж. Даже если у вас это получится - исправить недолго. "

Преимущество java для десктопов на ооо оценивать не стоит :) Как живущий в россии, ничего кроме java-IDE и lotus Notes на java я не видел, поэтому укажу только на IntelliJ IDEA - лучшая java среда, которая с головой покроет любые потребности девелопера занимает меньше 100мб, и Visual Studio+Vusial Assist рядом не валялись, это нужно просто увидеть. Кстати, работая на eclipse я не испытал никаких проблем с переездом на дженту, которые касаются переноса С и Java проектов, это к вопросу о кросплатформенности. Других таких мощных кросплатформенных средств разработки я не видел :)

А про язык посмотрите мой предыдущий коммент.

Цитата:
Цитата:
Цитата:
просить денег за приложения сделанные на этом не получится. Ну и supportа никакого не получить.

Если Вам это необходимо, сперва найдите деньги на платную версию Qt, где всё это есть.

Или использовать java, что гораздо дешевле :)

И сколько стоит суппорт у джавы?

Цитата:
Преимущество java для десктопов на ооо оценивать не стоит :)

А на чём стоит? Вы предлагаете на "IntelliJ IDEA", но я например не собираюсь ставить её на свой ДЕСКТОП только для того чтобы посмотреть. Я ещё могу понять Azerues, но то что было мной процитировано остаётся в силе: если язык такой хороший что не даёт писать плохо, и плохо написанное легко исправляется, то почему OOo использует jdk-1.4?

Re:

ArtSh написал(а):
И сколько стоит суппорт у джавы?

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

ArtSh написал(а):
Цитата:
Преимущество java для десктопов на ооо оценивать не стоит :)

А на чём стоит? Вы предлагаете на "IntelliJ IDEA", но я например не собираюсь ставить её на свой ДЕСКТОП только для того чтобы посмотреть. Я ещё могу понять Azerues,

Не ставьте, вас ведь никто не заставляет. Как связана java и ваши сложности по установке чего-то там? Java приложений я видел не так уж и много, и навскидку из хороших вспомнил только idea, для тех, кому интересно посмотреть на нормальное java-приложение. А если вы к их числу не относитесь, то к чему тогда эти вопросы?

ArtSh написал(а):
но то что было мной процитировано остаётся в силе: если язык такой хороший что не даёт писать плохо, и плохо написанное легко исправляется, то почему OOo использует jdk-1.4?

Что-то я не пойму. java есть java. это язык программирования такой, общего назначения. ООО это софтина, которая что-то там делает. Где-то в ООО используется как-то javа (ооо написано вовсе не на java, а осталось оно там видимо с давних времён, когда он ещё был starofficeом). Разве кто-то запретил в ооо использовать java?
Зачем? Понятия не имею. Опытным путём доказано, что без java он точно так же работает, почти никакого функционала не теряет, кроме того ещё и памяти хавает поменьше. Вот поэтому я и говорю - java в ооо ни при делах, и судить о java по ооо - как о пингвинах по карасям.

Quote: В самом

Цитата:
В самом худшем случае - стоимость вашего времени, потраченного на починку.

Ну так для опенсорсэдишн аналогично!

Цитата:
Суть в том, что написанное на java приложение можно спокойно продавать без дополнительных проходов и отчислений

Продавать приложение - можно, ограничивать в правах - нет.

Цитата:
Как связана java и ваши сложности по установке чего-то там?

Ей не место на десктопе.

Цитата:
это язык программирования такой, общего назначения.

Ну так что мешает (например Вам, если не трудно) взять и написать патч, чтобы ОО собирался с последней версией джавы? К слову о кроссплатформенности, а почему ОО не собирается с последней версией джавы?

Цитата:
Разве кто-то запретил в ооо использовать java?

А выше Вы предлагали её отрезать от ОО...

Цитата:
Опытным путём доказано, что без java он точно так же работает, почти никакого функционала не теряет, кроме того ещё и памяти хавает поменьше.

Это же опенсорс! Напишите соответствующий патч на любом другом языке общего назначения...

Это ваше

Это ваше целиком субъективное мнение. Смотрите.

Цитата:
- С++ это всё-таки С++, к программисту он куда менее дружественен, даже по сравнению с С, не то что с Java

что это значит? :) Для меня к примеру Java - менее дружественный язык.

Цитата:
- С++ нужно компилировать, и везде по-разному. У меня, например, куча проблем была с компиляцией qt4-opensource-win32 с помощью MinGW. А чтобы компилировать не MinGW, нужно покупать qt-commercial ($6000 всё-таки). И даже в этом случае проблемы с компиляцией не исчезают :)

Компиляция везде одинаковая. Поверьте мне я собираю и под Linux и под Win и под Mac. все что нужно сделать - поставить пакет разработки qt. и набрать qmake;make
после этого получаем бинарник под платформу, которая нам нужна.
Проблем с компиляцией у меня не было ни разу. Если у вас они были - аргументы в студию.
По поводу компиляция Java. как-то переписывал один проект. Проблем с компиляцией у меня было гораздо больше. Но это мое субъективное мнение.
так что это тоже не аргумент

Цитата:
- Qt нужно перекомпилировать под каждую платформу, для которой выпускается продукт. Порой приходится это делать у заказчика.

В смысле у заказчика? :) так не бывает.
А то что перекомпилировать нужно под каждую платформу - тут никакого недостататка нет.
Вы думаете что скомпилировали main.class выложили его на сайтике что работает под всеми платформами? Я например под Маком. что я должен делать с этим main.class? устанавливать JVM. потом делать что-то вроде java main.class? И откуда вы знаете что он будет работатьб под маком если вы его не тестировали?
Пользователю нужно предоставлять все в лучшем виде. Если под Мак, то стандартное маковское приложение main.app
+ в любом случае под каждую платформу необходимо писать инсталяторы.

Цитата:
- Размер qt приложения даже с shared либами (10-20 метров минимум)

Ну вы что? :) Откуда такая инфа-то?
Hello world можно в 50 кило запихать. Стандартное приложение 200-300.
К примеру инсталяшка под Win, Lin и Mac у меня занимает 4.5 метра. это с static lib. ничего скачивать доставлять не нужно. будет работать как родной.

Цитата:
- язык... не даст вам простой возможности сделать всё через ж.

:) потому что он как говорилось выше воистину ООП?
И в чем в таком случае C++ недоООП? В том что Hello world можно написать как с применением ООП так и без него? В этом случае это ограничение Java.

Цитата:
- компилировать вам это надо всего 1 раз. На своей банке.

perl и php приложения вообще компилировать не нужно

Цитата:
- получаете весь продукт максимум в 1мб-1.5мб (не включая ресурсы и прочую лабуду).

не забывайте пользователю в инсталяшку напихать jvm и пр.
а для web не забывайте Tomcat.

Цитата:
- JVM на десктопе встречается гораздо чаще, чем qt, а дистрибутив сейчас занимает 12 мб под винду (любой юзверь скачает)

:) В моем окружении JVM не установлена ни на одной машине. ПОд линуксом у меня нет программ на java (не нужно вспоминать ОО. его тормоза говорят сами за себя).
QT не нужно устанавливать отдельно. Она идет либо вместе с программой. либо создается static lib. тогда пойдет на любой аналогичной ОС.

Итак. идем дальше.
1. У QT очень граммотная, структурированная документация. можете запустить assistant если на линуксе есть qt (наверняка :))
2. Производительность программ написанных на C++/QT выше чем на java (память, проц и пр.)
3. Java Апплеты. Постоянный крах браузера заставляет от них отказываться. Даже в своих веб-приложениях раньше использовали java-аплет для drag&drop закачки картинок. но вылетает раз на раз. Сейчас пекреписали все с использованием Firefox-extension.
4. Идем к веб-приложениям. согласен на java можно писать огромные веб-приложения. но только огромные, в разработке которых участвует сотня человек. где код переваливает за млн строк и пр.
Мелкие веб приложения писать на Java нецелесообразно.
во-первых, Java под себя подминает как минимум 100 метров.
во-вторых, php на серверах установлен гораздо чаще чем java. купите VDS за 150 р. с 32 метрами оперативы и винтом на 300 метров и попробуйте туда свое java webapp вотнуть. тем более установка java web-server на что-нить вроде FreeBSD является более сложной задачей для админстратора чем тот же апач с пхп.

Так что в итоге.
Преимущества QT перед Java.
1. производительность
2. хорошая дока.
3. наличие родных интерфейсов
Java пока остается для Java2Me и для огромных вебприложений.
Других объективных преимуществ пока не вижу.

Re: Это ваше

файрфокс внезапно исчез из списка процессов и убил развёрнутый коммент. Вспомню не всё.

vano написал(а):
Это ваше целиком субъективное мнение. Смотрите.
Цитата:
- С++ это всё-таки С++, к программисту он куда менее дружественен, даже по сравнению с С, не то что с Java

что это значит? :) Для меня к примеру Java - менее дружественный язык.

Это значит, вы не запорите свой собственный код из-за перемешки шаблонов, генераторов (иначе зачем вам С++ вообще) и процедурного Сишного кода. Первая моя встреча с java была переделкой java-утилитки на С, я тогда очень матерился, но это было лишь по незнанию java. Java как язык гораздо проще, чем С++. И осваивается он быстро не самыми выдающимися программистами (жена за 2 недели освоилась с коллекциями, сериализацией, swing и java2D)

vano написал(а):
Цитата:
- С++ нужно компилировать, и везде по-разному. У меня, например, куча проблем была с компиляцией qt4-opensource-win32 с помощью MinGW.

Компиляция везде одинаковая. По поводу компиляция Java. как-то переписывал один проект. Проблем с компиляцией у меня было гораздо больше. Но это мое субъективное мнение.
так что это тоже не аргумент

Вообще говоря да, это проблема недостатка опыта.

vano написал(а):
Цитата:
- Qt нужно перекомпилировать под каждую платформу, для которой выпускается продукт. Порой приходится это делать у заказчика.

В смысле у заказчика? :) так не бывает.
А то что перекомпилировать нужно под каждую платформу - тут никакого недостататка нет.

Отсутствие необходимости в перекомпилировании это только плюс
Проблемы возникают, когда нет возможности перекомпилировать под нужную платформу. Вот нет у меня мака, а заказчик работает на маках. (но это надуманная ситуация, конечно). А вот под z/OS не то что Qt и gcc нету, там C/C++ апи жутко убогое и никому ненужное, и попытка написать что-то прикладное на этом языке - удовольствие то ещё. А вот jvm под неё есть.

vano написал(а):
Вы думаете что скомпилировали main.class выложили его на сайтике что работает под всеми платформами?

Если я пишу .class, то я уверен что он отобразится, если уж не в нативном скине, то в как минимум в стандартном Metal. По крайней мере на винде, лине и z/OS это делается без заморочек.

vano написал(а):
Я например под Маком. что я должен делать с этим main.class? устанавливать JVM. потом делать что-то вроде java main.class? И откуда вы знаете что он будет работатьб под маком если вы его не тестировали? Пользователю нужно предоставлять все в лучшем виде. Если под Мак, то стандартное маковское приложение main.app
+ в любом случае под каждую платформу необходимо писать инсталяторы.

Ну, вы ведь не в объектниках продукты распространяете? Так вот и .class заворачиваются в .jar. А уж .jar даже на винде запускаются с полпинка (mime-type с командой запуска прописывается инсталлером jvm). Если уж apple такого не сделали (в чём я сильно сомневаюсь) - то это проблема apple, которая впрочем легко решается инсталлером. При том, что дистрибутивы линя комплектуются javа-машиной (и OSX наверно тоже), до инсталлятор jvm под винду весит 12мб.

vano написал(а):
Цитата:
- Размер qt приложения даже с shared либами (10-20 метров минимум)

Ну вы что? :) Откуда такая инфа-то?

например нужно вам написать программку, которая умеет подключаться к нескольким разным серверам по soap или xml-rpc. Вам для такой программы требуется QtCore.dll,QtGui.dll,QtNetwork.dll,QtXml.dll - уже 10 метров + логика. Насчёт статика не знаю.

vano написал(а):
Hello world можно в 50 кило запихать. Стандартное приложение 200-300.
К примеру инсталяшка под Win, Lin и Mac у меня занимает 4.5 метра. это с static lib. ничего скачивать доставлять не нужно. будет работать как родной.

гуёвое приложение с главным окном и десятком экшнов в .jar 17кб, но речь ведь не о таких штуковинках? :) С нативностью есть некоторые проблемы, они решаются добавлением одной строчки в main().

vano написал(а):
Цитата:
- язык... не даст вам простой возможности сделать всё через ж.

:) потому что он как говорилось выше воистину ООП?
И в чем в таком случае C++ недоООП? В том что Hello world можно написать как с применением ООП так и без него? В этом случае это ограничение Java.

C++ это переооп + С. Классами и наследованием в С++ дело ведь не кончается? Все норовят использовать шаблоны и кодогенераторы и приправлять это сишным кодом. И автоматических тулзов, которые помогают это выправлять, нету.
На java можно писать и процедурным стилем, используя только static методы, при этом у вас остаются имена классов, что способствует удобочитаемости, но это как-то не принято. И в каждую java среду встроены инструменты по рефакторингу.

vano написал(а):
Цитата:
- компилировать вам это надо всего 1 раз. На своей банке.

perl и php приложения вообще компилировать не нужно

да, но причём здесь С++, Qt? Да и perl с php интерпретируются при КАЖДОМ запросе, в отличие от сервлетов и JSP, которые при старте сервера или установки в него веб-приложения компилируются в бинарный код и встраиваются в сервер.

vano написал(а):
Цитата:
- получаете весь продукт максимум в 1мб-1.5мб (не включая ресурсы и прочую лабуду).

не забывайте пользователю в инсталяшку напихать jvm и пр.
а для web не забывайте Tomcat.

1.5 метровый .jar без ресурсов содержит в себе около сотни тысяч строк кода (интересно, сколько будет занимать инсталляшка такого же нативного приложения?).
Для homepage java неэффективна, с этим никто не спорит, но ведь за homepage и денег никто не платит. Развёртывание же веб-приложения у клиента одним инсталлером не заканчивается, размер инсталлера большой роли тут не играет.

vano написал(а):
Цитата:
- JVM на десктопе встречается гораздо чаще, чем qt, а дистрибутив сейчас занимает 12 мб под винду (любой юзверь скачает)

:) В моем окружении JVM не установлена ни на одной машине. ПОд линуксом у меня нет программ на java (не нужно вспоминать ОО. его тормоза говорят сами за себя).
QT не нужно устанавливать отдельно. Она идет либо вместе с программой. либо создается static lib. тогда пойдет на любой аналогичной ОС.

речь ведь не о ваших машинах, а клиентам, которым вы устанавливаете продукт. У меня например с opera установилась jvm, когда я о ней даже и не знал, а qt поставил (под винду еле нашёл, кстати) только когда начал под неё код писать.
У опенофиса java ни к месту. он её не использует и надо бы её отключать, тормозит он при этом так же, но хоть памяти жрёт поменьше.

vano написал(а):
Итак. идем дальше.
1. У QT очень граммотная, структурированная документация. можете запустить assistant если на линуксе есть qt (наверняка :))

Документация по Qt великолепна, это лучшее, что я видел. Проблема в том, что на документации информация о qt исчерпывается, правда есть ещё книга Бланшетт по 3ке и ещё одна по 4ке.
По java же море книг, причём лучшие экзмемпляры есть на русском языке, и большинство книг доступно в электронном виде. Помимо java в них преподносится ООП и правила хорошего кода, что весьма немаловажно.

vano написал(а):
2. Производительность программ написанных на C++/QT выше чем на java (память, проц и пр.)

Это самое распространнёное заблуждение в отношении java. И лучше бы об этом не упоминать. java приложение работает совсем не медленнее нативного кода. Оно лишь запускается долго и поэтому не подходит для мелких и системных утилит, которыми изобилуют скрипты, но и Qt в них ни к месту.
К тому же в java 1.6 ускорили gui (работаю пока с 1.5, кстати под kde gui что у java приложений, что у обычных запускаются одинаково долго, не знаю почему)

vano написал(а):
3. Java Апплеты. Постоянный крах браузера заставляет от них отказываться. Даже в своих веб-приложениях раньше использовали java-аплет для drag&drop закачки картинок. но вылетает раз на раз. Сейчас пекреписали все с использованием Firefox-extension.
4. Идем к веб-приложениям. согласен на java можно писать огромные веб-приложения. но только огромные, в разработке которых участвует сотня человек. где код переваливает за млн строк и пр.
Мелкие веб приложения писать на Java нецелесообразно.
во-первых, Java под себя подминает как минимум 100 метров.
во-вторых, php на серверах установлен гораздо чаще чем java. купите VDS за 150 р. с 32 метрами оперативы и винтом на 300 метров и попробуйте туда свое java webapp вотнуть. тем более установка java web-server на что-нить вроде FreeBSD является более сложной задачей для админстратора чем тот же апач с пхп.

С цифрам в 100 девелоперов и миллионами строк java-кода не встречался ещё. До памяти java конечно охочая. С другой стороны, представьте, что вам предоставляет обычный j2ee сервер (JBoss или Geronimo, к примеру) - сервлеты,jsp,jsf,jdbc (причём jdbc драйверы для oracle очень и очень быстрые), jms и ejb всего в 40 мегабайтах инсталляшки - всё, что только может потребоваться для разработки корпоративного приложения любого масштаба.

Ну а если админ не в состоянии поднять j2ee сервер - тогда зачем такой админ нужен? Всё, что требуется для j2ee сервера - переменная окружения, где он находится и свободный порт, который бы он слушал.

vano написал(а):
Так что в итоге.
Преимущества QT перед Java.
1. производительность
2. хорошая дока.
3. наличие родных интерфейсов
Java пока остается для Java2Me и для огромных вебприложений.
Других объективных преимуществ пока не вижу.

Итого:
1. преимущство производительности отпадает, если программу не нужно запускать по 10 раз в минуту.
2. Доки.. доки... уж по кому по кому, а по qt их не хватает
3. Наличие родных интерфейсов к java давно уже придумали. Называется это SWT, и лежит в основе eclipse :) Azarues сильно тормозит? ;) Но о swt как и о qt на постсоветском пространстве знают немногие.
4. Для разработки коммерческих продуктов на qt - придётся её купить, jvm для этих целей распространять можно бесплатно
5. Чтобы написать систему из сервера, стационарных терминалов, мобильных терминалов и веб-интефейсом вам понадобится C++,Qt,perl,PHP,asm, и язык stored proc для бд, или знание java.

Есть ещё кое-что в джава, о чём тут не упомянуто:
- garbage collection - вам не нужно удалять объекты руками, за вас это сделает gc.
- удалённая отладка. На системах, к которым у вас не доступа и которые вы не можете эмулировать (удалённый сервер к примеру) благодаря java вы можете дебажить свой код через tcp/ip. Это встроено в jvm. Нужно только собрать ваш .jar и запустить jvm с 2мя дополнительными опциями (мы так отлаживаем код на мэйнфреймах)
- встроенная система сериализации. Вам не нужно ничего придумывать, чтобы передать какие-нибудь данные или сохранить их на винт, только оформить их в виде класса и дописать ему implements Serializable.
- единый стандарт - самое важное преимущство перед любыми другими платформами. Стандарт java поддерживается ведущими собаководами.

Извиняюсь за жёсткость и скомканность, но набивать такой ответ ещё раз... очень утомительно.

Прежде чем

Прежде чем писать про преимущества Жавы перед Сями, назовите операционную систему, ядро которой писано на жаве. Поверте на слово -та же жвм писана не на жаве а на сях, причем чистых сях без плюсов. Си и жава из разных весовых категорий. Жава выполняется интерпретатором. Сишный код выполняется реальной железякой. Проблемы кроссплатформенности не в языке программирования. Они в голове программиста. Тот же опеноффис компилится с сишных сурсов что на винде, что на лине, что на маке, что на соляре (утверждение что опеноффис писан на жабе считаю в корне не верным, бо он работает даже без установленной jvm).

у опенофиса

у опенофиса вроде хелп на яву завязан - во всяком случае при компиляции ООо с USE=-java ебилд грит что справка отвалиться. А вот азуреус очень даже ничо ворочается...

Re: Прежде чем

wi написал(а):
Прежде чем писать про преимущества Жавы перед Сями, назовите операционную систему, ядро которой писано на жаве. Поверьте на слово -та же жвм писана не на жаве а на сях, причем чистых сях без плюсов. Си и жава из разных весовых категорий. Жава выполняется интерпретатором. Сишный код выполняется реальной железякой. Проблемы кроссплатформенности не в языке программирования. Они в голове программиста. Тот же опеноффис компилится с сишных сурсов что на винде, что на лине, что на маке, что на соляре (утверждение что опеноффис писан на жабе считаю в корне не верным, бо он работает даже без установленной jvm).

я не говорю что

я не говорю что Java - плохое средство разработки. у него есть свои преимущества. Но обычным пользователям сложно и неудобно работать с Java программами.
Те же java webapp гораздо сложнее в использование чем php.
на десктопе тоже самое.
Сфера применения Java, с моей точки зрения, - крупные предприятия где java-приложениями пользуются (настраивают и сопровождают) сами разработчики.
На десктопы Java пихать не нужно. Есть гораздо лучшие решения.

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".