Linux за българи: Форуми

От скоро забелязвам, че никой ама никой не обича Java-та. Искам да попитам защо. Сигурно 4-5 човека ми казаха, че било супер голяма простотия, имаше даже изречение от рода: Java е C# в праисторията... Да не пиша и останалите коментари.
Искам всеки, който е писал или поне е запознат с Java-та да ми каже, какво не му харесва. Защо не е подходяща за писане и т.н. Не ми се четат изречения от рода, че най-доброто било C++, C и т.н.

Аз лично харесвам JAVA като програмен език но вече има по добри алтернативи

На мен ми е тромава за писане (прекалено много дълги думи, а не обичам да ползвам IDE-та, които да ми довършват думите) и четене на кода, освен това има няколко софтуера, написани на Java, които направо ме изприщват с това колко тежко вървят. Иначе е лесен език, учи се бързо и се помни (може и цяла година да не бараш нищо на Java, като се наложи да напишеш нещо бързо ще си спомниш), но на мен не ми харесва стилът й. Но това е мое лично мнение, аз така ги усещам нещата, може би и на база сравнение с други езици :)

Лично мое мнение: да сравниш C++/C  с Java е неуместно, защото това са 2 съвсем различни неща, подходящи за съвсем различни цели.

Все едно да сравниш Python с assembler...

Аз лично харесвам JAVA като програмен език но вече има по добри алтернативи

Като например?

@bop_bop_mara - Благодаря за отговора, всъщност темата е и малко породена от теб защото знам, че не харесваш Java-та.
@Ivshti - казах, че не ми се четят такива постове, ако имаш мение за Java-та пиши, ако имаш мнение за C/C++ пиши - но не в тази тема!
@tyuio pls да не започваме. Исках мнения за Java, не за по-добри алтернативи.

Аз реално не смятам че ще излезе нещо освен флейм. Аз харесвам идеята на джава и поносимостта и което за С# са пълни глупости (не ме занимавайте с моно), Не смятам че е тежка за добри компютри от новото поколение а и тя може да се оптимизира. 
Наистина не разбирам на какво се дължи омразата към нея?!

Добре де, и флейм да е - но нека поне е флейм на тема Java. Аре ако пък всички я харесвате кажете какво ви харесва. И понеже вече казахме, че ще е флейм нека направя едно сравнение. Всъщност не съм го направил аз но след дебати се достигна до извода, че в C# има get и set методи, а в Java-та трябва ти да си пишеш твои методи за достъп до private променливи.
Плюс ли е, минус ли е - не знам - то дали ги има или ще си ги пишеш само за мен в момента не е от голямо значение, но момчето ми изтъкна още аргументи против Java-та и в защита на C#. task_struct и той не я харесва, да не споменавам и още хора от ФМИ които са я учили и не я харесват.

То ясно, че може да се оптимизира, ама никой не го прави. Както казах, тя е ужасно лесен за научаване език, но това си има своите негативи, защото така се намират много хора дето да знаят Java и малко, които да пишат добре на нея. Това пък води до много софтуер на Java, голяма част от който е супер зле написан и неоптимизиран.
Иначе съм чувала, че някакви самолети щели да им пишат софтуера на Java, даже май го били написали донякъде, ама се оказало, че като кажеш на garbage collectora да мине да сбере боклука, той всъщност не се включва веднага, а по някаква си своя схема. Та се оказало, че самолета тъкмо ще трябва да каца, като му се пуска garbage collector-а и всичко замръзва, докато той си свърши работатат. Съответно харата се отказали да ползват Java :)
Друга случка - една популярна софтуерна компания в стремежа си да има най-много програмисти, след 1ви курс обра на работа почти всичките ми колеги, които не си бяха взели ООП (с Java), за да им пишат на Java - е какво може да очакваме от продуктите на тая фирма :)
Аз винаги съм си мислела, че за всяка програма трябва да се подбира правилният, най-подхождащият й език. Само че това обикновено не се спазва и хората избират да речем Java поради други причини (на такова могат да пишат, не им се занимава с друг език, звучи по-гъзарско. т.н.). И когато софтуерът не е написан на подходящия език, отнасят го както софтуера, така и езика (единият защото е лошо написан, другият, защото възпитава в лоши навици :) ).

Надявам се че няма твоите колеги да пишат софтуера за самолетите  ;D ;D ;D ;D ;D

  Вярно е,че С# има някои предимства спрямо Java (напр. в Java
няма деструктори,не знам как никой по-горе не написа за това)
 , само че С# е продукт на Майкрософт и върви без проблем май
само под бозата, а това само по себе си е сериозен недостатък...

Т.е. изтъкваш предимствата на Java платформата, че върви на всички ОС-и. Това е хубаво.

Да това е предимство, но работи само ако има готова виртуална машина.

Ако няма не работи... >:D

Да това е предимство, но работи само ако има готова виртуална машина.

Ако няма не работи... >:D

"готова" - какво означава това? Да не искаш да кажеш инсталирана?

Преди време се пробвах да науча Java ама ми се стори голяма хамалогия. Незнам от къде изхождат тези, които казват, че Java е лесна. Направих си една съпоставка, написах една елементарна програмка на java и на c++. Оказа се, че тази програма се написва на c++ много по-лесно, и много по-бързо. От тогава изоставих Java и се ориентирах на c++ и до сега не съжалявам за избора си. Не открих един свястно направен компилатор, който да компилира байт кода на Java до машинен код. От друга страна, които иска да пише мултиплатформен GUI софтуер спокойно може да комбинира примерно Qt и c++. Иначе Java има прекрасно IDE - Netbeans, може би едно от най-добрите, които съм ползвал.
С тези собственически амбиции на ORACLE не се знае и какво е бъдещето както на Open Office, MySQL така и на Java. Видяхме вече какво направиха с ODF плъгина.

Общо за Java:

Java (чете се "джава") е програмен език. Java се появи преди известно време. По-точно преди 3 години. "Авторите" на Java са американската фирма Sun. Тук е интересно да се спомене, че както повечето "творения" на Sun, Java не блести с "нещо" много голямо на пръв поглед. Например, въпреки че сървърите и работните станции на Sun никога не са били най-мощните за момента (като на Digital или HP например), то те са доста предпочитани и използувани.

