Java полностью свободна под лицензией GPL

>По ссылке жаба сильно всосала крестам.

Да Ё-маЁ. Вот ведь прицепились-то а. С/С++ извольте сравнивать с нативными языками. Никто не пытается хай-перфоманс на яве выжимать. Просто факт - ява не так уж сильно уступает. Кроме того, ява это не просто урезанный С. Ещё раз повторяю: хватит с крестами всё сравнивать. У крестов свой сектор применения, у явы свой. Вот С в энтерпрайз применить.. посмотрю я на вас, будете как 10 лет назад ковыряться. Никто не позиционирует яву как высокопроизводительную. А если кто и пытается серьёзно сравнивать яву с С по скорости, то он теряет время зря. Сила явы не в скорости и никогда никто не позиционировал так, даже тогда когда JIT появился. Речь идёт о том что с появлением JIT перфоманс явы СИЛЬНО возрос. И только. Я не виноват что кто-то там говорит что ява быстрее С. Давайте ещё может поищем людей которые с ассемблером сравнивают серьёзно.

Разрабатывает. И довольно много. На С сама ява разумеется, компайлеры всякие и солярис + некоторое количество мелких тулов на С. Основные разработки обычно на яве. Хотя встречается кое где и перл.

>А SUN не разрабатывает на жабе?

Молодой человек, я не хочу отнимать хлеб у Вашей учительницы младших классов Марьи Ивановны. Либо Вы найдете, где я утверждал, что _ВСЕ_ разработчики на Жаве говорят, что их фетиш быстрее Ц, либо таки сядите за букварь. Идет?

>Да Ё-маЁ. Вот ведь прицепились-то а. С/С++ извольте сравнивать с нативными языками. Никто не пытается хай-перфоманс на яве выжимать. Просто факт - ява не так уж сильно уступает. Кроме того, ява это не просто урезанный С. Ещё раз повторяю: хватит с крестами всё сравнивать. У крестов свой сектор применения, у явы свой. Вот С в энтерпрайз применить.. посмотрю я на вас, будете как 10 лет назад ковыряться. Никто не позиционирует яву как высокопроизводительную. А если кто и пытается серьёзно сравнивать яву с С по скорости, то он теряет время зря. Сила явы не в скорости и никогда никто не позиционировал так, даже тогда когда JIT появился. Речь идёт о том что с появлением JIT перфоманс явы СИЛЬНО возрос. И только. Я не виноват что кто-то там говорит что ява быстрее С. Давайте ещё может поищем людей которые с ассемблером сравнивают серьёзно.

Я раб, что Вы способны мыслить адекватно и видить недостатки любимой технологии. Жаль только, что это приходиться выжимать 8 страницами флейма...

Я лишь пытался доказать что есть гораздо более медленные товарищи (питон, перл) и что ява это не самое тормознутое что может быть и нечего питоновщикам корчить кислые лица, мол вот ява тормозит и вообще гавно. А у самих какой-то жалкий цикл на полтора часа затянулся. И это в общем и есть вся моя претензия. С я приписал пока ждал когда же питон что-то родит (тот так и не родил). Это просто проба чтобы сравнить насколько же ява-то проиграет, а оказалось что проиграла то раза в 2 (не в 500 раз как кое кто). И не более.

>Я лишь пытался доказать что есть гораздо более медленные товарищи (питон, перл) и что ява это не самое тормознутое что может быть и нечего питоновщикам корчить кислые лица, мол вот ява тормозит и вообще гавно. А у самих какой-то жалкий цикл на полтора часа затянулся. И это в общем и есть вся моя претензия. С я приписал пока ждал когда же питон что-то родит (тот так и не родил). Это просто проба чтобы сравнить насколько же ява-то проиграет, а оказалось что проиграла то раза в 2 (не в 500 раз как кое кто). И не более.

Ну Вы же понимаете, что проигрыш в 2 раза например в геймдеве это слишком много.

>Я лишь пытался доказать что есть гораздо более медленные товарищи (питон, перл)

В питоне и перле на нативные функции делегировано почти все, сам интерпретируемый код является как бы скотчем склеивающим нативный функционал. В Яве же работает почти исключительно JVM кроме тонкого интерфейса с несущей ОС.

> Ну Вы же понимаете, что проигрыш в 2 раза например в геймдеве это слишком много.

