>- прекрасная защита от несанкционированного доступа к исходному коду

а это зачем?

Плывут параходы! Превед окодэму!

Как это зачем? Это одна из основных головных болей разработчика.

А чтобы враги не утащили "секретные технологии в форматировании исходников" ;)

это разработка не opensource.

А gcj не тем же самым занимается?

>- прекрасная защита от несанкционированного доступа к исходному коду

здесь жлобов и халявщиков не любят

какая хрень этот Excelsior JET. Все якобы "преимущества", которые описаны в аннотации к релизу, уже несколько лет не соответствуют действительности.

Во-первых, JVM от Сана имеет великолепную производительность (мне не известны программы, которым бы этой проихводитиельности не хватало). От несакционированного доступа к коду есть куда более прямые решения: обфускаторы. Excelsior не поддерживает динамической загрузки классов. В случае ошибки в программе происходит crash. Про малый размер - полное фуфло по двум причинам: Excelsior сертифицировалось на Java. Поэтому _обязано_ иметь полный набор классов на борту (JRE). При нынешних скоростях интернета, размеров винтов и носимых флэшек никого не волнуют размеры. Тем кто думает, что JRE от сана огромных размеров, скажу, что оно занимает 7 метров в запакованном виде

--седайко стюмчик

>прекрасная защита от несанкционированного доступа к исходному коду

НАФИГ!!

Полностью согласен

Два раза пробовал ЭТО.
Никокого существенного выйгрыша в производительности
не заметил.
В пустую потраченное время.
Интересно, кто и для каких целей покупает это у них
за довольно приличные деньги (900 - 3500 $) ?

> Excelsior не поддерживает динамической загрузки классов

Ерунда. Если б оно не поддерживалось, JET бы не сертифицировали.

Прежде чем кричать, неплохо бы и попробовать.
Там же дают скачать бесплатно.

Зачем на сайте http://www.opensource.ru рекламировать программы, затрудняющие доступ к исходному коду?

> куда более прямые решения: обфускаторы

Это-то как раз намного более КРИВЫЕ решения, к тому же замедляющие исполнение байт-кода.

> оно занимает 7 метров в запакованном виде

Ерунда какая-то. JRE 1.5.0_07 (jre-1_5_0_07-windows-i586-p.exe) занимает 18 мб, а SwingSet2, скомпилированный и запакованный JET-ом, готовый к установке где угодно, занимает 10 мб.

>Зачем на сайте http://www.opensource.ru рекламировать программы, затрудняющие доступ к исходному коду?

А anonymous-то дело говорит. Причем это именно реклама. Уже хотя бы в раздел коммерческого софта запостили.

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

Думаю, что в класс ускоряемых JET-ом приложений входят в основном те, которые можно скомпилировать статически полностью (т. е. не использующие активно jit). 2 lvv: зайдите в каталог samples/Bench/caffein-like для примера и собери тесты. 2 sedajko_stjumchik & lvv : Огласите пожалуйста список тех приложений, которые вы пробовали скомпилировать JET-ом, буду очень признателен.

На счет фразы "Во-первых, JVM от Сана имеет великолепную производительность (мне не известны программы, которым бы этой проихводитиельности не хватало)." Тут можно думаю много чего написать, например приложения использующие swing (jdk_home/demo/jfc/SwingSet2).

"При нынешних скоростях интернета, размеров винтов и носимых флэшек никого не волнуют размеры" Меня волнует 8), и еще несколько миллионов пользователей которые пользуются dialup-ом + которые платят за траффик.

"А gcj не тем же самым занимается?" У gcj проблема с совместимостью, т. е. далеко не любую приладу на java созданную с использованием sun jdk можно им скомпилировать.

О чем вы говорите? Разве не открытый софт скомпиленный gcc ? вы компилируете java в байт код не коммерческими компиляторами(borland/sun)? Открытый софт - это софт под открытой лицензией. И никак не скрипты. Скрипт, выложенный под собственнической лицензией не открыт! И ява байт код под такой лицензией не открыт даже если Вы его можете декомпилировать!