По принцип Java е интерпретатор. Тук незапознатите веднага ще кажат "Това е крачка назад". Но Java не интерпретира p-код (като Basic например). Java интерпретира машинен код. Този машинен код обаче не е за никоя конкретна машина, той е за JVM (Виртуална машина на Java). JVM е измислен "супер-risk" стеков процесор, със само няколко регистъра и с много малко инструкции. (Преди известно време Sun представи "реален" JVM - процесора Java_Chip. Той обаче не е предназначен за компютри, а за TV, радио, офис техника, кредитни карти и т.н.). Java машинния код може да се компилира до машинен код за конкретна машина за части от секундата. Това е така, защото "компилацията" се свежда до размяна на едни машинни инструкции с други. Тези компилатори се наричат JIT (Just in time).

JVM може да се намери като отделна програма (java.exe), като част от друга програма (Netscape Fast Track Web Server), в Web Browser (Netscape Navigator, Ms Internet Explorer, IBM Web Explorer, Sun Hot Java), в някой OS (Linux, OS/2)

Sun обещават да създадат истински компилатор за Sun-Spark и 80x86 до една година, но това не е чак толкова важно.
К'во "печелим"?

Java e многоплатформен
той транслира JVM кода. Това е възможно за много процесори и операционни системи. Java код, разработен на PC например, ще тръгне на всяка друга. Това може да не е важно за някой офис приложения, но е много важно за всички Интернет/Интранет приложения. Един потребител може да започне със Windows 95, след време да премине на Windows NT или OS/2, а след като и тази операционна система не му задоволи изискванията, той може да премине на CISK/UNIX или RISK/UNIX. Във всичкото това време той ще може да ползува един и същи програмен продукт. Друг пример може да е потребител, който има различна техника, от Windows 95 и Mac/OS, през Windows NT, UNIX до големи enterprice UNIX сървъри. Този потребител би могъл да работи с един и същ програмен продукт на всичките тези машини.

Java прилича на C++
"Истинският програмист" на C++ може да премина на Java за броени дни. Напоследък все по-често се появява софтуер за автоматичен трансфер между C++ и Java. За съжаление той е полезен за трансфер само на алгоритмите, но транслирания код, радко може да се компилира директно:))
Според автора който все още предпочита Object Pascal пред C++, в Java са премахнати всички неща които са спорни във C++, и са добавени нови възможности, които никога не са били възможни във C++ (като лесни за работа String, тип boolean, предаване на параметри по адрес и др.) Тук е момента да се каже, че в Java има и нереализирани неща (като липсата на възможност за наследяване на constructor-ите на обектите, липсата на destructor-и на обектите, невъзможността за директно сравняване на String-ове, някой доста странни операции като
Date d = new Date();
System.out.print(d);
и др.)

Java е наистина обектно-ориентиран
Тук е важно да се отбележи, че за разлика от привидно обектно ориентираните езици като Power Boulder, New Era, Arc View Avenue и "др. от този сорт", Java е истински обектно ориентиран език, със всички възможности като наследяване, полиморфизъм и т.н. Недостатък е липсата на destructor, но тя се компенсира до някъде от gc (garbage collector, събирач на боклуци). Също е много важно да се отбележи, че Java "идва" с много класове, не само за визуален интерфейс (като Power Builder, Delphi или Visul C++ и др.), но и такива за паралелни процеси, достъп до бази данни, работа със данни в паметта и мн.др. Ползуването на тези класове е от особено значение, когато предаваме своята програма по Internet, т.к. тези класове са при клиента и мрежовия трафик се намалява значително. Това спомага и за сигурността на данните.
Много е важно да се отбележи, че Java използува собствените си класове (т.е. ние може да ги пренапишем) за неща като зареждане на системните класове от диска (а защо не от мрежата?), зареждане на картини GIF и JPEG (а защо не и някакъв наш формат?) и т.н.
K'во "губим" с Java?

Java е бавен
Java e бавен, даже понякога отчайващо бавен. Не трябва да се забравя обаче, че той е напълно 100% преносим.

Понякога Java не е достатъчно стабилен
Докато въпросът за скоростта не е толкова важен стабилността на дадена програма е нещо от първостепенно значение. Java е идеален за програми които работят известно време (до няколко часа), но все още не е достатъчно стабилен за сървър приложения, които трябва да работят дни, месеци даже години без спиране или изключване. Авторът лично е изпитал това когато е писал WWW сървър на Java. Въпросният WWW сървър (с "кодово" име `Octtarion`) е достатъчно бърз, но недостатъчно надежден. Въпросният сървър `забива` след 4-5 часа работа при максимално натоварване, когато оперативната памет е вече доста фрагментирана и "garbage collector", не успява да си 'свърши работата'. Ако се направи анализ обаче тези 4-5 часа биха се равнявали на 4-5 месеца в един не чак толкова натоварен Web сайт.

Относно сървърния софтуер трябва да се спомене, че Sun Microsystems са разработили "JAVA Web Server", но той се предлага на доста висока цена за такъв (около $400 - $500). Преди известно време беше разработен и безплатен SQL сървър базиран също на Java с `open source`.
Къде да използваме Java

Java може да се използува доста добре за множество цели (авторът няма пред вид 'шаренийте' по web страниците), като едни от най-добрите му качества са преносимостта и лесната разбираемост на програмния код написан с Java. Той наистина е бавен, но това много лесно може да се компенсира по различни начини.

Авторът лично смята, че Java не е подходящ за сървърен, а по-скоро за клиентски софтуер, и то при случаите на хетерогенна мрежа (какъвто е и Internet) или когато операционната система на клиента не е известна. Другото голямо приложение на Java е Java_Chip и по-точно монтирането му в кредини карти, телевизори и друга техника за бита.

//
Оригинална статия тук. ($2)

@backtolife: разбра ме погрешно. Харесвам Java, харесвам и C++. Идеята ми е че са създадени за различни цели ;)
Лично на мен Java ми харесва заради мултиплатформеността си, и заради това, че е "полу-интерпретиран" език (схемата с виртуалните машини). Не ми допада синтаксиса на езика, но това не е по вина на Java, просто не съм се сблъсквал преди с езици, които още от началото са били проектирани с идеята да са обектни.

@Ivshti да бе, тя Марчето ми каза, че съм те разбрал погрешно, но не ми се преправяше пост-а :)

