Компания Google представила (http://google-opensource.blogspot.ru/2016/01/j2objc-10-relea...) первый стабильный релиз транслятора J2ObjC (http://j2objc.org/), преобразующего исходные тексты на языке Java в представление на языке Objective-C, пригодное для использования в приложениях для iPhone и iPad. Код транслятора написан на языке Java и распространяется (https://github.com/google/j2ob) под лицензией Apache 2.0.
J2ObjC даёт возможность унифицировать процесс разработки приложений на языке Java, ориентированных на использование в различных мобильных платформах. Основу приложения, не связанную с обеспечением работы пользовательского интерфейса, предлагается разрабатывать на языке Java, а обвязку с реализацией интерфейса создавать с использованием родных средств платформы. Например, базовый Java-код, определяющий логику работы приложения и методы обработки данных, может быть использован в программах для платформы Android, iOS или в web-приложениях (для трансляции Java в JavaScript можно использовать GWT (http://www.gwtproject.org/)).
В процессе сборки приложения при помощи J2ObjC компоненты на языке Java прозрачно транслируются в код на Objective-C, позволяя сформировать финальное приложение для платформы iOS целиком на Objective-C. J2ObjC не является эмулятором и позволяет формировать полноценные итоговые проекты на языке Objective-C, что полностью соответствует требованиям компании Apple в отношении используемых средств разработки. Особенностью J2ObjC является то, что транслятор осуществляет преобразование Java-классов в соответствующие классы Objective-C, позволяя напрямую использовать iOS Foundation Framework.В J2ObjC поддерживаются все возможности языка Java 8 и большая часть runtime-функциональности, используемой в клиентских приложениях, включая исключения, внутренние и анонимные классы, generic-типы, потоки и отражения. Также поддерживается трансляция в Objective-C и запуск тестов JUnit и Mockito. Для сборки могут быть использованы штатные инструменты, такие как Xcode и Make, имеются плагины для Gradle и Maven. В рамках проекта J2ObjC не планируется предоставление унифицированного платформонезависимого тулкита для разработки пользовательского интерфейса, т.е. для создания интерфейса в редакции приложения для iOS требуется создание отдельной обвязки на Objective-C, Objective-C++ или Swift.
Из написанных с использованием J2ObjC приложений Google, поставляемых для платформы iOS, отмечаются Inbox by Gmail, Google Calendar, Google Docs, Google Sheets, Google Slides и Google My Business.
URL: http://google-opensource.blogspot.ru/2016/01/j2objc-10-relea...
Новость: https://www.opennet.ru/opennews/art.shtml?num=43714
>> J2ObjC не является эмулятором и позволяет формировать полноценные итоговые проекты на языке Objective-C, что полностью соответствует требованиям компании Apple в отношении используемых средств разработкиэплы совсем с катушек спрыгнули? они уже указывают в какой среде проги под них писать? может еще и как одеваться будут указывать? :D
Обутые глаза? Не Apple а Google, и не указывает, а рекомендует.
> Обутые глаза? Не Apple а Google, и не указывает, а рекомендует.Именно Apple. В его каталог-магазин принимаются только программы на Objective-C, Objective-C++ и Swift.
Пруфлинк пожалуйста. Интересно, как живут игры на Unity и плюсах, упакованный вебчик на Cordova, АОТный дотнет на Xamarin, AOTный флэш на Adobe AIR? Список технологий можно продолжить.
в итоге либо генерируется код на обжси, либо движок с интерпретатором написан на обжси.
Ну, вообще против сишных библиотек Эпплы тоже не возражают, но всё приложение на C не напишешь
Потому что Юнити генерирует икскод проект с плюсовым кодом, Хамарин скорее всего тоже. Адоб эир тоже скорее всего во что-то переделывается. Ибо эппл не разрешает приложения, которым для работы нужна эмуляция или интерпретация - исключение разве что веб приложения в вебвью.
Юнити генерирует плюсовый код довольно недавно. Раньше у них был форкнутый Mono, AOT которого умел только в ARM32. Xamarin делает прямую трансляцию в машинный код ARM через свой AOT. Тоже самое и Adobe AIR. На деле для Apple важно что бы не было динамической линковки и исполнения машинного кода сгенерированного во время выполнения. По этому пролетают все технологии в JIT, кроме JS для которого Apple предлагает свой собственный рантайм.
конторы специально делают стойки из эпловских компов, потому что их софт официально можно запускать на их железе.
iТрусы, iНоски
То же мне проснулся :) сто лет в обед.зы. а насчет одеваться - часы от яблока - must be :)
Эпплу на самом деле по барабану, на чем написано - главное, чтобы генерировался нативный arm код, безо всяких там JIT-ов.Пунктик про Objective-C был добавлен специально для Adobe, когда те выпустили под видом продакшен-решения недопиленную ерунду, которая из флешки вида echo "Hello World" делала бинарь на полгига, сажающий батарейку за полчаса. Исключительно из опасений, что аппстор мгновенно наводнят программисты на флеше мышкой - чтобы был повод автоматически делать отлуп всем таким поделиям. Несмотря на все возникшие тогда опасения, на практике более ни для чего этот пункт никогда не применялся; когда тот же AIR Adobe довел до ума, никаких препятствий не было.
Разработка под иОС и МакОС подразумевает строго работу в рамках стандартных каркасов. Средства разработки же никак не ограничиваются. В оригинале речь идёт о том, что Эпл не пошла на интеграцию JVM ни в каком виде. Более того, из последних релизов МакОСа Яву выпилили полностью.
>Java в Objective-CА чего не из ФОРТРАНа в COBOL?
Это для сферического кода в вакууме, который ни от чего не зависит?
Интересно, напишет ли Apple ObjC2J в ответ? ;-)
> Интересно, напишет ли Apple ObjC2J в ответ? ;-)Зачем? Они уже ушли в сторону Swift
Ну, Swift2J. ;-)
Apple - компания с закрытой экосистемой, там слово Java стараются не употреблять. Как и любое другое слово, к которому нельзя приписать Apple и запатентовать.Например, не прямоугольник (Rectangle), а Apple® iPad™
Ну и т.д. :)
> Apple - компания с закрытой экосистемой, там слово Java стараются не употреблять.
> Как и любое другое слово, к которому нельзя приписать Apple и
> запатентовать.
> Например, не прямоугольник (Rectangle), а Apple® iPad™
> Ну и т.д. :)Почему закрытой, коль Эпл сейчас основной спонсор очень многих открытых проектов (с BSD-лицензией)?
"В J2ObjC поддерживаются все возможности языка Java 8 и большая часть runtime-функциональности"
вот ведь как забавно
Т.е. можно будет писать только для android и автоматом переносить на iPhone и iPad. Хорошо.
автоматом можно, если не интересует результат
> Т.е. можно будет писать только для android и автоматом переносить на iPhone
> и iPad. Хорошо.Автоматом нельзя. Это миф для неосилянтов. Очень уж объектные модели различны. Проще вести два проекта, на ОбСи и на Яве, с единого UML-а.
Swift как язык намного лучше.
лучше бы наоборот запилили полноценный транслятор Swift в Java, android.
Гугл заинтересован в том, чтобы Андроид рассматривался как первичная платформа для разработки приложений, а iOS-приложения шли довеском. То, что вы предлагаете, дало бы ровно противоположный результат.
> Гугл заинтересован в том, чтобы Андроид рассматривался как первичная платформа
> для разработки приложений, а iOS-приложения шли довеском.Вот, не зря поискал -- написал ли кто уже то, что собирался тоже написать.
В последнее время мне Корпорация Добра видится бОльшим злом, чем Эппл и Майкрософт вместе взятые. Именно потому, что работают больше не кнутом, а пряником - который в итоге оказывается тем же анальным зондом, только с малиновым вкусом.
> В последнее время мне Корпорация Добра видится бОльшим злом, чем Эппл и Майкрософт
> вместе взятые. Именно потому, что работают больше не кнутом, а пряникомКнут у них тоже есть -- как и пряник у тех двоих... но в целом скорее так.
> лучше бы наоборот запилили полноценный транслятор Swift в Java, android.Зачем транслятор? Люди уже пилят компиляцию свифта в нативные бинарники для андроида. А уж интерфейс на яве извольте сами.
Тут коллеги порадовали, что есть тренд писать внутренности на плюсах, а потом отдельную морду на каждую мобильную платформу, благо и пилить ничего не нужно. Дополнительная выгода - при желании можно легко использовать на десктопе или сервере.
Ага, так и делаем. Для андроид-С++ еще берется CrystaX а то стандардный не очень поддерживает норм С++
>> лучше бы наоборот запилили полноценный транслятор Swift в Java, android.
> Зачем транслятор? Люди уже пилят компиляцию свифта в нативные бинарники для андроида.
> А уж интерфейс на яве извольте сами.Кто-то что-то делает на Свифте? Он же убог до нельзя.
>Swift как язык намного лучше.... чем грузины! :)
Недо- пере- питон.
Свифт опенсорснули же: https://github.com/apple/swiftЖелающие могут запилить. :-)
> Swift как язык намного лучше.
> лучше бы наоборот запилили полноценный транслятор Swift в Java, android.Лучше чем что? Свифт же это убогое пхп в исполнении Эпл.
.jar без -src.jar тоже умеет транслировать? А то меня в гугле забанили
> А то меня в гугле забанилиНу и как тогда собираетесь скачивать транслятор? :)
PS: а бинарники в исходники преобразовывать -- дизассемблирование в эквиваленте.
браво! это новый виток в развитии переводчика гугла!
Так вот почему гугл отказывается от далвика
А тем временем в аппсторе уже полно приложений и игр написанных на RoboVM (https://robovm.com/) . Гугл немного припоздал, как всегда.
Думаю, гуглу это только в плюс. А так - в конкуренции между инструментами от крупной корпорации-создателя платформы и чем-то сторонним корпорация проигрывает только если сильно чудит.
>корпорация проигрывает только если сильно чудит.по-моему тут как раз этот случай. Делать транслятор в исходный код другого (кстати устаревающего) языка, тогда когда у кого-то уже рабочий опунсурсный компилятор под эту платформу (с небольшими оговорками)...
ну так народ же хочет один раз написать и забыть! ох мечты-мечты(
> Google выпустил J2ObjC 1.0, транслятор из уныло в не нужноfixed
Как разработчик для Android, уже устал от тупоголовости Java (особенно от generics с кривым выводом типов), а при виде кода на Objective-C вообще хочется блевать. Нет бы сделать нормальный С интерфейс к Android, чтобы можно было на любом ЯП написать обёртки и радоваться - заодно любители изращений могли бы иметь большую часть кода приложения на Objective-C, и только UI делить по платформам. Все были бы счастливы. Но нет, мы сделаем интерфейс к платформе на самом геморройном в плане FFI языке, чтобы разработчики не скучали, а потом будем городить костыли. Такое ощущение, будто Android делает какое-то особо упоротое подразделение Google.