Вот потому на яве игры и не пишут :) я не против Сей, я сам с Сями имел дело не меньше чем с явой. Я исключительно против предвзятого отношения. И против твердолобости некоторых товарищей: есть реальный результат, так ведь надо было гнать про переполнение и прочую пургу. А как показал что переполнение ни при чём, так сразу вопрос отпал, а меня тут же обвинили в сравнении с С :D

>Вот потому на яве игры и не пишут :) я не против Сей, я сам с Сями имел дело не меньше чем с явой. Я исключительно против предвзятого отношения. И против твердолобости некоторых товарищей: есть реальный результат, так ведь надо было гнать про переполнение и прочую пургу. А как показал что переполнение ни при чём, так сразу вопрос отпал, а меня тут же обвинили в сравнении с С :D

Ну так никто и не говорит, что жава не подходит для сайтеков и прочего ынтырпрайза.

> Доказательство состоятельности явы является хотя бы то что вся стандартная библиотека написана на самой яве (кроме тех частей которые без JNI написать невозможно, например, чтение из сокета, открытие файла..).

Библиотеку сжатия-разжатия джипега можно на яве написать (там файлы открывать не надо, а надо битики двигать туда-сюда)? Пожалуста, ссылку сюда на исходный файл в JDK, написанный на Божественной Яве!!!

И не обертку вокруг сишной ./jre/lib/i386/libjpeg.so -- а именно явовский исходник!!! (кстати, само существование lib/i386/libjpeg.so не на какие мысли не наводит?)

> вся стандартная библиотека написана на самой яве

Вот это типично сановский маркетоидный пиздежь!!! Жду ссылку на исходник.

В самой яве по дефолту есть jpeg кодек, но там код гибридный. Если хотите чистую java, смотрите библиотеку JAI, там с битиками работают и работает прилично. Я лично её использовал и никаких трудностей не ощутил. Вот уж не сомневайтесь, битики двигать мы могЁм :)

> Вот это типично сановский маркетоидный пиздежь!!! Жду ссылку на исходник.

Пиздежа нет. Вы вырвали кусок откуда-то. Речь идёт о бОльшей части (~90%). Всякие классы типа String, списки, деревья и прочая дребедень реализована на яве.

ссылку не найду, но файлы зовутся JPEGCodec, JPEGImageEncoderImpl.java, jpegimageencoderimpl.c (!).

В JAI лезть не буду.

А вот такие строчки в ./jre/lib/i386/libjpeg.so не на какие мысли не наводят:

../../../src/share/native/sun/awt/image/jpeg/jpegimagedecoderimpl.c

> Если хотите чистую java, смотрите библиотеку JAI, там с битиками работают и работает прилично. Я лично её использовал и никаких трудностей не ощутил. Вот уж не сомневайтесь, битики двигать мы могЁм :)

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

эта вся грязь продолжается, как я понимаю, от зависти. есть фанаты некоторых языков. они понимают что эти языки/технологии сливают джаве во многом, но не признают этого никогда.

ведь к чему постоянно идёт? к крикам "java тормозит!". на реальных примерах доказать не могут, ищут некие тесты оторванные от реальности. прог на C++ тормозящих мало? рассыпающихся тормозных прог на питоне мало? как напишешь - так и будет работать.

> Если хотите чистую java,

Я не хочу чистой явы. Это может хотеть только человек, поверивший в сановский маркетоидный пиздежь.

Томми, перепиши libjpeg.so на чистой яве, чтобы работало быстрее сишного исходника -- тогда и поговорим.

А пока что Божественная Ява почему-то юзает Отстойный С... а всякие там Томми просят каких-то доказательств того, что ява тормозит.

>ведь к чему постоянно идёт? к крикам "java тормозит!". на реальных примерах доказать не могут, ищут некие тесты оторванные от реальности. прог на C++ тормозящих мало? рассыпающихся тормозных прог на питоне мало? как напишешь - так и будет работать.

Вроде уже все присутствующие сошлись на том, что Жаба Ц по скорости не конкурент. Вы один все еще хотите нам что-то сказать?

>эта вся грязь продолжается, как я понимаю, от зависти. есть фанаты некоторых языков. они понимают что эти языки/технологии сливают джаве во многом, но не признают этого никогда.

>ведь к чему постоянно идёт? к крикам "java тормозит!". на реальных примерах доказать не могут, ищут некие тесты оторванные от реальности. прог на C++ тормозящих мало? рассыпающихся тормозных прог на питоне мало? как напишешь - так и будет работать.

