Je možné programovat v čemkoli, co
1. Přeložíte do příslušného bytecode. To odpovídá bytecode z Javy 1.3 (přesněji bytecode verze 47.0), plus je nutné splnit další specifické požadavky (nepoužití instrukcí JSR a RET + StackMap), které zjednodušují práci JVM (teda vlastně KVM). Tyto další požadavky lze ale splnit celkem snadno – běžně se generuje bytecode nesplňující tyto požadavky, a následně se nástrojem preverify upravuje, aby je splňoval.
2. Použije správnou standardní knihovnu (MIDP+CLDC).
Teoreticky lze použít i novější verzi jazyka Java a následně nástroji jako Retrotranslator a případně snad k tomu i Retrolambda to přeložit do 1.3. To ale prakticky nemusí být až takový přínos – stejně potřebujete použít standardní knihovnu pro MIDP+CLDC, která například v kolekcích určitě nepoužívá generika.
Použití jiných jazyků než Java tak teoreticky možné je, s trochou snahy dokonce i pokud generují novější bytecode. V praxi ale můžete snadno narazit:
* Kompilátor automaticky použije třídy/metody, které nemá v MIDP+CLDC k dispozici. To se dost možná stane u dynamických jazyků jako Groovy nebo Clojure, protože nemáte k dispozici reflexi.
* Jazyk vyžaduje dodatečnou standardní knihovnu, která nemusí být plně kompatibilní.
* Formálně se dostanete ke kódu, který splňuje standardy, ale kvůli kompilátoru generujícímu obrovský kód (zkusil jsem si disassemblovat Hello World v Groovy++) nebo standardní knihovně dostanete JAR v řádu jednotek nebo desítek MiB. Je otázkou, jak si s tím poradí který telefon.
* Nebo se můžete dostat k funkčnímu, ale pomalému kódu. I když, to spíš nebude fungovat vůbec, protože to shoří na reflexi.
Částečně zde může pomoci ProGuard, který umí mimo jiné prořezat nepotřebný kód, ale taky nezvládne všechno. V praxi se IMHO snadno můžete dostat do situace, kdy u jednoduché aplikace strávíte více času laděním buildovacího procesu, než kolik ušetříte použitím příjemnějšího jazyka.
Jediný jiný jazyk, o kterém vím, že by teoreticky měl být tady celkem použitelný, je Mirah, který se snaží být staticky typovaným Ruby pro JVM. Nemá vlastní standardní knihovnu a má se kompilovat prý celkem přímočaře. Moc se nevyvíjí, ale na to se u programování v J2ME asi moc nehraje…
Nemůžete ale použít nativní kód ani nativní pointerovou aritmetiku. Cčko je asi prakticky mimo hru. I kdybychom měli kompilátor C do class souborů, jsou tu praktické problémy. Co s pointerovou aritmetikou? Ano, dá se udělat jedno velké pole, v rámci kterého simulujete pointerovou aritmetiku, něco podobného AFAIR dělá pro JS nástroj Emscripten. Tím ale ztratíte výkon (narozdíl od JS tu pro to není speciální podpora v JVM) a zkomplikujete interoperabilitu se standardní knihovnou, kterou potřebujete použít na UI apod. Pro aplikace psané na zelené louce to tedy nemá moc smysl. Nebo je možné C (nebo spíše C++) trošku uzpůsobit podmínkám a používat Javové třídy jako java.lang.String (namíšto std::string nebo char*). Pak ale celkem nevyhnutelně skončíte u jazyka prakticky dost podobného Javě, protože Java staví na Cčkové syntaxi. S trochou nadsázky tento jazyk C++4J může mít transpiler do Javy napsaný v Bashi pomocí sedu.
9 Odpovědí
5868 Zhlédnutí