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

Дай угадаю, взял за 3к на авито 4с с расколоченным экраном и накатил сразу же самую распоследнюю ось?

обломись, купил новый в официальном магазине.

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

Я вам говорю лишь о том, что под термином «native application» в 2016 году

Определений терминов зависящих от года не бывает. Как бы вам не хотелось выгородить свои никчёмные говноязычки для говноклепания говнософта, их статус никак не изменится. Жаба - не является native ни на одной мало-мальски распространённой платформе. Это язычок для быстрого клепания приложений находящихся на самом верхнем слое системы. И как бы вы ненавидели в силу своей ограниченности говносишечку, она останется native языком для всех платформ ещё очень и очень долго. Практика показала, что даже говноплюсплюс непригоден для native, что уж о говножабе-то говорить.

Это вовсе не значит, что сишечка - супер-пупер язык на котором пишутся только божественный софт, это значит что сишечка наиболее оптимальна как базовый, основной язык для написания базового софта любой платформы. Попытки писать native на чём-то отличном от сишечки - всегда провальны. Взять хотя бы i2p - написанние софтины, которая однозначно должна быть native на жабе убило на корню всю затею. В результате, вполне годная идея осталась в зачаточном состоянии, и уже вряд-ли когда-нибудь взлетит, сколько бы не пыжились апологеты переписывая софт с одного не-native языка на другой не-native язык. Был бы демон написан сразу на сишечке, как и положено - i2p уже давно был бы искаропки в каждом роутере и каждом дистре.

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

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

Андрей, вы путаете термины Native Code и Native Application. Звучит похоже, а смысл разный. Под вторым термином весь остальной мир подразумевает то, что написано вот тут: https://www.nngroup.com/articles/mobile-native-apps/

И как бы вы ненавидели в силу своей ограниченности говносишечку,

Во первых, предлагаю вам прекратить вести себя как ребенок, и прекратить переходить на оскорбления и личности, Андрей Козин из Дмитрова.

Во вторых, мне не очень понятно, почему вы вдруг решили, что я ненавижу «говносишечку» (ваш термин). Я ничего не высказывался ни за ни против языка.

Практика показала, что даже говноплюсплюс непригоден для native, что уж о говножабе-то говорить.

Практика показала, что 99% продакшн native кода написано таки на плюсах, а не на C. Чистый C удобен тем, что язык можно выучить за 2-3 часа чтения мануала, с плюсами меньше чем 6-12 месяцев на это не уйдет.

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

Это лишь значит, что исторически так сложилось, что «все привыкли писать на С». Ну и язык очень простой, не требует длительного изучения.

Попытки писать native на чём-то отличном от сишечки - всегда провальны.

А вот и нет. Например ADA очень неплохо используется в своих специфичных областях. Технически ADA ничем не хуже C, по возможностям сравнима с C++98, но пригрывает по легкости обучения, и по распространенности.

Или например возьмем Mac OS X, большая часть OS там написана на Objective C, драйвера - на C++, и только мелкое Mach/BSD гибридное ядро - на C.

Из свежачка - Swift, Rust - довольно сильные игроки, и скоро к ним присоединится еще Kotlin Native. Все вместе я думаю они оттяпают хорошую долю у C/C++.

Взять хотя бы i2p - написанние софтины, которая однозначно должна быть native на жабе убило на корню всю затею.

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

Андрей, вы путаете термины Native Code и Native Application.

Сергей, вам бы не мешало разобраться с терминами самому. Native Code теоретически можно сгенерить даже из какого-нибудь жабоскрипта, буде написан компилятор для жабоскрипта. Поэтому рассуждать о native - не native code совершенно бессмысленно. А native application - это application которое не только native code, что само собой разумеется, но и использует native API и прочую native инфраструктуру OC.

Ну так вот, не существует ОС, в которых native API на жабе, например. В Epoc/Symbian native API был на C++. Т.е. без привлечения дополнительных сущностей невозможно было написать работающую софтину не используя C++. Так и во всех нынешних ОС - невозможно написать что-либо не используя сишечку.