Голям плюс на Java е, че може да се ползва една и съща IDE под всички операцонни системи и да се програмира на вскякви платформи за всякакви платворми.
Положителна черта също е, че се интерпретира веднага. Нямам сведения дали има възможност примерно IDE на Microsoft  за C# да се инсталира и да се ползва с успех под Linux.
Определено Java има много преимущства и ако се ползват професионалните IDE като Eclipse и най-вече Netbeans, Java става един много мощен инструмент в ръцете на опитен програмист. Java има също и изключително добро API, ако изчистят някой неща в този език в бъдеще ще е  прекрасно, но както писах преди, откакто ORACLE влязоха в играта бъдещето е малко неясно.

Извинявайте по грешка писах със стария си ник, който вече не ползвам "pikimos".

task_struct и той не я харесва

Не е вярно! Аз я мразя !  ;D

1) Мулти платформено ... друг път. Аз на С/С++ мога да пиша по-мултиплатформено ( особено с Qt :) )

2) Адски е бавна. Според мен не е нормално 1 приложение да ми пуска по 20 000 нишки за да следи 3 променливи и да иска по 1ГБ рам. Заради употребата на такива езици колкото и бърз процесор да измислят, приложенията няма да се изпълняват по-бързо.

3) Последното пренаписване на диспечъра на процесите в ядрото (scheduler) е направено, точно за да се оптимизира с цел по-бързо изпълнение на джава нишките. Дали е случайно, че го пренаписаха точно заради този език ??

The 2.6 scheduler was designed and implemented by Ingo Molnar. Ingo has been involved in Linux kernel development since 1995. His motivation in working on the new scheduler was to create a completely O(1) scheduler for wakeup, context-switch, and timer interrupt overhead. One of the issues that triggered the need for a new scheduler was the use of Java™ virtual machines (JVMs). The Java programming model uses many threads of execution, which results in lots of overhead for scheduling in an O(n) scheduler. An O(1) scheduler doesn't suffer under high loads, so JVMs execute efficiently.

- http://www.ibm.com/developerworks/linux/library/l-scheduler/

4) Езика отдалечава програмиста от компютъра. Повечето джава програмисти, с който съм говорил си нямат на идея какво е това стек, хийп и въобще какво става в паметта, колко бързо се изпълнява кода им и колко памет заема. Никой не мисли за оптимизицаии :( Явно паметта и прозосорното време са безкрайни ...

Това ми хрумна на първо време :) Ако има още нещо ще го споделя :)

Приятна вечер на всички  [_]3

На мене ми харесва, откакто видях едно IDE за разработване на софтуер, свързан с java-базиран message bus. Голяма красота, 1/5 от работата е писане на код, останалото е влачене на стрелки с мишката и рисуване на някакви UML-подобни картинки. Може да звучи малоумно, но крайният резултат беше потресаващ и не мога да си представя колко зор ще отиде, за да напишеш подобно нещо, също толкова гъвкаво, само че на C++. Щото то не е просто да имаш конектори за най-различни протоколи, да се дефинира някакъв формат на данните и да конвертираш от външния формат във вътрешния XML формат и обратно. Това имаше транзакционни наклонности примерно и доста дълги последователност от неща можеха да се rollback-ват при положение, че някаква малка стъпка пропадне. На всичкото отгоре, самият език има навика да прощава някои неща.

Е да, това е език, който предразполага към големи свинщини, но пък не бих казал че го мразя. Мразех единствено свинщината на девелоперите, които физическата памет и процесорното време за нищо ги нямаха. За тях проблеми нямаше, като се появи проблем - вдигаме хийп сайз-а и толкова. И в един момент се чудят с многото памет защо като мине колектора и всичко се влачи едва-едва. Ама те не са виновни, то това там е философия - колкото повече, толкова повече.

Понякога Java не е достатъчно стабилен
Докато въпросът за скоростта не е толкова важен стабилността на дадена програма е нещо от първостепенно значение. Java е идеален за програми които работят известно време (до няколко часа), но все още не е достатъчно стабилен за сървър приложения, които трябва да работят дни, месеци даже години без спиране или изключване. Авторът лично е изпитал това когато е писал WWW сървър на Java. Въпросният WWW сървър (с "кодово" име `Octtarion`) е достатъчно бърз, но недостатъчно надежден. Въпросният сървър `забива` след 4-5 часа работа при максимално натоварване, когато оперативната памет е вече доста фрагментирана и "garbage collector", не успява да си 'свърши работата'. Ако се направи анализ обаче тези 4-5 часа биха се равнявали на 4-5 месеца в един не чак толкова натоварен Web сайт.

Това сериозно ли?

4) Езика отдалечава програмиста от компютъра. Повечето джава програмисти, с който съм говорил си нямат на идея какво е това стек, хийп и въобще какво става в паметта, колко бързо се изпълнява кода им и колко памет заема. Никой не мисли за оптимизицаии :( Явно паметта и прозосорното време са безкрайни ...

И какво от това? Който иска ще се научи който не иска няма, това не прави един програмист добър или лош, нито програмата.

Ами и аз съм писал на Java и не я харесвам:
1) Не дава свобода (даже в идеите ѝ е всичко да е по-строго) - харесвам езици в които човек има дадена сваобода, например в C имаш свободата да работиш с паметта както ти е удобно, в Ruby и Python имаш свободата, която ти дава метапрограмирането, доката Java гледа да ограничи местата на които можеш да сбъркаш при писането на код и така ограничва свободата на програмиста.
2) Тежка е. Да, Ruby, което съм посочил по-горе е по-тежко, но както вече казах дава свобода.
3) Не ми харесва стилът на писане на Java, колкото и да е лесна и да се пише лесно, самият език е направен така, че се опитва да те кара да си структурираш и организираш кода, по начин, който не харесвам.
4) Тежка е.
5) Тежка е.
6) Бавничка е.
7) Тежка е.

8 ) Тромава е.
9 ) Мудна е.

Докато четях отговорите до тук по темата сериозно обмислях да изчезна завинаги от тоя форум. С риск да си предизвикам гнева на модераторите - по-идиотски изказвания на едно място и в някой индийски форум за програмиране не могат да бъдат събрани... И подозирам, че никой от хората, които само търкалят като латерни "Java е бавна, Java е тежка" не е разработвал нищо смислено на Java...
Аз обичам езика Java(макар и не толкова колко Ruby и Lisp например), обичам безкрайно много Java Virtual Machine, която е фондацията на половината "модерни" езици за програмиране като Clojure, Scala, Groovy, etc...

