Неугомонный Жабаскриптер настаивает, что нэйтиваппс реально всё (часть II)

С++ умеет C искаропки.

Следите за терминологией. C++ не умеет C из корбки, но умеет cdecl и stdcall из корбки. А так, далеко не всякий код на C будет валидным C++ кодом, даже если не называть переменные словами «class» и «this»

И с каких же пор гуй - необходимая для работы часть системы?

в Android-е на Java - далеко не только один GUI, но и большая часть системных сервисов. Вы вполне можете написать Android приложение на java, у которого вообще не будет никакого GUI.

И вообще, раз речь идет об андроиде, то в случае Android-а - Java - это самая необходимая часть системы.

А теперь всё то же самое только без import

Вопрос в том, можно ли написать работающий helloworld без сторонних библиотек на отдельно взятом языке. Если можно - то язык может теоретически быть native. Если нельзя - то опаньки. На жабе нельзя. Жаба не может стать нативным языком.

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

в Android-е на Java - далеко не только один GUI, но и большая часть системных сервисов. Вы вполне можете написать Android приложение на java, у которого вообще не будет никакого GUI.

Так я и на lua или там bash могу написать приложение без гуя. Это не делает ни lua, ни bash нативным языком системы.

И вообще, раз речь идет об андроиде, то в случае Android-а - Java - это самая необходимая часть системы.

Необходимая для чего? Для быстрого написания ненативных приложений? Ну да, для этого необходимая. Она там для этого и есть, тащемта. Точно так же, как в какой-нибудь FirefoxOS есть необходимый интерпретатор жабоскритпа или в линуксе баш с питоном и перлом, например.

А так, далеко не всякий код на C будет валидным C++ кодом, даже если не называть переменные словами «class» и «this»

А уж код на паскале или лиспе тем более не будет валидным C++ кодом. Но и паскаль и лисп - могут быть нативными языками, а жаба - нет.

А теперь всё то же самое только без import

А вы сможете сделать тоже самое на C, не используя #include и ассемблерные вставки, и не линкуя libc?

Вопрос в том, можно ли написать работающий helloworld без сторонних библиотек на отдельно взятом языке. Если можно - то язык может теоретически быть native. Если нельзя - то опаньки. На жабе нельзя. Жаба не может стать нативным языком.

Что считается сторонними библиотеками? Почему libc можно использовать в коде на C но нельзя в коде на Java?

Так я и на lua или там bash могу написать приложение без гуя. Это не делает ни lua, ни bash нативным языком системы.

ОК, напишите на lua или bash функциональность, сравнимую с функциональностью Android, написанной на Java, и тогда вполне сможете называть.

Необходимая для чего? Для быстрого написания ненативных приложений? Ну да, для этого необходимая. Она там для этого и есть, тащемта. Точно так же, как в какой-нибудь FirefoxOS есть необходимый интерпретатор жабоскритпа или в линуксе баш с питоном и перлом, например.

Логика? не слышали о таком? Для OS, написанной на java, java - необходимый компонент.

А уж код на паскале или лиспе тем более не будет валидным C++ кодом. Но и паскаль и лисп - могут быть нативными языками, а жаба - нет.

Ну а вот вы обьясните, в чем разница? Код на C++ или C, компилируется в промежуточный байткод. Потом этот код компилируется в нативный код. Это все происходит не заметно для пользователя, но стадия vm так-же имеется.

Код на Java компилируется в java байткод. Потом при установке Android приложения, этот java байткод компилируется в нативный код на этапе установки. Когда пользователь кликает иконку - запускается уже нативный код.

Отличия только в том, что второй шаг делается на таргет-платформе, а не все сразу за 1 вызов компилятора.

Где принципиальная разница то? :)

А вы сможете сделать тоже самое на C, не используя #include и ассемблерные вставки?

#include не нужен, а ассемблерные вставки - часть языка.

В жабе, как языке, принципиально нет никаких конструкций для общения с ядром системы. В разных вариантах жабы (и прочих принципиально ненативных языках) это общение реализуется либо сторонними классами написанными совсем не на жабе, либо жабомашиной, либо каким-нибудь JIT компилятором который тоже не на жабе писан.

Что считается сторонними библиотеками? Почему libc можно использовать в коде на C но нельзя в коде на Java?