Вот уж точно. Твердолобость необыкновенная. Ну да, ну работает jpeg-кодер быстрее будучи написанным на сях, но есть кодек чисто явный, который хотя и медленее, но работает ( не в 500 раз уступает ;) ).

>Томми, перепиши libjpeg.so на чистой яве, чтобы работало быстрее сишного исходника -- тогда и поговорим.

Напишите хоть какую-то реализацию jpeg'a. Хотя бы на С.

>Томми, перепиши libjpeg.so на чистой яве, чтобы работало быстрее сишного исходника -- тогда и поговорим.

Справедливости ради стоит сказать что java.lang.BigInteger & java.lang.BigDecimal написаны на Яве. Факториал от 100.000 оно рассчитывает за 40 сек.

Сначала было так:

> Доказательство состоятельности явы является хотя бы то что вся стандартная библиотека написана на самой яве (кроме тех частей которые без JNI написать невозможно, например, чтение из сокета, открытие файла..).

Потом оказалось что все же 90%...

> Пиздежа нет. Вы вырвали кусок откуда-то. Речь идёт о бОльшей части (~90%).

Я утверждаю, что эти 90% -- это интерфейсная обертка, которую хочешь ты или не хочешь -- придется все равно писать на яве, а работу делают те самые 10%, и то, что они на сях -- это как раз одно из доказательств тормознутости явы.

java.math.BigInteger конечно же.

>Я утверждаю, что эти 90% -- это интерфейсная обертка, которую хочешь ты или не хочешь -- придется все равно писать на яве, а работу делают те самые 10%,

4.2

>а работу делают те самые 10%,

Да что вы говорите? что-то мне помнится я юзал JPEG где-то пол года назад, до этого полтора года назад. сразу видно, вся ява держится на нём.

> Справедливости ради стоит сказать что java.lang.BigInteger & java.lang.BigDecimal написаны на Яве. Факториал от 100.000 оно рассчитывает за 40 сек.

<лирическое_отступление> Абсурд, я тебя не понимаю. Это ты кажется недавно плакался, что на плюсах что-то типа BigInteger не написать -- ибо тормозит?

Кстати, плюсы под вещички типа BigInteger -- самое то. <лирическое_отступление/>

Ну и что что написаны? Бенчмарк будем делать? Во сколько раз ява сольет сям или плюсам? Или потом снова скажем что "производительность в тестах ничего общего не имеет с производительностью настоящих программ" ?

>Справедливости ради стоит сказать что java.lang.BigInteger & java.lang.BigDecimal написаны на Яве. Факториал от 100.000 оно рассчитывает за 40 сек.

Кстати, а какой длины в Жаве эти BigInt? Что-то мне подсказывает, что результат нахождения факториала от ста тысяч в 64битный инт не влезет.

>>Я утверждаю, что эти 90% -- это интерфейсная обертка, которую хочешь ты или не хочешь -- придется все равно писать на яве, а работу делают те самые 10%,

> 4.2

Тогда объясни, почему глупые сановские разрабы не выкинут нафиг эти 10% ? Это ж блин сколько критики в адрес сан после этого можно избежать!

> Кстати, а какой длины в Жаве эти BigInt? Что-то мне подсказывает, что результат нахождения факториала от ста тысяч в 64битный инт не влезет.

Несложно догадаться что он произвольной длины.

произвольной:

public class Main3 {
    public static void main ( String[] args ) {
        
        BigInteger i = BigInteger.valueOf( Long.MAX_VALUE );
        for( int j = 0; j < 100; ++j )
            i = i.add( i );
        System.out.println( "max long is " + Long.MAX_VALUE );
        System.out.println( "i = " + i );
    }
}


cy6ergn0m@localhost ~/NetBeansProjects/JavaApplication12 $ java -jar dist/JavaApplication12.jar
max long is 9223372036854775807
i = 11692013098647223344361828061502034755750757138432
cy6ergn0m@localhost ~/NetBeansProjects/JavaApplication12 $

>перепиши libjpeg.so на чистой яве, чтобы работало быстрее сишного исходника -- тогда и поговорим.

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

реальной жизни:

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

>Тогда объясни, почему глупые сановские разрабы не выкинут нафиг эти 10% ? Это ж блин сколько критики в адрес сан после этого можно избежать!

Да потому что быстрее работает. НО: 1. Большая часть работы в чисто явных классах и тут не поспоришь, ввод/вывод не настолько интенсивен, а время сборки мусора не так велико, если не навыделять тучу объектов. 2. Ничто не мешает реализовать тот же джпег на яве, но это будет медленее, да ещё и ресурсы съест эта разработка.