Практика показала, что 99% продакшн native кода написано таки на плюсах, а не на C.

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

Чистый C удобен тем, что язык можно выучить за 2-3 часа чтения мануала, с плюсами меньше чем 6-12 месяцев на это не уйдет.

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

А вот и нет. Например ADA очень неплохо используется в своих специфичных областях.

И как же на ADA какой-нибудь gethostbyname делается? ADA прям syscall'ами дрыгает, чтоб добиться нужного, или всё же таки вызывается банальная сишечная нативная библиотечка?

Или например возьмем Mac OS X, большая часть OS там написана на Objective C, драйвера - на C++, и только мелкое Mach/BSD гибридное ядро - на C.

Ну я с MacOSX не сильно ковырялся, но если я правильно помню, то там как минмум можно писать софт только на C. Ниаких прослоек С->ObjC как в том же Epoc (C->C++) для этого не нужно, libc там совершенно привычная и без особых извращений. Впрочем, допускаю что API гуйни может быть ObjectiveC-only.

Уже прогресс, вы стали вести себя культурно, стоит напомнить, что у всех у нас есть имена, а не просто «непонятно кто, с интернета».

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

Ну так вот, не существует ОС, в которых native API на жабе...

Само по себе смешивание и сравнение «native API» и «native apps» не очень корректно, т.к. это категории разные. Равно как «свобода слова» и «свободный туалет» - корень слова один, а смысл совсем другой, и если у вась есть свободный туалет - это еще не значит. что есть свобода слова и наоборот.

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

Я к тому, что если говорить о «C vs C++» - в реальности на C уже никто не пишет, там где нужен native код.

И как же на ADA какой-нибудь gethostbyname делается? ADA прям syscall'ами дрыгает, чтоб добиться нужного, или всё же таки вызывается банальная сишечная нативная библиотечка?

Глупый ответ: никак, там где используется ADA, обычно нет интернета, и быть не может (зачем например марсианскому зонду gethostbyname?)

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

Ну я с MacOSX не сильно ковырялся, но если я правильно помню, то там как минмум можно писать софт только на C. Ниаких прослоек С->ObjC как в том же Epoc (C->C++) для этого не нужно, libc там совершенно привычная и без особых извращений. Впрочем, допускаю что API гуйни может быть ObjectiveC-only.

К чему вы это сказали? Ну можно, и что с того, что это доказывает?

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

P.S. Имя в профиле я поменял не ради вас, а задолго до этого.

Так и во всех нынешних ОС - невозможно написать что-либо не используя сишечку.

Inferno за ОС считается (: ?

Inferno за ОС считается (: ?

Ну как-то на уровне с симбианом :)

Уже прогресс, вы стали вести себя культурно, стоит напомнить, что у всех у нас есть имена, а не просто «непонятно кто, с интернета».

Свою сраную лицемерную культурку оставьте себе и себе подобным. Мне на неё глубоко насрать. Тут интернет, и глупо тащить сюда то, что не имеет тут никакого смысла.

Я лиш толкую вам что в современном мире под «native mobile app» понимают совсем не то, что вы привыкли считать.

Application может быть либо native, либо нет. Вне зависимости от всяких там годов, современности, mobile и прочего дерьмища. Если вы не осиливаете по каким-либо причинам (скудоумие, зажатие инфы производителем, отсутствие документации и пр.) написание native application для мобил на native языке, то это совсем не значит, что какая-то там жаба внезапно стала native языком.

Само по себе смешивание и сравнение «native API» и «native apps» не очень корректно, т.к. это категории разные.

native apps используют native API без всяких прослоек типа жабы. Очевидно, что если native API использует C calling convention, то хоть усрись, а native app может быть написано только на C.

Я к тому, что если говорить о «C vs C++» - в реальности на C уже никто не пишет, там где нужен native код.

Сколько системных утилит, необходимых для работы системы, написано на C++? Да ни одной.

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

Мне насрать тащем-та.

P.S. Имя в профиле я поменял не ради вас, а задолго до этого.

ЩИТО? Это вы о чём ваще? Мне совершенно наплевать, как вас зовут и как вы называете меня, если ваша культурка требует имён-фамилий, мне не составит труда общаться так, как вам кажется приемлемым. Лично мне более чем достаточно какого-нибудь юзернейма, просто чтобы отличать вас от остальных юзеров. Всё остальное в данном случае не имеет никакого смысла и значения.

Вы все не поймете одну простую вещь: сейчас смысл слова native - куда шире, чем вы привыкли считать :) на остальное - не вижу смысла отвечать.