libc вовсе не обязателен для написания helloworld.

/* test.c */
#define __NR_exit       1
#define __NR_write      4

#define my_sys_write(a,b,c)     asm( "int $0x80" : : "a" (__NR_write),"b" (a),"c" (b),"d" (c) )
#define my_sys_exit(a)          asm( "int $0x80" : : "a" (__NR_exit), "b" (a) );

void _start()
{
    char *b = "Hello world!\n";
    my_sys_write( 0, b, 13 );
    my_sys_exit( 0 );
}

Потом gcc -nostdlib -nostdinc -o test test.c

и получаем в чистом виде совершенно нативное приложение для линукса без всяких библиотек и сторонних сущностей.

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

А на жабе helloworld без чего-то написанного на нативном для системы языке невозможен. Ну жабу специально так задумали - типа такой сферический язык в вакууме, без возможности общения с системой из кода, а для всякого ввода-вывода и т.п. для каждой системы будут написаны на каких-нибудь сях классы стандартного образца, чтоб связь с внешним миром обеспечить.

ОК, напишите на lua или bash функциональность, сравнимую с функциональностью Android, написанной на Java, и тогда вполне сможете называть.

легко!

#!/bin/sh
CPUS=$(cat /proc/cpuinfo | grep ^processor | wc -l)
for i in $(seq 1 $CPUS); do 
  while : ; do : ; done & 
done

Основная функциональность в точности как у ведроида - загрузить все имеющиеся CPU на 100% и чтоб всё тормозило. Для полного счастья можно дописать ещё сжирание всей памяти. :) :) :)

Для OS, написанной на java, java - необходимый компонент.

Хочу посмотреть на OS написанную на java. ОС написанные на сях, к которым через одно место прикручена возможность писать софт на жабе я уже видел.

Где принципиальная разница то?

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

код на C, который llvm-ом сначала компилируется в платформенно-независимый байткод, и только потом llvm генирирует нативный код

Байт-код LLVM который для Clang он как раз платфрмо-зависимый. Так по краней мере в их доках было написано пару лет назад.

Если говорить на чистоту - то из Java тоже можно вызвать нативные методы, не обращаясь к промежуточным библиотекам ... Это называется JNA

JNA если педивикия нам не врет использует С-шный libffi. То есть это обертка над JNI просто более засахареная.

Это называется JNA

Кстати, вопрос: Ну и зачем же жабе нужен какой-то Java Native Access если она сама якобы Native в ведроиде? К какому такому ещё Native этот Access у Java происходит, и почему этот Native окзался внезапно не на Java?

Код на C++ или C, компилируется в промежуточный байткод. Потом этот код компилируется в нативный код.

Ну да. Возьмём самодостаточный helloworld для линукса. Оно компилируется, компилируется и на выходе получаем для x86 что-то типа

08048094 <_start>:
 8048094: push   %ebp
 8048095: mov    %esp,%ebp
 8048097: push   %ebx
 8048098: sub    $0x10,%esp
 804809b: movl   $0x80480cb,-0x8(%ebp)
 80480a2: mov    $0x4,%eax
 80480a7: mov    $0x0,%ebx
 80480ac: mov    -0x8(%ebp),%ecx
 80480af: mov    $0xd,%edx
 80480b4: int    $0x80
 80480b6: mov    $0x1,%eax
 80480bb: mov    $0x0,%edx
 80480c0: mov    %edx,%ebx
 80480c2: int    $0x80
 80480c4: nop
 80480c5: add    $0x10,%esp
 80480c8: pop    %ebx
 80480c9: pop    %ebp
 80480ca: ret    

Всё чудесно, int $0x80 - сисколл, специальная хрень которая перекидывает выполнение программы из user в kernel. Это не обязательно прерывание, это может быть особый трап, исключение, или там ещё какая процессороспецифичная хрень.

Код на Java компилируется в java байткод.

Всё бы ничего, но Java байткод - это стандартный такой список команд, среди которых нет вообще ни одной, которая могла бы хоть как-то использоваться для реализации сисколла. Вообще нет. Не предусмотрено. Что ни пиши на жабе, после компиляции будет код без сисколлов. Сисколлов нету, значит вызов системных функций, переход из user в kernel в принципе невозможен, заставить ядро системы что-то сделать для программы совершенно невозможно.

