Kompatibilní VM si můžu snadno naprogramovat Vy, nebo já, a to zcela bez zdrojáků Sunu. Protože popis instrukcí virtuálního strojového kódu Javovské VM si stáhnete jako dokument z webu Sunu, kde se také dozvíte jak se má co interpretovat. A pak stačí sednout a programovat - a naprogramovat jednoduchou JVM je celkem jednoduché a bez problémů, to není naprosto nic složitého, a uděláte to za chvilku.
Není třeba z JVM dělat super složitou věc, je to věc velmi jednoduchá. Pokud potřebujete naprogramovat jednoduchou JVM - pouze interpretr Javovského byte kódu (tedy přechroustaného do .dgx), pak to zvládne i jeden průměrný programátor a celkem za krátký čas, protože tam nic složitého ani náročného není.
Normální desktopová JVM třeba pro Linux je samozřejmě složitá, ale jen proto, že obsahuje spoustu optimalizačních věcí, třeba JIT kompilaci a další, ale nic takového pro mobil samozřejmě programovat nebudete, pro mobil uděláte holý interpretr JVM - záležitost na zhruba pár desítek tisíc řádek ve zdrojovém kódu C++. Nic složitého.
Ale stale je ta specifikace JVM forma IP, na kterou se nejake ty paragrafy vztahuji a to i bez ohledu na to, ze delame jen prepis z mnoziny A do B.
Uvedu konkretni priklad, kde jde opravdu o velke penize - soubory AutoCADu... - jak to, ze neni plnohodnotny popis, jak to ze nejsou plnohodnotne knihovny? A je to opravdu jen diky tomu, ze nikdo nema tu chut ten soubor "rozbagrovat"? Vetsina struktur a grafickych primitiv, vcetne parametru je znama a obcas se dala i na webech (kde byla docela rychle a urcite ne dobrovolne stazena) nalezt... - mluvim ted o binarnim formatu, nikoli omezene (= neplnohodnotne) mnozite "textoveho" vystupu.
Google navíc neudělal JVM, ale pouze se _inspiroval_, což třeba Sun udělal také, že se inspiroval C++ a později dalšími jazyky. Google si vážím v tom, že po udělání Davlika neplive špínu na Javu, kterou se inspiroval. Sun je zase pokrytec v tom, že poté, co se inspiroval C++ a v Javě použil spoustu věcí z C++ začal špinavou kampaň proti C++, kterou začal mohutně pomlouvat.
Pokud reverzních enginneringem rozkryjete soubory z AutoCadu, není problém je veřejně použít, koneckonců já jsem je rozkrýval taky, když jsem potřeboval programovat práci s mapami a s mapovým programem, který jsem naprogramoval a koupil jsem některé mapové vstupy ve formátu AutoCadu.
"Pokud reverzních enginneringem rozkryjete soubory z AutoCadu, není problém je veřejně použít, koneckonců já jsem je rozkrýval taky, když jsem potřeboval programovat práci s mapami a s mapovým programem, který jsem naprogramoval a koupil jsem některé mapové vstupy ve formátu AutoCadu."
Nejsem si uplne jisty, neodporuje-li to nasemu autorskemu zakonu. Okolo reverse engineeringu tam bylo par uprav.
Co je to plnohodnotný popis? Ten, co vznikl reverzním inženýrstvím to asi nebude, protože není jistota, že je úplný. K JVM je popis už hotový, přímo od Sunu, narozdíl od AutoCadu, který formát dwg tají.
Krom toho chuť "rozbagrovat" DWG má spoustu lidí, viz OpenDWG Alliance, kde kromě reverzně zinžerovaného popisu jsou pro členy i knihovny pro práci s DWG. Jsou na tom založené importery a exportery mnoha konkurenčních CADů a jádro rodiny IntelliCadu.
A neslyšel jsem, že by se to nějak drasticky právně řešilo. Autodesk to v poslední době řeší tím, že při každé příležitosti formát DWG mění a omezuje zpětnou kompatibilitu v ACADu, aby si zajistil konkurenční výhodu obrovské penetrace DWG formátu v technicky zaměřených firmách.
Vytvorit kompatibilni VM opravdu neni zadny vetsi problem (ted nemyslim JIT, ale interpreter), to je zalezitost o rozsahu rocnikoveho projektu (tusim, ze jsme to na VUT delali). A pokud si sezenete knihovny (pod GPL), tak je nova JRE na svete. Dokonce neni ani vetsi problem vytvorit prekladac nejakeho jazyka, ktery misto zdrojaku generuje Javovsky bytekod - je to vlastne velmi jednoduchy zasobnikovy strojek.