Что касается Ява вирутальной машины, то более тормознутой, и пожирающей ОЗУ машины трудно себе представить!

Вообще, хочу Вам напомнить, что Ява - это коммерческая разработка от САН-а, основанная на открытом обероне разработки ETH Zurich Виртом и Гукнехтом, испорченная Сишным синтаксисом, а впослвдствии оператором goto!

Что интересно, Jet также основан на компиляторе Оберона XDS, так как языки очень близки.

Именно наличие компилятора оберона позволило Новосибирской фирме XDS продавать на весь мир компилятор Java.

И никто никогда меня не убедит в том, что хорошо написанный код, скомпиленный хорошим компилятором в нативный будет уступать в скорости так же хорошоо написанному но интерпретируемому машиной. Не говоря уже о размере ОЗУ почему-то занимаемой ява машиной.

Ява хороший язык (повторюсь, скатан с Оберона) но реализация с ВМ неудачна!

Мда, чего-то ник пропал, последнее собщение anonymous (*) (11.07.2006 10:58:56) от меня (_limit_)

noch (*) (11.07.2006 11:01:17) +1

>прекрасная защита от несанкционированного доступа к исходному коду

Если оно мне будет нужно так сразу же появиться reJet как когда то появился refoxer revba и прочая подобная компания re

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

Положим "интерпретируемому машиной" - это давно не правда.

И он может уступать. Если например код порождает и убивает в процессе долгой работы большое количество обектов разного размера то работа программы без GC выполняющего heap compaction приведет к дикой фрагментации памяти.

>Если оно мне будет нужно так сразу же появиться reJet как когда то появился refoxer revba и прочая подобная компания re

О!
начинаются сбываться мечты идиота ...
пол-дела сделано - наконец-то найден главный в интернете по re-обфускаторам

Осталось только его убедить в том, что ему нужны reGCC и reAssembler
:)

> Это-то как раз намного более КРИВЫЕ решения, к тому же замедляющие исполнение байт-кода.

rose99, да вы видимо специалист по изготовлению обфускаторов? :) говорите ерунду, чесслово. как правило использование обфускаторов уменьшает размер constant pool'а, увеличивает скорость линковки классов и т.п.

> Ерунда какая-то. JRE 1.5.0_07 (jre-1_5_0_07-windows-i586-p.exe) занимает 18 мб, а SwingSet2

почитайте, что такое pack200.exe. говорю вам 7 метров! :)

--седайко стюмчик

во-первых, сдаётся, что что вы в Excelsior работает :) я не прав?

>Тут можно думаю много чего написать, например приложения использующие swing (jdk_home/demo/jfc/SwingSet2)

работает охрененно быстро. у вас что SwingSet тормозит?

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

я пробовал скомпилировать IDEA. только время потратил.

> У gcj проблема с совместимостью, т. е. далеко не любую приладу на java созданную с использованием sun jdk

GCJ - такой же изврат. да упокоится он с миром...

--седайко стюмчик

> Интересно, кто и для каких целей покупает это у них за довольно приличные деньги (900 - 3500 $) ?

Вот кто:

http://www.excelsior-usa.com/jetcustomers.html

Кстати, академическая лицензия дешевле в разы плюс несколько лицензий роздано бесплатно авторам бесплатных же программ в обмен на ссылки или case studies вроде этой:

http://www.excelsior-usa.com/jetcs00002.html

Среди пользователей - все ведущие изготовители фотооборудования - Canon, Nikon, Fuji и т.п. - интересно, для какого софта они эту штуку используют...

> Что касается Ява вирутальной машины, то более тормознутой, и пожирающей ОЗУ машины трудно себе представить!

обоснуйте, господин студент.

