Přemostění (programování) - Bridging (programming)
v počítačová věda, přemostění popisuje systémy, které mapují běhové chování různých programovací jazyky aby mohli sdílet společné zdroje. Často se používají k tomu, aby „cizím“ jazykům umožnily provozovat nativní hostitelskou platformu objektové knihovny, překládající data a stav přes dvě strany mostu. Překlenovací kontrasty s „zabudovanými“ systémy, které umožňují omezenou interakci prostřednictvím a Černá skříňka mechanismus, kdy je sdílení stavu omezené nebo neexistuje.
Apple Inc. již několikrát těžce využívá přemostění, zejména v raných verzích systému Windows Mac OS X který překlenul starší "klasické" systémy pomocí Uhlík systém stejně jako Jáva. Microsoft je Common Language Runtime, představený s .NET Framework, byl od začátku navržen jako vícejazyčný a vyhnul se potřebě rozsáhlých překlenovacích řešení. Obě platformy nedávno přidaly nové přemosťovací systémy pro JavaScript, Apple ObjC-to-JS a Microsoft HTML Bridge.
Koncepty
Funkce, knihovny a runtime
Většina programovacích jazyků zahrnuje koncept a podprogram nebo funkce, mechanismus, který umožňuje zapouzdření a opětovné použití běžně používaného kódu v celém programu. Například program, který velmi využívá matematiku, bude možná muset provést odmocnina výpočet na různých číslech v celém programu, takže tento kód může být izolován v a sqrt (aNumber)
funkce, která je „předána“ číslo, které má provést výpočet druhé odmocniny, a „vrací“ výsledek. V mnoha případech dotyčný kód již existuje, buď implementovaný v hardwaru, nebo jako součást podkladu operační systém program běží uvnitř. V těchto případech čtv
funkce může být dále zjednodušena voláním vestavěného kódu.
Funkce často spadají do snadno identifikovatelných skupin podobných schopností, například matematických funkcí nebo zpracování textových souborů. Funkce se často shromažďují ve sbírkách známých jako knihovny které jsou dodávány se systémem nebo, častěji v minulosti, s programovacím jazykem. Každý jazyk má vlastní metodu volání funkcí, takže knihovny napsané pro jeden jazyk nemusí fungovat s jiným; sémantika pro volání funkcí ve Windows C se liší od Pascal, takže programy C obecně nemohou volat knihovny Pascal a naopak. Běžně používaným řešením tohoto problému je vybrat jednu sadu volání sémantiky jako výchozí systém pro platformu a poté musí všechny programovací jazyky odpovídat tomuto standardu.
Většina počítačových jazyků a platforem obecně přidala funkčnost, kterou nelze vyjádřit v modelu volání / návratu funkce. Sběr odpadu například běží po celou dobu životnosti aplikace. Tento druh funkcí je efektivně „mimo“ program, je přítomen, ale není vyjádřen přímo v samotném programu. Funkce, jako jsou tyto, jsou obecně implementovány do stále rostoucího počtu runtime systémy, knihovny, které jsou kompilovány do programů, ale nejsou nutně viditelné v kódu.
Zavedení sdílená knihovna systémy značně změnily model konstrukce konvenčního programu. V minulosti byl kód knihovny kopírován přímo do programů pomocí „linker "a účinně se stal součástí programu dynamické propojení kód knihovny (obvykle) existuje pouze na jednom místě, soubor poskytovaný dodavatelem v systému, který sdílejí všechny aplikace. Starší systémy představovaly mnoho problémů, často z hlediska výkonu, a sdílené knihovny byly do značné míry izolované pro konkrétní jazyky nebo platformy, na rozdíl od operačního systému jako celku. Mnoho z těchto problémů bylo vyřešeno v 90. letech a počátkem roku 2000 většina hlavních platforem přešla na sdílené knihovny jako primární rozhraní pro celý systém.
Ačkoli tyto systémy řešily problém poskytování běžných knihoven kódů pro nové aplikace, tyto systémy obecně přidávaly také vlastní runtime. To znamenalo, že jazyk, knihovna a nyní celý systém byly často úzce propojeny. Například pod OpenStep celý operační systém byl ve skutečnosti Cíl-C program. Všechny programy na něm spuštěné, které by chtěly používat rozsáhlou sadu objektů poskytovanou v OpenStep, by nejen musely být schopny volat tyto knihovny pomocí sémantiky Obj-C, ale také komunikovat s běhovým modulem Obj-C, aby poskytly základní kontrolu nad aplikací.
V porovnání, Microsoft je .NET Framework byl od začátku navržen tak, aby zpočátku podporoval více jazyků C#, C ++ a nová verze Visual Basic. K tomu MS izoloval knihovny objektů a runtime do Společná jazyková infrastruktura (CLI). Místo programů kompilačních přímo z zdrojový kód do základního běhového formátu, jak je tomu ve většině jazyků, v rámci modelu CLI jsou všechny jazyky nejprve zkompilovány do Společný střední jazyk (CIL), který pak volá do Common Language Runtime (CLR). Teoreticky může jakýkoli programovací jazyk používat systém CLI a používat objekty .NET.
Přemostění
Ačkoli platformy jako OSX a .NET nabízejí možnost přizpůsobení většiny programovacích jazyků runtime systému platformy, je také pravda, že tyto programovací jazyky mají často na mysli cílový runtime - Cíl-C v podstatě vyžaduje runtime Obj-C, zatímco C # dělá to samé pro CLR. Pokud chce někdo použít C # kód v Obj-C, nebo naopak, musí najít verzi napsanou pro použití druhého běhového prostředí, které často neexistuje.
Běžnější verze tohoto problému se týká použití jazyků nezávislých na platformě, jako je Java, které mají vlastní runtime a knihovny. I když je možné sestavit kompilátor Java, který volá základní systém, jako je J #, takový systém by také nebyl schopen komunikovat s jiným kódem Java, pokud by také nebyl znovu kompilován. Přístup ke kódu v knihovnách Java může být obtížný nebo nemožný.
Vzestup webový prohlížeč jako druh virtuálního operačního systému učinil tento problém akutnějším. Moderní "programovací" paradigma pod HTML5 zahrnuje JavaScript (JS) jazyk, Model objektu dokumentu jako hlavní knihovna a samotný prohlížeč jako běhové prostředí. I když by bylo možné vytvořit verzi JS, která běží na CLR, ale to by do značné míry porazilo účel jazyka určeného převážně pro provoz prohlížečů - pokud tento kompilátor nemůže přímo komunikovat s prohlížečem, jeho použití je malý účel .
V těchto případech a mnohým se to líbí, vyvstává potřeba systému, který umožní spolupráci dvou běhových časů. Toto se nazývá „přemostění“ doby běhu.
Příklady
Jablko
Společnost Apple od nejranějšího úsilí, které k tomu vedlo, značně využívala překlenovací technologie Mac OS X.
Když společnost NeXT poprvé zakoupila společnost Apple, bylo plánováno vybudování nové verze OpenStep, tehdy známé jako Rapsódie, s emulátor známý jako Blue Box, který spouští „klasické“ programy Mac OS. To vedlo k výraznému návratu ze strany vývojářské komunity a Rhapsody byla zrušena.[1] Místo toho by OS X implementoval mnoho starších volání systému Mac OS nad základní funkce v OpenStep, což by poskytlo cestu pro bezproblémovou migraci stávajících aplikací.
K tomu Apple vzal užitečný kód z platformy OpenStep a znovu implementoval základní funkce v knihovně pure-C známé jako Základní nadace, nebo zkráceně CF. Knihovny OpenStepu volající na základní kód CF se staly Kakaové API, zatímco novými knihovnami typu C podobnými Mac se staly Uhlíkové API. Protože strany systému C a Obj-C potřebovaly sdílet data a data na straně Obj-C byla obvykle uložena v objektech (na rozdíl od základních typů), převody do az CF mohly být drahé. Apple nebyl ochoten zaplatit tento výkonnostní trest, proto implementovali systém známý jako „bezplatný přemostění“, který má tento problém snížit nebo eliminovat.[2]
V té době se Java stávala významným hráčem ve světě programování a společnost Apple také poskytla překlenovací řešení Java vyvinuté pro WebObjects plošina. Jednalo se o klasičtější překlenovací řešení s přímými převody mezi typy Java a OpenStep / CF, které byly v případě potřeby dokončeny v kódu. V rámci programu Carbon program využívající CFStrings používal stejný kód jako kakaová aplikace používající NSString a tyto dva programy mohly být bezplatně přemostěny. S mostem Java byly CFStrings místo toho vrženy do vlastních řetězcových objektů Java, což vyžadovalo více práce, ale portování bylo v podstatě neviditelné.[3] Jiní vývojáři široce využívali podobné technologie k poskytování podpory pro jiné jazyky, včetně systému „peeringu“ používaného k povolení kódu Obj-C volat kód .NET pod Mono.[4]
Vzhledem k tomu, že potřeba těchto portovacích řešení slábla, byly jak Carbon, tak Java Bridge zastaralé a nakonec odstraněny z pozdějších verzí systému.[5][6] Podpora Java byla migrována na použití Nativní rozhraní Java (JNI), standard ze světa Javy, který umožňoval Javě komunikovat s kódem založeným na C. Na OSX umožnilo JNI s určitými obtížemi použít kód Obj-C.[7]
Kolem roku 2012 proběhly rozsáhlé práce společnosti Apple WebKit vedlo k zavedení nové přemosťovací technologie, která umožňuje JavaScript programový kód pro volání do modulu runtime Obj-C / Cocoa a naopak. To umožňuje automatizaci prohlížeče pomocí Obj-C nebo alternativně automatizaci kakaových aplikací pomocí JavaScriptu. Původně součást Webový prohlížeč Safari V roce 2013 byl kód povýšen na součást nového OSX 10.9.[8]
Microsoft
Ačkoli existují některé příklady přemostění, které se v minulosti používalo, systém CLI společnosti Microsoft byl určen k podpoře jazyků na vrcholu systému .NET, nikoli na běh v nativních běhových režimech a přemostění. To vedlo k zavedení řady nových jazyků v systému CLI, často zahrnujících buď hash mark (#), nebo „Iron“ ve svém názvu. Viz Seznam jazyků CLI pro komplexnější soubor příkladů. Tento koncept byl považován za příklad MS obejmout, rozšířit a uhasit chování, protože produkovalo jazyky podobné Javě (C # a J # například), kteří nepracovali s jiným kódem Java nebo nepoužívali své knihovny.
„Klasický“ ekosystém Windows však obsahoval značný kód, který by bylo potřeba použít ve světě .NET, a pro tuto roli zavedla společnost MS dobře podporovaný přemosťovací systém. Systém obsahoval řadu nástrojů a jazykových funkcí, které usnadňují používání kódu Windows nebo Visual Basic v systému .NET,[9] nebo naopak.[10]
Společnost Microsoft také představila technologii přemostění JavaScriptu pro Silverlight, most HTML. Bridge vystavuje typy JS kódu .NET, typy .NET kódu JS a spravuje paměť a zajišťuje mezi nimi bezpečnost.[11][12]
Další příklady
Podobné přemosťovací technologie, často s JavaScriptem na jedné straně, jsou běžné na různých platformách. Jedním z příkladů je most JS pro OS Android napsáno jako příklad.[13]
Termín je také někdy používán k popisu objektově-relační mapování systémy, které překlenují propast mezi SQL svět databází a moderní objektové programovací jazyky.
Reference
- ^ Dave Winer, „Rhapsody Zrušeno“, 12. května 1998
- ^ „Bezplatné mostní typy“, Apple, 19. září 2012
- ^ „Používání Java Bridge“, Apple
- ^ „Přemostění“
- ^ Andrew Youll, „Apple kapky Cocoa-Java Bridge“, OSNews, 10. července 2005
- ^ „Podpora uhlíkového jádra“, Apple, 23. července 2013
- ^ „Technická poznámka TN2147: Vývoj JNI v systému Mac OS X“, Apple, 14. července 2011
- ^ Nigel Brooke, „Nový most Apple Objective-C k JavaScriptu“, 14. května 2013
- ^ Jason Clark, „Volání metody spravované .NET z nativního kódu“, MSDN Magazine
- ^ „Volání metody spravované .NET z nativního kódu“, Microsoft
- ^ „Most HTML: Interakce mezi HTML a spravovaným kódem“, Microsoft
- ^ „Používání mostu HTML“, Microsoft
- ^ „Android Development: JavaScript Bridge Příklad - zcela vysvětleno!“ Archivováno 29 července 2013, na Wayback Machine, objektový graf, 16. května 2012