>Абсурд, я тебя не понимаю. Это ты кажется недавно плакался, что на плюсах что-то типа BigInteger не написать -- ибо тормозит?

Это тут причем? Предъява была к тому что биттрах на жаве не пишется и все JRE - это биндинги к библиотекам на Си. Я показал что за редким исключением это не так.

>Кстати, плюсы под вещички типа BigInteger -- самое то.

Я запрещаю в коде на С++ использовать перегрузку операторов и семантику значений и конструктор копирования и оператор= не в private части, так что без разницы.

>Ну и что что написаны? Бенчмарк будем делать? Во сколько раз ява сольет сям или плюсам?

Раза в два-три. Возможно меньше.

А что-то в тех же сорцах линукса так много ассемблерного кода? не всё ведь там реализует те вещи которые в С сделать невозможно. Просто кое кто (gcc) временами генерит ТАКОЕ говно, что волосы дыбом. Так что не надо рассказывать что С прям тоже былые и пушистые. Есть у всех слабые места.

>Кстати, а какой длины в Жаве эти BigInt? Что-то мне подсказывает, что результат нахождения факториала от ста тысяч в 64битный инт не влезет.

Конечно не влезет - там 456.575 десятичных разрядов.

> кто по потреблению памяти вырывается вперёд? часто это именно C++ программы, а не Java.

почему тогда сан не выкинет нафиг libjpeg.so ?

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

А может потому, что не хватило сил переписать всё на Java, а оказалось легче всего использовать ГОТОВОЕ_И_ПРОВЕРЕННОЕ решение? А?

P.S.
Вон, PNG вроде бы на чистой Java кодируется.

> Просто кое кто (gcc) временами генерит ТАКОЕ говно, что волосы дыбом.

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

> А может потому, что не хватило сил переписать всё на Java, а оказалось легче всего использовать ГОТОВОЕ_И_ПРОВЕРЕННОЕ решение? А?

А почему щас не заменили на Гораздо Более Скоростное И Безопасное Решение, Написанное На Божественной Яве? вон кибергном пальцем указывл на библиотечку...

> Вон, PNG вроде бы на чистой Java кодируется.

Это не отменяет того, что джипег не на яве. Да и если без компрессии, то хоть на bash можно написать. (а компрессия наверно там -- вызов либки libzip.so или аналогичной, гы-гы-гы :-)

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

да вот скомпилируйте что-нить типа float x, phi=....

x = sin(phi) * cos(phi) + tan(phi) / sin(phi);

и посмотри какое говно с точки зрения ассемблерщиков он сгенерирует.

Это конечно не ядерный код. Ядерный код вы можете сами посмотреть.

>А почему щас не заменили на Гораздо Более Скоростное И Безопасное Решение, Написанное На Божественной Яве? вон кибергном пальцем указывл на библиотечку...

>а компрессия наверно там -- вызов либки libzip.so