Очевидно, что если native API использует C calling convention, то хоть усрись, а native app может быть написано только на C.

Это всё, что нужно знать о твоей квалификации.

Это всё, что нужно знать о твоей квалификации.

Прекрасно, теперь ты всё знаешь. Рад за тебя.

Ну так вот, не существует ОС, в которых native API на жабе, например

Андроид же!!1

Андроид же!!1

Ну и как же из жабы сделать int 0x80 (или там swi 0x00), например?

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

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

Java вообще никак не предусматривает assembler inline. Единственный способ это сделать - JNI, то бишь Java _Native_ Interface. А именно - написать кусок кода на _native_ языке, и уже этот кусок вызывать из жабы.

Т.к. почти все мало-мальски приличные ОС таки пользуют те или иные низкоуровневые способы связи userspace и OS kernel, то жаба ни в одной из них не может быть native.

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

А под словами «нативное андроид-приложение» везде понимается именно приложение на жабе, использующее АПИ андроида.

Нет смысла с ним спорить, он живет в своей параллельной вселенной, в которой сейчас 2000-ный год.

P.S. Вообще стоит упомянуть что Android приложениям, в большинстве своем, вообще нет нужды знать, как оно реализовано «под капотом», не говоря уже о том, что технически - можно из Android-а выкинуть Linux ядро и заменить его например «фуксией», и это все равно будет Android, а не что-то другое.

Технически возможно, практически сложно. Сама реализация платформы весьма сильно завязана на линукс (проводили эксперименты с портом андроида на freebsd, вышло сложно и бажно), да и многие приложения линкуются с нативными soшками, таскаемыми с собой.

Так можно договориться до того, что ассемблер — единственный нативный язык.

Нативным языком может быть только тот, который позволяет полноценно взаимодействовать с ядром и API системы без дополнительных прослоек. Для линукса, даже упоротого ведроидом, это plain C.

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

Теоретически, можно взять линуксячье ядро и написать к нему юзабельный API на каком-нибудь паскале, например. Будет ОС с нативным ЯП Паскаль. И жабу наверно тоже можно задрючить так, чтобы оно смогло таки дёргать сисколлы. Вот только как правильно замечено - это нафиг никому не надо. Есть нативный C, его и пользуют, ибо удобно, быстро и разумно. А жабу как нашлёпку сверху прикрутили чтоб жабомакакам было как можно проще «фигак - и в продакшн». Но нативным как был, так и остался plain C. И приложения на жабе не стали нативными даже в ведроиде.

А под словами «нативное андроид-приложение» везде понимается именно приложение на жабе, использующее АПИ андроида.

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

plain C

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

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

Просто под словом «нативный» нынче имеют в виду нативность гуя. Соответственно в андроиде нативный гуй делается на жабе, на айфоне — на обжективси.

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

Из фрипаскаля можно вызывать сисколы.

Вообще стоит упомянуть что Android приложениям, в большинстве своем, вообще нет нужды знать, как оно реализовано «под капотом»

Вот в том числе и поэтому они никак не могут быть нативными. :)

технически - можно из Android-а выкинуть Linux ядро и заменить его например «фуксией», и это все равно будет Android, а не что-то другое.

Ну вот когда выкинут, и окажется, что чтобы написать «Hello world» на сишечке надо дёргать жабоклассы - тогда и приходи. А пока жабоаппликухи так и останутся ненативными.

Вот в том числе и поэтому они никак не могут быть нативными. :)

Даже если программа написана на ассемблере и напрямую тягает сисколы, то ей тоже во многих случаях будет пофиг где её пустили: на линуксе, на фряшном линуксулаторе, или на виндовом linux subsystem.