>Вообще, хочу Вам напомнить, что Ява - это коммерческая разработка от САН-а, основанная на открытом обероне разработки ETH Zurich Виртом и Гукнехтом, испорченная Сишным синтаксисом, а впослвдствии оператором goto!

милай! если ты мне найдешь goto в каком-нибудь серьезном Java-проекте (скажем на sourceforge.org), я тебе памятник воздвигну!

преимущество заключается в том что нет компиляции байткода при запуске. нотепад из экзамплов за 1 секунду на 300 mhz celeron стартует. производительность awt выше чуть ли не в 2 раза. все остальные показатели такие же как у sun jre или медленнее.

IMHO Excelsior идеально подходит для shareware производителей, котрым важен положительный user experience(UI) и защита. замутить защиту augmentтя байткод(каждый класс декларативно), который потом компилируется в нативный и в котором потом не приятно разбираться, что добавит кучу гемороя ломателю. к тому же есть класс программ которые без быстрого запуска никак - просмотрщики всякие... итп

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

Открытая Harmony JVM от Apache давно пускает eclipse. На моей машине (1.5mhz) elipse стартует считанные секунды Все на Harmony - благо большая часть кода из России - почитайте переписку разработчиков :)

>Excelsior не поддерживает динамической загрузки классов

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

из-за этого для того чтобы нормально статически скомпилить проги построенные на plugin architecture придется повозиться. но это в общем не проблема

кроме этого jet имеет фичу - "jit кэширование" позволяет не выполнять компиляцию более одного раза

>GCJ - такой же изврат. да упокоится он с миром...

Narod, nu chto nakinulis'? Vy prosto ne predstavlyaete kakoe kolichestvo moral'nyh urodov vokrug, kotorye krichat, chto Java - lazha i nivkakuyu ne stavyat jre (pravda v bol'shinstve sluchaev ona u nih stoit, prosto oni ob etom ne znayut). Skol'ko raz prihodilos' pisat' na c++/MFC melkie utility po etoj prichine. Inogda pisal na SWT + JET, no hochetsya Swing. Nschet skol'ko "vesit" jre, to eto kak kachat' - esli installer, to 14-15Mb, esli autoinstaller (v IE6, naprimer dlya appletov), to 6-7. Tam oni pack200 zapakovali. Jet 4.5 esli kto chital compilit vse klassy v exe, a chto ne nuzhno kladet ryadom zapakovannym - "choby ne narushat' licenziyu". Yasno, chto etim lishnij raz podcherkivaetsya marazm etoj licenzii... Lichno ya dumayu, chto, kogda, Sun otkroet Java i Jet smozhet izbavit'sy a ot etogo "doveska" "Microsoft tochno konec (c)" :-) Potomu kak mne kak razrabotchiku pofigu zapuskat' IDEA s jre ot SUN/JET/IBM... a vot pol'zovatel' on kapriznyj i luchshe uzh pust' ne vedaet na chem proga napsana...

надо jetbrains и excelcior объединиться и создать новую ОС на основе безопасного языка.

полностью согласен с noch

Вот эти дебилы покупают http://forum.vingrad.ru/
index.php?showtopic=61197

Я сделал аппликатион в Sun one Studio, компилируется и работает все
отлично.

Что можно сделать что бы другие могли им пользоваться???

Тоесть: как можно сделать из этого аппликатиона программу, которую
можно будет инсталировать на любой другой компьютер, в котором
инсталирован Windows?

Может переделать его в Setup.exe или есть другой способ?

>Я понятия не имею что надо делать!!!

>У меня есть SUN ONE STUDIO и я в нем сделал следующие:

>1 Сделал класс назвал Proba.java; >2 скомпилировал, получился Proba.class; >3 сделал еще что то, получилось Proba.jar;

>Теперь мне хочется сделать этот класс программой, но как я незнаю >Надеюсь проблему изложил понятно

И вот такие бабуины полезли с VB в Java, ибо VB.NET и Delphi.NET для них походу вообще не по силам

А вот, насчёт download size и скомпилированных приложений:

http://www.excelsior-usa.com/jetdownsize.html

> и еще несколько миллионов пользователей которые пользуются dialup-ом +
> которые платят за траффик.
В Москве безлимитный интернет через DSL стоит $21 - $25 в месяц. Для маськвичей других вообще не существует :) (за МКАДом жизни нет). Но все-таки то что в Новосибирске или вообще за Уралом цены на интернет значительно выше не слишком характерно для мирового рынка. У основных потребителей коммерческого софта все-таки траффик довольно дешевый.