Потом при установке Android приложения, этот java байткод компилируется в нативный код на этапе установки. Когда пользователь кликает иконку - запускается уже нативный код.

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

И как же это чудесное жабоприложение сможет общаться с миром? Ни файл открыть, ни сокет создать, ни даже в serial port не погадить. Такая идиотская и бесполезная вещь в себе получается - можно чего-то там посчитать, логику какую-то реализовать, но ни исходных данных не получить, ни результат работы не вывести. Ну и в чём смысл этой охоты тогда?

Все мало-мальски распространённые системы используют как минимум 2 уровня доступа - user и kernel, и, соответственно сисколлы для переключения между ними. Ядро и только оно обеспечивает приложению ввод-вывод. На любой из этих систем приложение неспособное взаимодействовать с ядром не имеет никакого смысла. А в жабе и её байткоде в принципе не предусмотрено никаких способов вызвать сисколл.

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

Там же всё равно сишная прослойка будет.

Отчего же. Помимо CPython есть pypy, который написан на питоне чуть менее чем полностью, на си там только реализации кусочка API CPython для упрощения совместимости с компилируемыми CPython-модулями. Внутри pypy есть модуль ctypes, написанный на питоне. С помощью этого модуля можно загрузить в память последовательность байт и перейти на них как на функцию. Вот тебе и сискол без всяких сишных прослоек.

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

В винде си выполняет ту же роль, что и жаба в андроиде: средство для запуска данных «свыше» библиотечных функций.

me>> Потом при установке Android приложения, этот java байткод компилируется в нативный код на этапе установки. Когда пользователь кликает иконку - запускается уже нативный код.

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

очень странный вывод, с чего вы это вообще взяли? В исходном коде hello world тоже нет прямых syscall-ов, однако в скомпилированном x86 блобе - они внезапно появляются (если конечно мухлевать и собирать со -static, иначе их там тоже нет)

Кстати, вопрос: Ну и зачем же жабе нужен какой-то Java Native Access если она сама якобы Native в ведроиде? К какому такому ещё Native этот Access у Java происходит, и почему этот Native окзался внезапно не на Java?

А зачем C нужен ABI для вызова функций из libc?

Хочу посмотреть на OS написанную на java. ОС написанные на сях, к которым через одно место прикручена возможность писать софт на жабе я уже видел.

Почти все, что называется OS Android, написано на Java. та часть, которая на C/C++ - не так принципиально чтобы это вообще был Linux. Android-ом называют как раз «верхушку» этого бутерброда.

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

А что это меняет? :) Код исполняется напрямую процессором? Да, следовательно по вашему же определению - он нативный :)

Я все ждал, когда же до вас дойдет, то о чем вы говорите - это не «native / non native». Это разделение называется managed code / unmanaged code. И managed code вполне может исполняться как native, одно другому не мешает.

С помощью этого модуля можно загрузить в память последовательность байт и перейти на них как на функцию

Это грязный хак же! жаболюбители будут недовольны :)

В виндовых приложениях нет сисколов

Они есть в основных dll. А нативную dll из жабы можно вызвать опять же только через JNI.

А зачем C нужен ABI для вызова функций из libc?

С нужен ABI вовсе не для вызова функций из libc, он нужен для вызова функций вообще. Так язык устроен. Вызов какой-нибудь open() из libc ничем не отличается от вызова foo() из той же программы.

В жабе же, вызов нативного класса через JNI принципиально отличается от вызова жабного класса. Более того, сам жабокод этого сделать не может, в силу отсутствия в байткоде каких-то специальных команд для этого, нативный код вызывает JVM когда обнаруживает, что жабокод вызвал класс с native.

В исходном коде hello world тоже нет прямых syscall-ов, однако в скомпилированном x86 блобе - они внезапно появляются (если конечно мухлевать и собирать со -static, иначе их там тоже нет)

Во-первых, нет никакой разницы между кодом программы и кодом подгруженной libc. Во-вторых, исходный код helloworld с сисколлами на несколько сообщений выше, а в третьих, в жабобайткоде в принципе не может быть никаких сисколлов. А без сисколлов программа не может в ввод-вывод и, следовательно, совершенно бесполезна.