Между другото са за информация на всички дето се изказваха колко бавна е Java(което е идиотско изказване само по себе си с оглед на това, че един език не може да е бавен като език, а не ми се струваше че някой визираше виртуалната машина) - генериния от компилатора bytecode се изпълнява от JIT компилатора на Java 6 само за около 20% повече време отколкото еквивалентен С код, което е впечатляващо. При Ruby говорим за загуба на ефективност около 300 пъти в много сценарии(300 пъти, не 300%). Най-бързата имплементация на Ruby е JRuby, която върви върху JVM... Мога си продължавам така до утре, но има чувството, че каквото и да се каже тук някои хора все ще си продължават с тяхното... За Бога, братя, мислете преди да пишете :-)

"готова" - какво означава това? Да не искаш да кажеш инсталирана?

Не имам напредвид написана...

Иначе идеята не е нова - OS/390 обаче по-добре се справя с байткода -> просто при инсталация се компилира до машинен код за съответната машина.

Ето какво правят ентусиастите:
http://jnode.org/

LordBad, зачезването от форума няма да промени нечие мнение, така че е излишно действие. В крайна сметка всеки си има свое мнение, къде аргументирано, къде не чак толкова. По-добре свикни с това, че има и негативни мнения за нещата, които харесваш, вместо да бягаш от реалността :) А иначе ти, според мен, имаш принос за по-доброто име на Java, не помня някой да се е оплакал (мрънкал трайно), че Spellbook е написан на точно този език.  [_]3
Колко бавна и тежка е Java (пък и Ruby, Python и т.н.) е вечен въпрос. Независимо колко много се развива в тази посока, не може да достигне да речем C, поради особеностите на архитектурата си. Но това е нормално, това е част от "атмосферата" на езика, Java (както и Ruby, Python и т.н.) просто си има други, свои, приложения.

Най-бързата имплементация на Ruby е JRuby, която върви върху JVM...

Не бих казал: http://antoniocangiano.com/2007/02/19/ruby-implementations-shootout-ruby-vs-yarv-vs-jruby-vs-gardens-point-ruby-net-vs-rubinius-vs-cardinal/

Директен въпрос към Марчето (пък и към другите, които харесват С) - мен в училище са ме учили, че С не е обектно ориентиран, защо тогава толкова го харесвате. И за да не се отклонявам от темата за Java искам да попитам има ли нещо което може да се реализира на Java, а на C не, и обратното (само ви моля без това, че Java е преносима (JVM) и че в С можеш да си бърникаш из паметта и т.н.

Не става дума на какво е писан Spellbook(днес между другото ще пусна най-сетне версия 0.3). Просто помня времето, когато преди 5 години във форума се водеха много смислени дискусии и беше полезно човек да прекарва време тук. Напоследък като преглеждам темите - всичко е или безсмислени спорове с не особено солидна обосновка от всяка страна и предъвкване на елементарни неща, които са дискутирани по хиляда пъти. Затова и рядко пиша вече - ама тая тема като я видях - не можах да се сдържа. Аз съм сигурно съм критикувал Java (езика) повече от всеки друг - но критиката от мен е в духа - "Грануляритета на многонишковите програми можеше да е по-добър", "Ех, да имаше поддръжка на closures", "Кой идиот направи switch-а без поддръжка на низове", "Не можеха ли да сложат някакъв културен ситанксис за директно манупулиране на колекции", "Ама от getter-и и setter-и", "Кой измисли тая грешка на природата checked exceptions" и т.н. За JVM-а единственото, което ме дразни е малко големия memory footprint като boot-не, и че няма поддръжка за динамично изпълнение на методи. Много от тези неща ще бъдат оправени в Java 7, която ще излезе тази година между другото...

Та мисълта ми е следната - едно е да се впуска човек в градивна критика - друго е да повтаря едни и същи не особено верни нещо. JVM беше действително много неефективен до 1.4, в 1.6 имаше огромни подобрения в тази сфера - повечето хора, обаче, не следят, тези развития. Те просто си говорят каквото си знаят. Едно дългроработещо Java приложение поне на теория е възможно в един момент да заработи по-бързо дори от приложение компилирано директно до машинен код благодарение на това, че виртуалната машина идентифицира с времето ключовите места в приложението, кешира и оптимизира генерирания код за конкретната микроархитектура. Като компилирате едно С приложение е малко досадно да правите отделен билд за всяка възможна целева платформа за да използва човек всички възможни процесорни възможности - за това приложенията обикновено се компилират с консервативни опции, за да работят на най-много машини.

И още нещо - не обичам Java чак толкова много :-) Любовта ми към Lisp не познава граници, но ми е неприятно да чета тоя flame подобен контент и просто затова се издразних толкова. Мир, братя! (и код и бира) ;-)

@dvd - статия от 2007ма не е мерило - JRuby се развива изключително активно. Версия 1.5 е почти готова и тя се очаква съвсем да ликвидира задочния спор с MRI. Въвеждането на invoke dynamic инструкцията в JDK 7 ще вдигне производителността на JRuby в пъти - алтернативните имплементации да му мислят...

@backtolife,
Аз съм дългогодишен C/C++ програмист - на С можеш да направиш абсолютно всичко! Въпроса, обаче, е - искаш ли да си го причиниш. Хората рядко си дават сметка, че най-ценния ресурс на един програмист е неговото време и понякога е безумно да си загубиш много време за да спечелиш малко производителност. Много лоша идея е да тръгнеш да пишеш уеб или enterprise приложения на C - за леко натоварените сайтове php, ruby, python царуват(а дори и за не толкова леки), java и .net са ествествения избор за супер тежки enterprise приложения.

На Java не можеш да пишеш системен софтуер - примерно ядро на OS, драйвери и т.н., т.е. ти можеш да ги пишеш на езика Java, ама това ще трябва да си компилирал до машинен код, освен ако не намериш начин да bootstrap-неш някаква малка jvm преди да ти напали ядрото на системата. Помня, че имаше нещо такова писано на .нет, а навремето имаше и едно недоразумение JavaOS. Във всеки случай - системния софт е едно от местата, където ефективността е критична и С и асемблер се очертава да царуват там вечно. Подобно е ситуацията с игрите - никой не иска да играя Doom 6/7/8 върху виртуална машина, всеки иска максимум производителност и затова почти всички игри се разработват на C++. Всеки език и платформа си имат предимствата и минусите - важно е човек да е запознат с тях, която селектира технологиите, в който и да е нов проект.

да дам и моите 2 цента:
http://googlewebtoolkit.blogspot.com/2010/04/tale-of-two-and-more-apps.html
разглеждайки езика за програмиране като средство за изразяване на идеи и мисли, с джава можеш да обясниш много неща. подкрепям лорд–бад за мнението, но все пак създаване на език за всичко не е търсената панацея, а ние трябва да имаме инструменти за всеки материал.