% ls -all /usr/local/jdk1.6.0/jre/lib/i386
total 6676
drwxr-xr-x   8 root  wheel     1024  7 июн 13:10 ./
drwxr-xr-x  17 root  wheel     1024  7 июн 13:10 ../
drwxr-xr-x   2 root  wheel      512  7 июн 13:10 client/
drwxr-xr-x   2 root  wheel      512  7 июн 13:10 headless/
-rwxr-xr-x   1 root  wheel     6423  7 июн 12:51 jexec*
drwxr-xr-x   2 root  wheel      512  7 июн 13:10 jli/
-rw-r--r--   1 root  wheel      689  7 июн 12:50 jvm.cfg
-rwxr-xr-x   1 root  wheel    79400  7 июн 12:59 libJdbcOdbc.so*
-rwxr-xr-x   1 root  wheel     4200  7 июн 12:59 libattach.so*
-rwxr-xr-x   1 root  wheel   718030  7 июн 12:59 libawt.so*
-rwxr-xr-x   1 root  wheel   523996  7 июн 12:59 libcmm.so*
-rwxr-xr-x   1 root  wheel   204461  7 июн 12:59 libdcpr.so*
-rwxr-xr-x   1 root  wheel    43153  7 июн 13:01 libdeploy.so*
-rwxr-xr-x   1 root  wheel    21533  7 июн 12:59 libdt_socket.so*
-rwxr-xr-x   1 root  wheel   809768  7 июн 12:59 libfontmanager.so*
-rwxr-xr-x   1 root  wheel   214281  7 июн 12:59 libhprof.so*
-rwxr-xr-x   1 root  wheel    98313  7 июн 12:59 libinstrument.so*
-rwxr-xr-x   1 root  wheel    20748  7 июн 12:59 libioser12.so*
-rwxr-xr-x   1 root  wheel    46259  7 июн 12:59 libj2gss.so*
-rwxr-xr-x   1 root  wheel    12693  7 июн 12:59 libj2pcsc.so*
-rwxr-xr-x   1 root  wheel    82836  7 июн 12:59 libj2pkcs11.so*
-rwxr-xr-x   1 root  wheel     6145  7 июн 12:59 libjaas_unix.so*
-rwxr-xr-x   1 root  wheel   197315  7 июн 12:59 libjava.so*
-rwxr-xr-x   1 root  wheel    27201  7 июн 12:59 libjava_crw_demo.so*
-rwxr-xr-x   1 root  wheel    87813  7 июн 13:01 libjavaplugin_jni.so*
-rwxr-xr-x   1 root  wheel   334389  7 июн 13:01 libjavaplugin_nscp.so*
-rwxr-xr-x   1 root  wheel     4977  7 июн 12:59 libjawt.so*
-rwxr-xr-x   1 root  wheel   323990  7 июн 12:59 libjdwp.so*
-rwxr-xr-x   1 root  wheel   223767  7 июн 12:59 libjpeg.so*
-rwxr-xr-x   1 root  wheel     7793  7 июн 12:59 libjsig.so*
-rwxr-xr-x   1 root  wheel   346340  7 июн 12:59 libjsound.so*
-rwxr-xr-x   1 root  wheel    36397  7 июн 12:59 libmanagement.so*
-rwxr-xr-x   1 root  wheel  1247196  7 июн 12:59 libmlib_image.so*
-rwxr-xr-x   1 root  wheel    98988  7 июн 12:59 libnet.so*
-rwxr-xr-x   1 root  wheel    39498  7 июн 12:59 libnio.so*
-rwxr-xr-x   1 root  wheel    14411  7 июн 12:59 libnpt.so*
-rwxr-xr-x   1 root  wheel     4584  7 июн 12:59 librmi.so*
-rwxr-xr-x   1 root  wheel   351684  7 июн 12:59 libsplashscreen.so*
-rwxr-xr-x   1 root  wheel   146663  7 июн 12:59 libunpack.so*
-rwxr-xr-x   1 root  wheel    60784  7 июн 12:59 libverify.so*
-rwxr-xr-x   1 root  wheel    38233  7 июн 12:59 libzip.so*
drwxr-xr-x   2 root  wheel      512  7 июн 13:10 native_threads/
drwxr-xr-x   2 root  wheel      512  7 июн 13:10 server/
drwxr-xr-x   2 root  wheel      512  7 июн 13:10 xawt/
%
Наверно потому, что эти библиотеки — части JVM.

> Предъява была к тому что биттрах на жаве не пишется и все JRE - это биндинги к библиотекам на Си. Я показал что за редким исключением это не так.

Не было у меня предъявы __именно_ по битовым операциям на яве -- я про битики сказал только для того, чтобы объяснить, что libjpeg можно и на чистой яве написать -- в отличие от например libnio.so, которое обязательно на С.

>компрессия наверно там -- вызов либки libzip.so или аналогичной, гы-гы-гы :-)

не знаете, не говорите.

см. java/util/zip/ZipOutStream.java

*ZipOutputStream.java

> Наверно потому, что эти библиотеки — части JVM.

А почему части JVM -- это эти библиотеки, написанные на Опасном И Тормозном С, а не Божественные Программы, Написанные На Божественной Яве ?

>>компрессия наверно там -- вызов либки libzip.so или аналогичной, гы-гы-гы :-)

> не знаете, не говорите. см. java/util/zip/ZipOutStream.java

Я сказал "наверно", ибо не знаю, какая компрессия в PNG.

Но мудрейшему не мешало бы объяснить, зачем сан включает в JRE libzip.so ?

> да вот скомпилируйте что-нить типа float x, phi=.... x = sin(phi) * cos(phi) + tan(phi) / sin(phi); и посмотри какое говно с точки зрения ассемблерщиков он сгенерирует.

И в чем же будет говно? Можно поподробней?