Что теперь, эту программу нельзя считать нативной если ей пофиг на чём работать?

Ну вот когда выкинут, и окажется, что чтобы написать «Hello world» на сишечке надо дёргать жабоклассы - тогда и приходи. А пока жабоаппликухи так и останутся ненативными.

Сделать приложение без единой строчки java-кода в первых версиях андроида было невозможно. Только где-то к версии наверное 2.2-2.3 появилась такая возможность, и то по сей день она ограничена лишь доступом к сети, опенгл, звуку и некоторым устройствам ввода. Хочешь нарисовать нативную кнопочку или дёрнуть гуглосервис — будь добр, используй jni.

Ну вот когда выкинут, и окажется, что чтобы написать «Hello world» на сишечке надо дёргать жабоклассы - тогда и приходи. А пока жабоаппликухи так и останутся ненативными.

Вообще-то на андроиде уже сейчас так. Конечно можно написать приложение которое будет работать только с API ядра linux. Но это не будет Android приложением. А для реализации именно _Android_ приложения, даже если оно целиком на C или C++ (NDK позволяет это сделать), оно все равно будет дергать Java API через JNI. Единственное что можно напрямую - это графика и звук, для чего собственно это все и затевалось изначально.

Кстати вопрос, с вашей точки зрения, код на C#, который скомпилирован в CLR байткод, и потом по нему прошлись ngen-ом и получили обычный *.exe - его можно считать native или нет? :)

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

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

Ну это не только под винду. Xamarin тоже самое делает и под Android

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

В сишечке есть ассемблерные вставки, в паскале есть, да, блин в даже в лиспе есть. А в жабе - нету. Способа общаться с ядром не используя что-то процессороспецифичное пока не придумали. Поэтому жаба пролетает с нативностью.

Просто под словом «нативный» нынче имеют в виду нативность гуя. Соответственно в андроиде нативный гуй делается на жабе, на айфоне — на обжективси.

Ну иметь ввиду можно что угодно. Если objc ещё может как-то с железом работать, то жаба никак. Я охотно верю, что подсистема гуя в макоси написана на чистом objc, но вот ведроидный гуй никак на жабе написан быть не может. Если я правильно помню, там C++ во все поля. Причины, по котором гуйня не экспортируется как C++ библиотека для гуя мне неизвестны, но тем не менее жабософт даже с гуем работает через прослойку из нативных С++ библиотек.

Из фрипаскаля можно вызывать сисколы.

О том и речь. А из жабы - нельзя.

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

В винде системные сисколлы просто упакованы в ntdll.dll а те, которые касаются графики - в gdi32.dll. user32.dll и kernel32.dll пользуют ntdll.dll. Эти библиотеки и есть нативный API винды. Чисто сишный, причём.

А из жабы - нельзя.

А что по твоему делает new File()? В конечном итоге вызывает open. Как именно? Implementation detail, как и в случае вызова функции fopen() из си.

И вообще, разве inline assembler это не компилероспецифичная хреновина? В стандарт наверняка не входит.

Кстати вопрос, с вашей точки зрения, код на C#, который скомпилирован в CLR байткод, и потом по нему прошлись ngen-ом и получили обычный *.exe - его можно считать native или нет? :)

Код - нативный, ибо исполняется на процессоре, приложение и язык на котором оно написано - нет.

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

Потому что в винде нативный API - сишный.

Эти библиотеки и есть нативный API винды

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

Потому что в винде нативный API - сишный.

Чем кстати сишный апи отличается от других апи?

Вообще-то на андроиде уже сейчас так. Конечно можно написать приложение которое будет работать только с API ядра linux. Но это не будет Android приложением.

Если что-то собирается для ведроида, запускается на ведроиде и работает на ведроиде - то это ведроид приложение.

А для реализации именно _Android_ приложения, даже если оно целиком на C или C++ (NDK позволяет это сделать), оно все равно будет дергать Java API через JNI.

А потом Java API будет дёргать через JNI всякий HAL, libs/gui и что там ещё есть, которое написано на C++, а вовсе не на жабе.