'кой какво обича' се свежда по-скоро до 'кой какви интереси има' в програмирането и тук няма нищо лошо, защото ако всички обичахме С, никога нямаше да се роди скала или руби или каквото и да е. ако не ни мързеше да управляваме паметта си, никога нямаше да има gc-та и т.н. (няма да се отплесвам за теорията, че мързела е в корена на прогреса)

поздрави
нас

Цитат

Понякога Java не е достатъчно стабилен
Докато въпросът за скоростта не е толкова важен стабилността на дадена програма е нещо от първостепенно значение. Java е идеален за програми които работят известно време (до няколко часа), но все още не е достатъчно стабилен за сървър приложения, които трябва да работят дни, месеци даже години без спиране или изключване. Авторът лично е изпитал това когато е писал WWW сървър на Java. Въпросният WWW сървър (с "кодово" име `Octtarion`) е достатъчно бърз, но недостатъчно надежден. Въпросният сървър `забива` след 4-5 часа работа при максимално натоварване, когато оперативната памет е вече доста фрагментирана и "garbage collector", не успява да си 'свърши работата'. Ако се направи анализ обаче тези 4-5 часа биха се равнявали на 4-5 месеца в един не чак толкова натоварен Web сайт.

Това сериозно ли?

Цитат

4) Езика отдалечава програмиста от компютъра. Повечето джава програмисти, с който съм говорил си нямат на идея какво е това стек, хийп и въобще какво става в паметта, колко бързо се изпълнява кода им и колко памет заема. Никой не мисли за оптимизицаии :( Явно паметта и прозосорното време са безкрайни ...

И какво от това? Който иска ще се научи който не иска няма, това не прави един програмист добър или лош, нито програмата.

Ами сериозно tyuio. Статията е писана през 1998 г. (помниш в началото твърдението, че езика е на три години, нали?). По това време, ако не се лъжа версията беше 1.3 и всичко това беше наистина вярно за нея.

Въпреки всички оптимизации, за които говори многоуважавания Лорд Бед, все пак жабата си е алчна. И това не е оправдано, защото разбирате ли се били появили по-алчни езици. И все пак спасение има. За настолни машини- днес паметта е голямо количество и по-евтина от всякога. За ентрепрайза, който аз наричам енъртеймънта спасението е друго- рота кодонабивачи начело с умен водач, които изолират тесните места.

@go_fire
Еми тогава да взема да поместя и една статия за рнр3 и да кажа на програмистите какви смешници са а? Какво ме интересува какво е било преди 100 години. Миналата година си играх с опън браво 3 месеца който си е доста жаба сървърно приложение, и да ти кажа има критика само за използваемоста му но не и за начина на работа. Както знаеш моята машина не е тавана на технологиите обаче изобщо не се затрудни само дето интерфейса му беше скапан и адски не интуитивен но за това вина няма жабата. А пък за малко неща azureus да не би да е лош торент клиен даже взех да се замислям да мина изцяло ан него особенно като компа с торентите не е същия на който ги гледам вече.
Освен това какво значи тежка бе, жабата за телефони тежка ли е или онова е различно? Щом там може значи зашо и другаде да не може бъдещето да не е зад нас, мисля че е в обратна посока!
Само да мис върши сесията и лятото си обещавам да седна да почета от онази книжка за жаба дето си я купих преди години.

@backtolife - ми то на C това му е хубавото, че не е ОО :) Изобщо кой е казал, че ООП е най-великото нещо на света :) То е точно толкова велико, колкото останалите стилове за програмиране, защото всеки си има свое местенце под слънцето, където е незаменим.

Пък пак на въпроса за Java-та - еми явно хората, които не я харесват, или са попаднали на програми, за които тя е била избрана погрешно като език, и са се разочаровали и/или или пък просто се интересуват от (харесват, пишат) такъв софтуер, за който тя е неподходящ език в сравнение с някои други (да речем системен софтуер).

Понякога Java не е достатъчно стабилен
Докато въпросът за скоростта не е толкова важен стабилността на дадена програма е нещо от първостепенно значение. Java е идеален за програми които работят известно време (до няколко часа), но все още не е достатъчно стабилен за сървър приложения, които трябва да работят дни, месеци даже години без спиране или изключване.

В отговор на това ще дам един пример - Hadoop ($2). Това е гръбнака на Twitter, Facebook и Yahoo. Писан е на Java.

Java е прекрасен език и всеки, който отдели време да го научи няма да съжалява. Същото важи и за C++.  :)
Така, че ако владееш добре Java и C++ си супер. А ако към тях добавиш и Python, цена нямаш.
За да постигнеш обаче това се иска да жертваш много голяма част от времето си, да си упорит и да не се отказваш лесно, и не на последно място програмирането да ти доставя удоволствие.  [_]3

Аз харесвам Java и често пиша на този език.
Харесва ми автоматичното управление на памета.
Мнгото Абстрактни Типове Данни които вече са препрограмирани.
Интуитивният синтаксис.
Логичната конвенция за наиминуване на неща.
И куп други неща.

Като профисионалист, аз не програмирам само на Java, така че имам знания в много други езици, и ползвам това което за конкретният случай ми е най удобно, ако ще програмирам приложение за Windws * няма да взема Java, или... (зависи от приложението :D, wв момента пиша едно такова).

Който ти отговаря с такива глупости е поредният кре*ен, който само говори, и не знае нищо.

Аз харесвам Java и често пиша на този език.
Харесва ми автоматичното управление на памета.
Мнгото Абстрактни Типове Данни които вече са препрограмирани.
Интуитивният синтаксис.
Логичната конвенция за наиминуване на неща.
И куп други неща.

Като профисионалист, аз не програмирам само на Java, така че имам знания в много други езици, и ползвам това което за конкретният случай ми е най удобно, ако ще програмирам приложение за Windws * няма да взема Java, или... (зависи от приложението :D, wв момента пиша едно такова).

Който ти отговаря с такива глупости е поредният кре*ен, който само говори, и не знае нищо.

Не съм съгласна с теб. Java е един от най-простите езици.

Цитат:

"Не съм съгласна с теб. Java е един от най-простите езици."

Аз не съм програмист, или поне отдавна не се занимавам вече, ама това ми идва в повече. ЕДИН ОТ НАЙ-ПРОСТИТЕ, как може такова мнение ? Нищо лично колежке.