>забавно слушать тех кто на не опенсоурсность ругается. менталитет эксплуататоров ПО ей богу.

еще один лор с винфаком перепутал. и откуда вы такие беретесь

>Если например код порождает и убивает в процессе долгой работы большое количество обектов разного размера то работа программы без GC выполняющего heap compaction приведет к дикой фрагментации памяти.

ну это конечно не так ... более того откровенная дурь. возьмите например оракл, который в серьезных приложениях работает месяцами без остановки или ядро любой операционки, которые работают годами без перезагрузки. при грамотном проектировании никакой фрагментации не будет, т.к. всегда есть возможность изменить стратегию выделения памяти ( например использовать пулы для некоторых объектов ). в тоже время в жабА невозможно изменить стратегию выделения памяти ( хотя есть возможность использовать пулы объектов, как например поступает javolution - но это техника ИСКЛЮЧЕНИЯ GC из жизни приложения ), что при некоторых allocation pattern-ах приводит к тому, что GC надолго "останавливает мир" выполняя очень затратную (во всех отношениях) процедуру дефрагментации хипа. вообще, пока GC работает без потдержки ядра ОС и (или) железа, само по себе обращения к памяти (некоторые операции) в системах например с generational GC очень дорогая операция - возьмите например write barrier в generational GC (каким является жабА GC) - все модификации в elder generations должны перехватываться для проверки на предмет появления ссылок на young generation.

так шта - БОЛЬШЕ МИФОФ ХАРОШЕХ И разНАХ!

>Для маськвичей других вообще не существует :) (за МКАДом жизни нет).

и пральна - естественный отбор. хочешь хорошо жить - устраивайся в Москве если сможешь, а не сможешь - в биореактор ибо все остальное (за МКАДом)- биомасса. успешный город для успешных людей.

>>Для маськвичей других вообще не существует :) (за МКАДом жизни нет).

>и пральна - естественный отбор. хочешь хорошо жить - устраивайся в >Москве если сможешь, а не сможешь - в биореактор ибо все остальное (за >МКАДом)- биомасса. успешный город для успешных людей.

uti puti, kakoi ty. nah, mne tvoya maskva nesdalas.

Excelsior -> Harmony

А ведь есть, есть приличная альтернатива - Apache Harmony, http://incubator.apache.org/ - и Новосибирцы-эксельсиорцы могли бы помочь проекту какими-нибудь своими не самыми секретными кусочками. И им хорошо, и всем - тогда правильная реклама получится.

Вот читаете же свой тред наверное... Почему бы вам не перейти на Harmony classlib с сановской?

> Вот читаете же свой тред наверное... Почему бы вам не перейти на Harmony classlib с сановской?

Чтобы клиенты огребли кучу проблем с совместимостью?

Использование сановского кода экономит массу усилий. Если программа написана по спецификации и на ХотСпоте работает, на JET должна работать и работать идентично. Если это не так - проблема в JET.

>при грамотном проектировании никакой фрагментации не будет,

Вроде своего memory manager?:) Вы удивитесь колько народу так далает. А еще больше удивитесь сколько народу так не делает.

>или ядро любой операционки, которые работают годами без перезагрузки.

http://kernelnewbies.org/KernelGlossary

buddy allocator