Разумеется этот бутерброд не добавит ни быстродействия, ни экономичности.

Чем кстати сишный апи отличается от других апи?

Ну посмотри чем отличаются calling convention для разных языков. Даже С и С++ отличаются (в C++ как минимум this передаётся).

А что по твоему делает new File()? В конечном итоге вызывает open.

Именно. Вызывает open из libc написанной на С. Нативное приложение просто вызовет open сразу из libc, без всякой прослойки в виде жабы.

И вообще, разве inline assembler это не компилероспецифичная хреновина? В стандарт наверняка не входит.

Какая разница, входит оно в стандарт или нет, если без неё невозможно ничего написать?

В винде тогда API не сишное, а паскалевое, поскольку там для системных функций применяется не cdecl, а stdcall.

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

В винде тогда API не сишное, а паскалевое, поскольку там для системных функций применяется не cdecl, а stdcall.

Не, у pascal и stdcall порядок аргументов на стеке разный. :)

Почему MS выбрала stdcall а не стандартный cdecl - я не в курсе. Возможно руководствовались небольшой экономией размера кода которую даёт stdcall.

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

Ну вот когда появится специальная гугловская жаба, тогда и можно будет говорить о нативности жабы. А пока специальная гугловская жаба дёргает libc или чего там, написанное на сишечке и для сишечки. Да и сама гугловская жаба пока что написана отнюдь не на жабе, а на плюсах.

Из питона с применением смекалочки кстати можно дёргать сисколы, записываем его в нативные?

Код - нативный, ибо исполняется на процессоре, приложение и язык на котором оно написано - нет.

Замечательно, вы выдумали новый термин только что - «нативный язык» ;) Напишите про него статью в википедии что-ли, чтобы другие знали тоже, что это такое

Потому что в винде нативный API - сишный.

API - он API, он не зависит от языка. То, о чем вы говорите - называется «calling convention», и для родного виндового API используется __stdcall calling convention (https://msdn.microsoft.com/en-us/library/zxk0tw93.aspx). Ни к какому конкретному языку программирования __stdcall не привязан.

А потом Java API будет дёргать через JNI всякий HAL, libs/gui и что там ещё есть, которое написано на C++, а вовсе не на жабе.

99% кода - написано на Java, в случае андроида. Более того, согласно вашему же определению, получается что в данном случае тоже «Код - нативный, ибо исполняется на процессоре».

Разумеется этот бутерброд не добавит ни быстродействия, ни экономичности.

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

Stanson ★★★ (23.11.2016 21:36:51):

Сколько системных утилит, необходимых для работы системы, написано на C++? Да ни одной.

Stanson ★★★ (24.11.2016 0:18:38):

Да и сама гугловская жаба пока что написана отнюдь не на жабе, а на плюсах.

Именно. Вызывает open из libc написанной на С. Нативное приложение просто вызовет open сразу из libc, без всякой прослойки в виде жабы.

Получается QT приложение, использующее QFile для работы с файлом - тоже не нативное?

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

Ни к какому конкретному языку программирования __stdcall не привязан.

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

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

Получается QT приложение, использующее QFile для работы с файлом - тоже не нативное?

С++ умеет C искаропки. Никакие JNI для этого не нужны.

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

Если говорить на чистоту - то из Java тоже можно вызвать нативные методы, не обращаясь к промежуточным библиотекам, например так (это самодостаточный компилируемый код):

import com.sun.jna.Library;
import com.sun.jna.Native;
import com.sun.jna.Platform;

public class HelloWorld {
    public interface CLibrary extends Library {
        CLibrary INSTANCE = (CLibrary) Native.loadLibrary(
            (Platform.isWindows() ? "msvcrt" : "c"), CLibrary.class);
        void printf(String format, Object... args);
    }

    public static void main(String[] args) {
        CLibrary.INSTANCE.printf("Hello, World\n");
        for (int i = 0; i < args.length; i++) {
            CLibrary.INSTANCE.printf("Argument %d: %s\n", i, args[i]);
        }
    }
}

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