Не съм съгласна с теб. Java е един от най-простите езици.

щом казвашл

Малко офтопик тема ще се получи, но тъй като последната година основно се занимавам с този език ми е интересно какво мислят другите за него...
Аз лично много го харесвам. Отделен е въпросът колко е производителна тази джава... ясно е, че джава с/у С и С++ губи по този показател като език който не се изпълнява директно върху хардуерната равнина, но все пак за Големи уеб-базирани приложения какво друго ползвате? От друга страна съм наясно, че силно оптимизиран и изчистен джава код далеч не работи токова бавно, колкото се говори...
Според мен една от причините много хора да говорят за ниска производителност при джава е, това че “Лесно се учи“, ама тия дето лесно са научили джава после пишат едни приложения за чудо и приказ...

И сега нека флейма започне [_]3

Единствените хора които обичат Java са една малка фракция програмисти. Всички останали - потребители, администратори, тек съпорт, другата част програмисти я мразят.
Няма как като потребител да ми хареса едно бавно приложение което иска топ машина.
Няма как да ми хареса като администратор  като JVM e едно от най-продупчените откъм секюрити приложения (само флаша го бие)
Само феновете на нишки и гарбидж колектъри му се кефят.
Като се избуши някое Джава приложение под Tomcat - като отвориш лог / дъмп файла даже Джаваджиите не могат да разберат къде е проблема щото е заровен в 9 слоя та в десети абстракции.

Аре стига глупости, на всички им стана ясно, че Java haters говорят от гъза си тука. Никой няма идея за какво иде реч. С това че C++/Java са едни от най-големите изцепки като езици на програмиране съм напълно съгласен (особено за първия), обаче това че Java е тромаво е крайно време да престане.

Java е било тромаво едно време, когато още е нямало JIT и VM-то е било крайно неефективно. В момента обаче JVM е една от най-стабилните индустриални платформи с повече от 15 години опит. JIT кодът в много от случаите се компилира до по-бърз от този на C++, тъй като има много повече информация от C++ компилатора. Който не е съгласен с това твърдение е напълно некомпетентен по темата и няма нужда да противоречи. Java е единствено бавна при GUI приложенията, защото не използва native widgets на операционната система, ами свои собствени. Това че Java била бавна, защото се изпълнява на VM е някакъв мит от 90те. Модерните JIT компилатори са изключително ефективни, генериращи код по-добър от обикновен компилатор. Да не говорим за GC, който в много случаи е по-бърз от ръчен malloc/free! Има доста материали по темата, който не вярва може да провери. Java има други проблеми като non-value types и locality на данните, което го прави значително по-неефективно за multicore performance в сравнение с F# примерно.

А какви с ви наблюденията когато Java се използва за web приложения?
Как може да се оптимизира по-бързо да се зареждат страниците?

Къде ги четеш тези неща?

Java генерира по-бърз код от c++?!
GC е по-бърз от free?!

 :D

Ами всъщност - да, може да генерира по-добър код. Има оптимизации, които не могат да се направят в compile-time. Много прост пример:

d = a*b + c;

Ако стойностите на а и/или b не са ти известни в compile-time (демек не са константи), това ще се компилира до MUL и ADD инструкция. JIT компилатора обаче може да вземе предвид че a или b ти е равно на 0 и да ти спести умножението и събирането. Примерът е доста прост, но предполагам го илюстрира.

Що се отнася до malloc/free vs garbage collection-а - да, възможно е, поради ред причини, garbage collector-а при определени обстоятелства да ти свърши по-добра работа. Това зависи от ред неща и според мен в общият случай malloc/free е по-бърз вариант, особено ако имаш много голям heap size и GC алгоритъма се събуди да го чисти :) Но теоретично - да, възможно е. malloc() примерно може да включва system call - sbrk(), който да ти накара ядрото да ти задели памет и да я мапне в адресното ти пространство. При java, това става само веднъж в началото на изпълнението. Склонен съм да вярвам, че в общият случай malloc/free имплементацията на glibc работи по-бързо, но не мога да го подкрепя с някакви доказателства и това силно зависи от workload-а и настройките на jvm-то.

GeSHi (Java):
public class HelloWorld {
 
    public static void main(String[] args) {
        System.out.println("Hello, World");
    }
 
}

GeSHi (PHP):
echo "Hello world"

а сега открийте разликите  ;D

Ми в единия низ world е с главна буква и има запетайка пред него...

Сравняваш Java с PHP  :o :o :o...

Ми в единия низ world е с главна буква и има запетайка пред него...

+1

Ами всъщност - да, може да генерира по-добър код. Има оптимизации, които не могат да се направят в compile-time. Много прост пример:

d = a*b + c;

Ако стойностите на а и/или b не са ти известни в compile-time (демек не са константи), това ще се компилира до MUL и ADD инструкция. JIT компилатора обаче може да вземе предвид че a или b ти е равно на 0 и да ти спести умножението и събирането. Примерът е доста прост, но предполагам го илюстрира.

Това е най-малкото, което може да направи. Въпреки това няма да спечелиш много, освен ако не си в tight nested loop, което пак ще бъде hoisted. Ето една интересна статия JIT based interpreter (LuaJIT) http://article.gmane.org/gmane.comp.lang.lua.general/75426.

А GC-то е generational, рядко трябва да се обхожда целия heap. В повечето случаи мястото за short living objects се преизползва и чистенето става изключително бързо заради доброто locality на датата.

Ами всъщност - да, може да генерира по-добър код. Има оптимизации, които не могат да се направят в compile-time. Много прост пример:

d = a*b + c;

Ако стойностите на а и/или b не са ти известни в compile-time (демек не са константи), това ще се компилира до MUL и ADD инструкция. JIT компилатора обаче може да вземе предвид че a или b ти е равно на 0 и да ти спести умножението и събирането. Примерът е доста прост, но предполагам го илюстрира.

Що се отнася до malloc/free vs garbage collection-а - да, възможно е, поради ред причини, garbage collector-а при определени обстоятелства да ти свърши по-добра работа. Това зависи от ред неща и според мен в общият случай malloc/free е по-бърз вариант, особено ако имаш много голям heap size и GC алгоритъма се събуди да го чисти :) Но теоретично - да, възможно е. malloc() примерно може да включва system call - sbrk(), който да ти накара ядрото да ти задели памет и да я мапне в адресното ти пространство. При java, това става само веднъж в началото на изпълнението. Склонен съм да вярвам, че в общият случай malloc/free имплементацията на glibc работи по-бързо, но не мога да го подкрепя с някакви доказателства и това силно зависи от workload-а и настройките на jvm-то.