The memory allocation scheme used in the kernel. A vector of lists of free pages is kept, ordered by the size of the chunk (in powers of two). When a chunk is allocated, it is removed from the relevant list. When a chunk is freed back to the free pages pool, it is placed in the relevant list, starting from the top. If it is physically contiguous with a present chunk, they are merged and placed in the list above (i.e. where the chunks are twice the size), and this operation percolates up the vector. As regions are merged whenever possible, *this design helps to reduce memory fragmentation*.

Борются с мифической проблемой да?

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

Оракл я конечно не взял - я взял постгрес. И странно - там тоже свой memory manager. И даже разделы документации посвященные выделению памяти при программировании под постгрес. Тоже пацанам нефик делать? Нет бы malloc и понеслась....?

>Борются с мифической проблемой да?

не понял пойнта. описан стандартный алгоритм сегрегирующего аллокатора с КОНЕЧНО ЖЕ объединением смежных свободных блоков.

>не понял пойнта.

Поинт в том, что проблема фрагментации памяти существует. И все перечисленые "ядра операционок и прочие ораклы" парятся этой проблемой в том числе при стратегии распределения памяти - у всех свои алокаторы и т.д. В ядре более generic, который имеет дело со страницами, многие пишут просто recycling всех типов используемых структур (чем собственно и занимается javolution насколько я его одним глазом посмотрел). То есть все перечисленные долгожители в памяти делают свои телодвижения в эту сторону. И heap compaсtion в GC тоже способствует решению проблемы фрагментации памяти.

И это не миф.

>Оракл я конечно не взял - я взял постгрес. И странно - там тоже свой memory manager. И даже разделы документации посвященные выделению памяти при программировании под постгрес. Тоже пацанам нефик делать? Нет бы malloc и понеслась....?

было сказано паном r:

>Если например код порождает и убивает в процессе долгой работы большое количество обектов разного размера то работа программы без GC выполняющего heap compaction приведет к дикой фрагментации памяти.

я позволил себе не согласиться:

>при грамотном проектировании никакой фрагментации не будет, т.к. всегда есть возможность изменить стратегию выделения памяти ( например использовать пулы для некоторых объектов )

теперь вы что хотите доказать то? еще раз: при некоторых allocation pattern-ах возникает необходимость реализовать собственную стратегию выделения памяти. мысль понятна?

и чаще всего за этим стоит не проблема фрагментации ( сегрегирующий аллокатор, реализующий best-fit стратегию в 99% случаев отлично справляется с проблемой фрагментации хипа ) но увеличение скорости аллокации/деаллокации, лучшая масштабируемость и т.д. это касается в частности аллокатора, используемого постгресом.

адью

>теперь вы что хотите доказать то? еще раз: при некоторых allocation pattern-ах возникает необходимость реализовать собственную стратегию выделения памяти. мысль понятна?

Тогда мне непонятно чему вы оппонировали. Если вы согласны: что проблема существует и что heap compaction ее решает так в чем был миф?

А то что можно написать свой аллокатор так никто и не утверждал обратного. GC/HC это тоже не египетский бог, а один из вариантов решения.

>и чаще всего за этим стоит не проблема фрагментации ( сегрегирующий аллокатор, реализующий best-fit стратегию в 99% случаев отлично справляется с проблемой фрагментации хипа ) но увеличение скорости аллокации/деаллокации, лучшая масштабируемость и т.д.

Фрагментация сама по себе это просто факт. Как погода. Проблема и есть падающая скорость выделения/ухудшение эффективности использования памяти.

>Тогда мне непонятно чему вы оппонировали. Если вы согласны: что проблема существует и что heap compaction ее решает так в чем был миф?

вот к этому:

>работа программы без GC выполняющего heap compaction приведет к дикой фрагментации памяти.

конкретнее - при правильном проектировании, GC с дефрагментацией хипа не нужен. более того в подавляющем большинстве случаев обычный malloc (например тот, который есть в линаксе ) вполне достаточен.