elizarov


Блог Романа Елизарова


Previous Entry Share Next Entry
Cross-compile Java bytecode to Objective-C
elizarov
Перед Devexperts стоит задача перевести некий объем бизнес-логики написанный на Java для мобильных приложений на iPhone, где основным языком разработки является Objective-C. Начнем с кода который рисует красивые графики на нашем собственном классе типа Canvas. Речь о GUI в целом сейчас пока не идет -- его мы разрабатываем "с нуля" используя нативные элементы управления на iPhone.

Объем кода для перевода на Objective-C достаточно большой, чтобы у нас не возникало безоговорочного желание написать всё с нуля, так как нам же потом этот код и поддерживать. Хочется вносить все будущие изменения в один code-base. Более того, таких проектов предвидится несколько, то есть в перспективе придется переводить на iPhone несколько различных библиотек и приложений.

Возникла идея разработать кросс-компилятор с Java bytecode в Objective-C и ограничиться пока ref-counting GC, так мы знаем что у нас нет циклов в графе объектов. Занимался ли кто-нибудь чем-нибудь подобным? Нет ли для этого готовых решений? Если готовых решений нет, то на следущей неделе мы официально откроем вакансию на позицию "Senior Developer" под этот проект. Если кому интересно -- пишите.

  • 1
мы маньяки...

а откуда мы так смело знаем, что у нас нет циклов в графе объектов?

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

Вы имеете ввиду shape analysis?

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

Когда iPhone только вышел, Sun заявила, что собирается портировать JVM на него. Потом вышел SDK и в Сан заявили, что его возможностей недостаточно для портирования полноценной виртуальной машины. Или эпл готовит свою платформу-конкурента джавы, флекса и сильверлайта, или более продвинутый сдк всё-таки выйдет и джаву на айфон портируют. И тогда кросс-компилятор будет уже не нужен.
Но задумка прикольная, хотел бы чем-то таким заниматься :)

Я и так у вас работаю :)

Так тогда welcome в квадрате :) Мы всегда заинтересованы в том, чтобы наши сотрудники занимались именно тем, что им наиболее интересно (в рамках их квалификации, естественно).


Заявил об этом исключительно маркетинг Сана, технические специалисты изначально были настроены скептически. Да и понятие "портировать JVM" в Сане обычно трактуется своеобразно - сейчас они переносят на айфон CLDC/MIDP платформу. Кому она там нафиг нужна?

Кроме того, лицензионное соглашение по использованию SDK явно запрещает создание языковых интерпретаторов.

если в java коде не используются особенности java не имеющие прямых аналогов в с++ то это не сильно сложная задача. можно взять gc либы для с++ которых есть в ассортименте.


Опорный язык на айфонах - Objective C, а не С++, различия довольно существенные. Все интерфейсы стандартного SDK оформлены только на ObjC (т.е. теоретически на плюсах писать можно, но на практике запаришься), и именно на нём пишется нативная GUI-часть. Мы изначально решили, что без крайней необходимости плюсы вовлекать не будем.

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

и сильно objective-c отличается от c++?
что-то мне подсказывает что база у них совсем общая.
попробую угадать - нет exceptions и templates.
так?

Objective-C
Похож ли - решай сам.

ой :)
потом почитаю :)

прочитал.
сложилось ощущение что этот Objective-C ближе к java чем к с++

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

Ещё раз - лицензионное соглашение Apple по использованию SDK для iPhone явным образом запрещает создание интерпретируемых языков программирования. Зачем нам лицензионные проблемы с полученным продуктом?

Вот, первая ссылка, что нашлась в гугле: Javascript is an interpreted programming language, and thus forbidden as per Apple's terms of service. Also banned from the iPhone: programming languages Ruby, Python, Perl, and Java.

Даже отвлекаясь от этого - нет, JVM пересобрать не так-то просто. Вернее, JVM как таковую может и относительно просто (как минимум есть действующая JVM, собранная на основе GNU classpath ещё под неофициальный toolchain), но кому она нужна без поддержки нативного GUI?

Да, SDK всех неприятно удивил.(
А GUI всё равно придётся поддерживать отдельно, я так понял. Ведь подход к пользовательскому интерфейсу сильно отличается от пкшного. Я не прав?

Да. GUI для iPhone будет отдельный. При правильном дизайне кода (a la Model-View-Controller) само GUI составляет небольшую часть кода. На данном этапе перед кросс-компилятором стоит задача переноса бизнес-логики, которая там есть даже несмотря на то, что клиент "тонкий".

Погодите, при чем тут интерпретируемые языки и байт-код? : ) Мне казалось, это таки две большие разницы. Кроме того, никто же не запрещает использовать не SDK, а toolchains.

А, если вопрос стоит именно в GUI... Тогда проще действительно сделать трансляцию исходного кода Java в ObjC и результат рихтовать напильником.

Хм... Я думаю, что то, что делает JVM с байткодом в классическом варианте (пошаговое исполнение команд без перевода в машинный код процессора), называется именно интерпретацией.
Впрочем, в оригинале ограничения оказались ещё более сильными (ссылку не привожу, т.к. всё равно не откроется - нужно зарегистрироваться на developer.apple.com):

3.3.2. An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple's Published API and built-in interpreter(s).

toolchain подразумевает использование приложения на jailbroken аппаратах, наша же аудитория - легальные пользователи, скачивающие приложения в App Store.

Очень понравился ваш ЖЖ, я вас зафренжу и было бы круто если бы вы ответили взаимно;)

(Deleted comment)

Re: интересное

Можно писать на elizarov at devexperts точка com.

(Deleted comment)
Можно было бы исходник Java в исходник Objective-C, но:
1. Это сложней. Анализировть bytecode на порядок проще чем source code -- у него просто меньше "семантическое пространство". Многие "сложные" моменты в source cod (например generics, boxing/unboxing, и т.п.) имеют тривиальное представление в bytecode.
2. Это не работает с 3rd party libs к которым нет исходников.
3. Это не работает если после компиляции Java кода используется byte-code processing (aspects и т.п.)

А чем всё закончилось в итоге? Очень любопытно

Пока не закончилось. Процесс идет.

Роман, есть несколько разработчиков, знающих ObjC и Cocoa изнутри, а также положительный опыт кроссплатформенности, с ними связанный. Если тема еще актуальна, как с Вами удобнее связаться?

Шлите резюме на job at devexperts dot com с копией мне на elizarov at devexperts dot com.

  • 1
?

Log in

No account? Create an account