Доколкото се спомням JIT генерира код по време на (преди) изпълнение. За фрагмент от сорса ако вече е генериран код, при повторно му изпълнение вече се изпълнява генерирания код.
(Това е на база мой спомени от преди около 5 години. Вече не ползвам Java.)
Примера който си дал предполага генериране на код най-малко един път, защото a и b са променливи а не константи.

За сравнението със C++ на база работа с паметта... Само да припомня че в C++ мога да си напиша собствен memory pool. Така че заделяне/освобождаване на памет мога да сведа до преместване на указатели.

Всъщност често където се търси голяма производителност в код на C и C++ не се ползва malloc или new, а собствен memory pool. Например в рънтайм библиотеките на Apache (apr) и Mozilla (nspr).

Сега очаквам lkr да даде списък с популярни игри написани на Java, заради по-високата производителност и по-лесното писане в сравнение със C++. Може и Web сървъри (без да включваме неща като Tomcat и GlasFish) или браузъри. Единствените Java браузъри използвани в момента са в малките мобилни телефони, но това не е заради по-високата производителност.

Всъщност често където се търси голяма производителност в код на C и C++ не се ползва malloc или new, а собствен memory pool. Например в рънтайм библиотеките на Apache (apr) и Mozilla (nspr).

Сега очаквам lkr да даде списък с популярни игри написани на Java, заради по-високата производителност и по-лесното писане в сравнение със C++. Може и Web сървъри (без да включваме неща като Tomcat и GlasFish) или браузъри. Единствените Java браузъри използвани в момента са в малките мобилни телефони, но това не е заради по-високата производителност.

Minecraft добър пример ли е ? Или това не е достатъчно успяла игра. Вярно е че Java все още не може да се сравнява с RAW performance, но това че била бавна е абсурдно твърдение. Никъде не съм написал, че има по-висока производителност, а че в *някои* случаи JIT кодът е по-добър от този генериран от обикновен компилатор. Съответно това не е безплатно, има runtime overhead, а и трябва profiler-a да "загрее" преди да прави каквото и да е. Това е недопустимо при FPS игри, където latecy-то е от изключително значение. Да не говорим за неща като autoboxing, nondeterministic GC, reference types, virtual function inlining & co.  Факт е обаче, че Java за application/web programming е значително стабилна, дори и за server-side неща като Cassandra, Flock, etc.

Модерните JIT компилатори са изключително ефективни, генериращи код по-добър от обикновен компилатор. Да не говорим за GC, който в много случаи е по-бърз от ръчен malloc/free! Има доста материали по темата, който не вярва може да провери.

Никъде не съм написал, че има по-висока производителност, а че в *някои* случаи JIT кодът е по-добър от този генериран от обикновен компилатор. Съответно това не е безплатно, има runtime overhead, а и трябва profiler-a да "загрее" преди да прави каквото и да е. Това е недопустимо при FPS игри, където latecy-то е от изключително значение. Да не говорим за неща като autoboxing, nondeterministic GC, reference types, virtual function inlining & co.  Факт е обаче, че Java за application/web programming е значително стабилна, дори и за server-side неща като Cassandra, Flock, etc.

Само на мен ли ми се струва че не си спомняш какво си написал вчера? :)
Minecraft е частен случай. Ако не го осъзнаваш проблема си е твой. Не всяка игра е FPS. Очевидно никой не пише на Java и стратегии, дори и походови, където не е толкова важна производителността. Там „по-лесното писане“ би трябвало да помага.

Много обичам да гледам как Java феновете се отказват от думите си колко е производителна любимата им платформа и започват да говорят за стабилност като им зададеш един прост въпрос.

редакция:
Просто не успях да се сдържа :) . Който смята че термините, дето lkr е извадил от презентациите на Oracle са специфични за Java да вдигне ръка. Знам че любимият спорт на Java програмистите е да обясняват колко е по-готина тяхната платформа в сравнение със C, ама понякога прекалявате. Поне като ще сравнявате принципно различни неща си намерете някой който е във вашата пазарна ниша. Още малко някой ще заяви че Java-та на Oracle е по-готина от асемблера за ARM7, защото автоматично конвертирала double в Double.

Цитат на: lkr в May 31, 2011, 21:46

Модерните JIT компилатори са изключително ефективни, генериращи код по-добър от обикновен компилатор. Да не говорим за GC, който в много случаи е по-бърз от ръчен malloc/free! Има доста материали по темата, който не вярва може да провери.

Цитат на: lkr в Jun 01, 2011, 13:58

Никъде не съм написал, че има по-висока производителност, а че в *някои* случаи JIT кодът е по-добър от този генериран от обикновен компилатор. Съответно това не е безплатно, има runtime overhead, а и трябва profiler-a да "загрее" преди да прави каквото и да е. Това е недопустимо при FPS игри, където latecy-то е от изключително значение. Да не говорим за неща като autoboxing, nondeterministic GC, reference types, virtual function inlining & co.  Факт е обаче, че Java за application/web programming е значително стабилна, дори и за server-side неща като Cassandra, Flock, etc.

Само на мен ли ми се струва че не си спомняш какво си написал вчера? :)
Minecraft е частен случай. Ако не го осъзнаваш проблема си е твой. Не всяка игра е FPS. Очевидно никой не пише на Java и стратегии, дори и походови, където не е толкова важна производителността. Там „по-лесното писане“ би трябвало да помага.

Много обичам да гледам как Java феновете се отказват от думите си колко е производителна любимата им платформа и започват да говорят за стабилност като им зададеш един прост въпрос.

То май и ти не си спомняш, защото в първото изречение съм написал още, че смятам C++/Java за пълен провал. Толкова беше с Java "феновете". След изключването на игрите за телефони (защото явно и те са частен случай) няма какво повече да коментираме. Виждам обаче, че явно си съгласен за динамичното компилиране, ако не е така, prove me wrong.

Аз само цитирах противоречието между мненията ти. Веднъж казваш че модерните JIT компилатори генерират по-добър код от останалите, а после казваш че „в *някои* случаи JIT кодът е по-добър“. Лично аз съм съгалсен с второто твърдение, но не и с първото. Понеже и двете си ги писал ти, не мога да кажа че съм съгласен с теб :) А и темата е за Java, а не по принцип за JIT срещу нормални компилатори.