Это разделение называется managed code / unmanaged code. И managed code вполне может исполняться как native, одно другому не мешает.

Конечно может. Есть даже сопроцессор для ARM - Jazelle который может выполнять жабобайткод в железе. Но даже он не способен вызвать сисколл. Поэтому должна быть какая-то native прослойка, между жабопрограммой и системой, чтобы программа имела смысл. А сама программа на жабе, вне зависимости от способа выполнения жабобайткода никак не может быть native, потому что будет совершенно бесполезна без настоящей native прослойки между жабой и системой.

Почти все, что называется OS Android, написано на Java. та часть, которая на C/C++ - не так принципиально чтобы это вообще был Linux.

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

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

Я умываю руки, живите дальше в своей бронированной криокамере :)

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

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

Это что, комплекс жабокодеров, что-ли? Или какое-то профзаболевание? Вы ощущаете себя неполноценным из-за того, что приходится писать на ненативном языке ненативные приложения, что-ли? Тогда зачем вы выбрали язык, который изначально и был задуман именно как ненативный, и именно эта его особенность позиционируется как преимущество жабы?

Лол. С чего вы решили, что я пишу на Java? Ваша интуиция вас постоянно подводит. Более того, я думаю что и родную вашу «сишечку» я знаю получше вас (судя по вашему коду на гитхабе)

Лол. С чего вы решили, что я пишу на Java?

Ну если не пишете - то это тогда вообще клиника - всячески мечтать о том, чтобы неблизкий язычок где-нибудь считался native.

Более того, я думаю что и родную вашу «сишечку» я знаю получше вас (судя по вашему коду на гитхабе)

И как же это можно сишечку «знать получше»? goto и указатели не использовать, что-ли? :)

Ну если не пишете - то это тогда вообще клиника - всячески мечтать о том, чтобы неблизкий язычок где-нибудь считался native.

Как человек более разбирающися в мобильной разработке, я просто указал вам на то, что весь мир имеет в виду под термином «mobile native app». Вы можете не соглашаться, ваше право.

И как же это можно сишечку «знать получше»? goto и указатели не использовать, что-ли? :)

Ну как минимум не делать ляпов откровенных, в отличии от того, что я видел у вас

Как человек более разбирающися в мобильной разработке, я просто указал вам на то, что весь мир имеет в виду под термином «mobile native app». Вы можете не соглашаться, ваше право.

Хотелось бы увидеть как «весь мир» считает жабопрограммы native app. Я такую чушь слышал только от жабофилов, пока что.

Ну как минимум не делать ляпов откровенных, в отличии от того, что я видел у вас

И что же за ляпы откровенные, интересно? Ткните же пальчиком, может окажется что это вовсе не ляпы, а просто вы чего-то не знаете. :)

И что же за ляпы откровенные, интересно? Ткните же пальчиком, может окажется что это вовсе не ляпы, а просто вы чего-то не знаете. :)

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

не знаю, что например указатели, возвращаемые из сторонних библиотечных функций, нужно проверять на NULL?

А нахрена мне это нужно, если альтернативы действий при получении NULL в принципе нету? Нет уж, пусть оно в корку свалится, будет что gdb скормить.

Я ж говорю - вы просто малообразованы, так что ваше «обучение» мне совершенно ни к чему.

А нахрена мне это нужно, если альтернативы действий при получении NULL в принципе нету? Нет уж, пусть оно в корку свалится, будет что gdb скормить.

«Безопасный код», не, не слышали..

P.S. Извините, но дальше действительно нет смысла продолжать дискуссию. Такой феерический бред, как несете вы, может нести человек только очень далекий от разработки ПО.

«Безопасный код», не, не слышали..

Ох уж эти жабосказочки, ох уж эти жабосказочники. :)

Чтобы получить безопасный код, нужно выловить все возможные ошибки как в самом приложении, так и в низлежащих библиотеках, а не затыкать 100500 дыр всякими сраными «проверками на NULL», которые часто смысла вообще не имеют в силу особенностей работы конкретной ОС.

Проверь malloc на NULL :) Флаг в руки и барабан на шею.

И телефонная книга/gmail/сообщения запускаются наконец то быстрее 2-3 секунд? Вообще, у меня особых претензий к нексусам не было в плане производительности, но стандартные приложения всегда ужасно тормозили.