Логиката че щом се пишат много игри за малките телефони на Java ME, значи платформата е добра е като логиката че щом повечето GUI софтуер по света ползва MFC, значи това е добър GUI framework.

Като говорим за JIT че използва повече информация при компилиране, то се сетих че за C++ има profile guided optimization или PGO.

Помня че имаше версия на FireFox компилирана с PGO.

Аз само цитирах противоречието между мненията ти. Веднъж казваш че модерните JIT компилатори генерират по-добър код от останалите, а после казваш че „в *някои* случаи JIT кодът е по-добър“. Лично аз съм съгалсен с второто твърдение, но не и с първото. Понеже и двете си ги писал ти, не мога да кажа че съм съгласен с теб :) А и темата е за Java, а не по принцип за JIT срещу нормални компилатори.

Логиката че щом се пишат много игри за малките телефони на Java ME, значи платформата е добра е като логиката че щом повечето GUI софтуер по света ползва MFC, значи това е добър GUI framework.

Почвам да се съмнявам дали има смисъл да отговарям. Никъде не става въпрос колко игри се пишат като брой, твърдението беше, че Java е бавна и не става. Е щом се пишат игри за телефони (и то колко) явно е достатъчно бърза. JIT кодът винаги е по-добър, при наличието на достатъчно данни, това си е факт, практически няма начин да генерираш по-добър код с обикновен компилатор. Проблемът е, че писането на JIT компилатор е изключително трудно, особено за език като Java, затова не винаги е ефективно. Това беше цялата идея с "някои" - кодът винаги е по-добър, а тези случаи, когато не е, просто са свързани с това, че опитът е много по-малък. Въпреки това резултатите се виждат:

 - http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php
 - http://lambda-the-ultimate.org/node/3851

Темата не знам дали е за Java, тъй като Java като език не представлява нищо. Всичко идва от платформата. Нещата отидоха в посоката на JIT, за да разберат някои хора, че модерните VM-та не са това, което бяха през 90-те.

Щях да правя нещо подобно, но го намерих наготово -> Java vs. C++: The Performance Showdown ($2)
за да не си чешем езиците.

Всъщност за малко да се хвана да тествам, но ме домързя да тегля и слагам JDK.

Щях да правя нещо подобно, но го намерих наготово -> Java vs. C++: The Performance Showdown ($2)
за да не си чешем езиците.

Всъщност за малко да се хвана да тествам, но ме домързя да тегля и слагам JDK.

Тези тестове са безсмислени, авторът няма идея какво прави. JIT работи per method invocation, java methods по default са virtual за разлика от тези на C++ и още много. За да тестваш VM-to първо трябва да направиш dry-run итерации, за да може profilera да събере достатъчно данни.

И аз я мразя  >:( Целият свят е написан на С, операционните системи, виртуалната машина на Джава, JIT, ... няма ли С се срутва света, е за тва на никой не му дреме за Джава. Сега и Андроид-а ще я разкарат, щото видяха, че всички пишат на С библиотека и после я зареждат през Джавата, което създава само неудобства да избегнеш нещо излишно.
http://www.mycplus.com/featured-articles/top-10-applications-written-in-c-cplusplus/

Мисля, че това са глупави спорове. Аз примерно предпочитам C защото дава прост и удобен начин да си изразиш идеите и по същата причина ненавиждам ООП парадигмата и в частност C++ като (поне според мен) малоумна нейна реализация, обаче няма да тръгна да споря по въпроса. И да - убеден съм че JIT като идея има доста предимства и се надявам LLVM да внесе малко промени в това отношение. Примерът, който дадох е доста тривиален и тъп, съгласен съм, но нещата не опират само до това. JIT компилаторите имат повече свобода по отношение на register allocation, минимизиране на performance драми при разклонение на кода и т.н. Не виждам какъв е проблема при определени обстоятелства да генерират по-бърз код.

Сравняваш Java с PHP  :o :o :o...

Цитат на: bop_bop_mara в Jun 01, 2011, 00:36

Ми в единия низ world е с главна буква и има запетайка пред него...

+1

Да сравнявам ги ...в кръга на шегата...

Java има както предимства, така и недостатъци.

Скоро ми се наложи да направя програма, която да обработва изображения, особено важно беше, да ги смалява качествено. Оказа се, че на ява-та има много библиотеки, източници които да помогнат и т.н. От друга страна, например в QT С++, функцията, която смалява картината не дава добро качество. Оттам се започва търсене на допълнителни библиотеки като ImageMagic например. Да ама започва едно гърчене с компилиране, свързване и т.н. С ява-та намерих много кратко и просто решение. Единствения недостатък е, че консумира доста памет ако се използва Swing. А най изненадващото е, че направих някои кратки тестови програми на с с++ (пр. с wxDev-Cpp), конкурентни на ява-та, при което се оказа, че вървят по-бавно. Е, явно не съм се постарал да оптимизирам, но със съвременна виртуална машина, Java върви доста добре.

Какъв е изводът? Ще отговоря с цитат от Мусаши Миямото - самурай, победил стотици противници в двубои с мечове:
"Да нямаш любимо оръжие".
Т.е., да нямаш любим език за програмиране. Избери езикът, който е най-подходящ за решаване на задачата. Тогава ще си победител. ;)

Нещо не се чете. Последно казваш че функцията на C била по-бавна от Java?

Пробал си някакви "тестови програми на С C++" и вече реши че С++ се справя по-зле с твоята задача?!

Сортирането по метода на мехурчето и на асемблер да го напишеш пак ще е по-бавно от примерно quicksort (за големи данни).

Така че всичко зависи от алгоритъма. Езика почти няма значение в тази връзка.

На Qt функциите за скалиране си работят много добре, ако знаеш какво да им подадеш, за което си има много добра документация. Да не говорим, че може да си скалираш и с помощта на видео картата с QShaderProgram и останалите класове за шейдъри.

Категорично, ако се напише качествен код на с++, той ще работи по-бързо и ефективно от Java. Но
не дава достатъчно добър резултат. Еквивалентен код в Java дава по-добър резултат, само че, скалирането трябва да се направи на стъпки. Същия трик с QT не даде добър резултат. Еталон ми е била картина скалирана с фотошоп. Това конкретно съм тествал, а не сортиране или нещо друго. Пак повтарям, разбира се, че това може да се постигне и със с++, но се оказа, че на Java ми е по-лесно.