Tento článek poskytuje přehled návrhů, specifikací a platforem zaměřených na modulární technologii Java v prostředí Java 9. Budu diskutovat o faktorech, které přispívají k potřebě modulárnější architektury Java, stručně popíšu a porovnáme navrhovaná řešení, a představit tři aktualizace modularity plánované pro prostředí Java 9, včetně jejich potenciálního dopadu na vývoj prostředí Java.
Proč potřebujeme modularitu Javy?
Modularita je obecný pojem. V softwaru platí pro psaní a implementaci programu nebo výpočetního systému jako množství jedinečných modulů, spíše než jako jediný monolitický design. Poté se použije standardizované rozhraní umožňující komunikaci modulů. Rozdělení prostředí softwarových konstrukcí do samostatných modulů nám pomáhá minimalizovat propojení, optimalizovat vývoj aplikací a snížit složitost systému.
Modularita umožňuje programátorům provádět testování funkčnosti izolovaně a zapojit se do paralelního vývoje během daného sprintu nebo projektu. To zvyšuje efektivitu během celého životního cyklu vývoje softwaru.
Některé charakteristické atributy originálního modulu jsou:
- Autonomní jednotka nasazení (volné spojení)
- Konzistentní a jedinečná identita (ID modulu a verze)
- Snadno identifikovatelné a objevené požadavky a závislosti (standardní doba kompilace a nasazení a metainformace)
- Otevřené a srozumitelné rozhraní (komunikační smlouva)
- Skryté podrobnosti implementace (zapouzdření)
Systémy, které jsou postaveny tak, aby efektivně zpracovávaly moduly, by měly dělat následující:
- Podporujte modularitu a zjišťování závislostí v době kompilace
- Spouštějte moduly v běhovém prostředí, které podporuje snadné nasazení a opětovné nasazení bez prostojů systému
- Implementujte životní cyklus spuštění, který je jasný a robustní
- Poskytují zařízení pro snadnou registraci a vyhledávání modulů
Objektově orientovaná, komponentově orientovaná a servisně orientovaná řešení se všichni pokusili umožnit čistou modularitu. Každé řešení má svou vlastní sadu zvláštností, které mu však brání v dosažení modulární dokonalosti. Pojďme se krátce zamyslet.
Třídy a objekty Java jako modulární konstrukce
Nevyhovuje objektově orientovaná povaha prostředí Java požadavkům na modularitu? Objektově orientované programování v Javě přeci jen zdůrazňuje a někdy vynucuje jedinečnost, zapouzdření dat a volné propojení. I když jsou tyto body dobrým začátkem, všimněte si požadavků na modularitu nejsou splněno objektově orientovaným rámcem Java: identita na úrovni objektu je nespolehlivá; rozhraní nemají verzi: a třídy nejsou na úrovni nasazení jedinečné. Volná vazba je osvědčený postup, ale rozhodně není vynucován.
Opakované použití tříd v Javě je obtížné, když jsou závislosti třetích stran tak snadno zneužity. Nástroje pro kompilaci, jako je Maven, se snaží tento nedostatek vyřešit. Konvence a konstrukce jazykového jazyka, jako je například vkládání závislostí a inverze kontroly, pomáhají vývojářům v našich pokusech o ovládání běhového prostředí a někdy uspějí, zvláště pokud se používají s přísnou disciplínou. Tato situace bohužel ponechává práci na vytváření modulárního prostředí až po konvenční rámcové konvence a konfigurace.
Java také přidává do mixu jmenné prostory balíků a viditelnost oboru jako prostředek pro vytváření modulárních mechanismů kompilace a nasazení. Ale tyto jazykové funkce se snadno obejdou, jak vysvětlím.
Balíčky jako modulární řešení
Balíčky se pokoušejí přidat úroveň abstrakce do programovacího prostředí Java. Poskytují zařízení pro jedinečné kódovací jmenné prostory a konfigurační kontexty. Je smutné, že konvence balíčků se snadno obcházejí, což často vede k prostředí nebezpečných kompilací v době kompilace.
Stav modularity v Javě se v současné době (kromě OSGi, o kterém se krátce budu zabývat) nejčastěji dosahuje použitím jmenných prostorů balíčků, konvencí JavaBeans a proprietárních konfigurací rámce, jaké se nacházejí na jaře.
Nejsou soubory JAR dostatečně modulární?
Soubory JAR a prostředí nasazení, ve kterém fungují, výrazně vylepšují mnoho konvencí starších nasazení, které jsou jinak k dispozici. Soubory JAR však nemají žádnou vlastní jedinečnost, kromě zřídka používaného čísla verze, které je skryto v manifestu .jar. Soubor JAR a volitelný manifest se nepoužívají jako konvence modularity v prostředí runtime prostředí Java. Názvy balíků tříd v souboru a jejich účast na cestě ke třídě jsou tedy jedinou částí struktury JAR, která propůjčuje runtime prostředí modularitu.
Stručně řečeno, JAR jsou dobrým pokusem o modularizaci, ale nesplňují všechny požadavky na skutečně modulární prostředí. Rámečky a platformy jako Spring a OSGi používají vzory a vylepšení specifikace JAR k zajištění prostředí pro vytváření velmi schopných a modulárních systémů. Postupem času však i tyto nástroje podlehnou velmi nešťastnému vedlejšímu účinku specifikace JAR, peklo JAR!
Classpath / JAR peklo
Pokud běhové prostředí Java umožňuje libovolně složité zaváděcí mechanismy JAR, vývojáři vědí, že jsou v classpath peklo nebo JAR, sakra. K tomuto stavu může vést řada konfigurací.
Nejprve zvažte situaci, kdy vývojář aplikace Java poskytuje aktualizovanou verzi aplikace a zabalil ji do souboru JAR se stejným názvem jako stará verze. Běhové prostředí Java neposkytuje žádné ověřovací prostředky pro určení správného souboru JAR. Běhové prostředí jednoduše načte třídy ze souboru JAR, který najde jako první nebo který splňuje jedno z mnoha pravidel classpath. To vede v nejlepším případě k neočekávanému chování.
Další instance pekla JAR vzniká, když dvě nebo více aplikací nebo procesů závisí na různých verzích knihovny jiného výrobce. Pomocí standardních zařízení pro načítání tříd bude za běhu k dispozici pouze jedna verze knihovny jiného výrobce, což povede k chybám alespoň v jedné aplikaci nebo procesu.
Plnohodnotný a efektivní systém modulů Java by měl usnadnit rozdělení kódu na odlišné, snadno pochopitelné a volně spojené moduly. Závislosti by měly být jasně specifikovány a přísně vynucovány. Měla by být k dispozici zařízení, která umožňují upgradovat moduly, aniž by to mělo negativní dopad na ostatní moduly. Modulární běhové prostředí by mělo umožnit konfigurace, které jsou specifické pro konkrétní doménu nebo vertikální trh, čímž by se snížila doba spuštění a systémová stopa prostředí.
Modularita řešení pro Javu
Spolu s dosud zmíněnými funkcemi modularity nedávné snahy přidávají několik dalších. Následující funkce jsou určeny k optimalizaci výkonu a povolení rozšíření běhového prostředí:
- Segmentovaný zdrojový kód: Zdrojový kód rozdělený na odlišné segmenty v mezipaměti, z nichž každý obsahuje konkrétní typ kompilovaného kódu. Cíle, které zahrnují přeskakování kódu, který není metodou, během zametání paměti, přírůstkových sestavení a lepší správy paměti.
- Prosazování v době sestavení: Jazykové konstrukce pro vynucení jmenných prostorů, správy verzí, závislostí a další.
- Nasazení zařízení: Podpora pro nasazení škálovaných běhových prostředí podle konkrétních potřeb, například prostředí mobilního zařízení.
Řada specifikací a rámců modularity se snažila tyto funkce usnadnit a několik z nich se nedávno dostalo na špici v návrzích pro Javu 9. Níže je uveden přehled návrhů Java modularity.
JSR (Java Specification Request) 277
Aktuálně neaktivní je Java Specification Request (JSR) 277, Java Module System; představen společností Sun v červnu 2005. Tato specifikace pokrývala většinu stejných oblastí jako OSGi. Stejně jako OSGi, JSR 277 také definuje zjišťování, načítání a konzistenci modulů, s řídkou podporou pro běhové úpravy a / nebo kontrolu integrity.
Nevýhody JSR 277 zahrnují:
- Žádné dynamické načítání a vykládání modulů / svazků
- Žádné runtime kontroly jedinečnosti třídního prostoru
OSGi (iniciativa Open Service Gateway)
Platforma OSGI, kterou představila Aliance OSGI v listopadu 1998, je nejrozšířenější modularitou odpovědí na formální standardní otázku pro Javu. Aktuálně ve vydání 6 je specifikace OSGi široce přijímána a používána, zejména pozdě.
OSGi je v podstatě modulární systém a servisní platforma pro programovací jazyk Java, která implementuje kompletní a dynamický model komponenty ve formě modulů, služeb, nasaditelných balíčků atd.
Primární vrstvy architektury OSGI jsou následující:
- Prováděcí prostředí: Prostředí Java (například Java EE nebo Java SE), pod kterým bude balíček spuštěn.
- Modul: Kde OSGi framework zpracovává modulární aspekty svazku. Zde se zpracovávají metadata svazku.
- Životní cyklus: Inicializace, spuštění a zastavení svazků se děje zde.
- Servisní registr: Kde balíčky uvádějí své služby, aby je mohly objevit další balíčky.
Jednou z největších nevýhod OSGi je nedostatek formálního mechanismu pro instalaci nativního balíčku.
JSR 291
JSR 291 je rámec dynamických komponent pro prostředí Java SE, který je založen na OSGi, je v současné době v konečné fázi vývoje. Tato snaha se zaměřuje na převzetí OSGi do běžné Javy, jak to bylo pro mobilní prostředí Java provedeno JSR 232.
JSR 294
JSR 294 definuje systém metamodulů a deleguje skutečné provedení zásuvných modulů (verze, závislosti, omezení atd.) Na externí poskytovatele. Tato specifikace zavádí rozšíření jazyka, například „superbalíčky“ a hierarchicky související moduly, aby se usnadnila modularita. Součástí zaměření spec je také přísné zapouzdření a odlišné kompilační jednotky. JSR 294 v současné době spí.
Projekt Jigsaw
Project Jigsaw je nejpravděpodobnějším kandidátem na modularitu v prostředí Java 9. Jigsaw se snaží pomocí jazykových konstrukcí a konfigurací prostředí definovat škálovatelný systém modulů pro prostředí Java SE. Mezi hlavní cíle hry Jigsaw patří:
- Díky tomu je velmi snadné škálovat běh prostředí Java SE a JDK na malá zařízení.
- Zlepšení zabezpečení prostředí Java SE a JDK zákazem přístupu k interním API JDK a vynucením a zdokonalením
SecurityManager.checkPackageAccessmetoda. - Zlepšení výkonu aplikace prostřednictvím optimalizace stávajícího kódu a usnadňování technik optimalizace dopředného programu.
- Zjednodušení vývoje aplikací v prostředí Java SE umožněním konstruování knihoven a aplikací z modulů poskytovaných vývojáři a z modulárního JDK
- Vyžadování a vynucování omezené sady omezení verze
JEP (Java Enhancement Proposal) 200
Návrh Java Enhancement 200 vytvořený v červenci 2014 se snaží definovat modulární strukturu pro JDK. JEP 200 staví na rámci Jigsaw, aby usnadnil segmentaci JDK, podle Java 8 Compact Profiles, do sad modulů, které lze kombinovat v době kompilace, doby sestavení a doby nasazení. Tyto kombinace modulů lze poté nasadit jako zmenšená běhová prostředí, která se skládají z modulů kompatibilních s Jigsaw.
JEP 201
JEP 201 se snaží navázat na Jigsaw a reorganizovat zdrojový kód JDK na moduly. Tyto moduly lze poté zkompilovat jako odlišné jednotky vylepšeným systémem sestavení, který vynucuje hranice modulů. JEP 201 navrhuje schéma restrukturalizace zdrojového kódu v celé JDK, které zdůrazňuje hranice modulů na nejvyšší úrovni stromů zdrojového kódu.
Penrose
Penrose by řídil interoperabilitu mezi Jigsaw a OSGi. Konkrétně by to usnadnilo schopnost upravovat mikrok jádra OSGi, aby balíčky běžící v upraveném jádře mohly využívat moduly Jigsaw. Při popisu modulů se spoléhá na použití JSON.
Plány pro Javu 9
Java 9 je jedinečné hlavní vydání pro Javu. Díky čemuž je jedinečný díky zavedení modulárních komponent a segmentů v celém JDK. Primární funkce podporující modularizaci jsou:
- Modulární zdrojový kód: V prostředí Java 9 budou prostředí JRE a JDK reorganizována do interoperabilních modulů. To umožní vytvoření škálovatelných modulů runtime, které lze spustit na malých zařízeních.
- Segmentovaná mezipaměť kódu: I když to není striktně modulární zařízení, nová segmentovaná mezipaměť kódu Java 9 bude následovat ducha modularizace a bude využívat některé ze stejných výhod. Nová mezipaměť kódu provede inteligentní rozhodnutí o kompilaci často přístupných segmentů kódu do nativního kódu a jejich uložení pro optimalizované vyhledávání a budoucí spuštění. Halda bude také rozdělena na 3 odlišné jednotky: kód bez metody, který bude trvale uložen v mezipaměti; kód, který má potenciálně dlouhý životní cyklus (známý jako „neprofilovaný kód“); a kód, který je přechodný (známý jako „profilovaný kód“).
- Prosazování v době sestavení: Systém sestavení bude prostřednictvím JEP 201 vylepšen o kompilaci a vynucování hranic modulů.
- Nasazení zařízení: V rámci projektu Jigsaw budou poskytnuty nástroje, které budou podporovat hranice modulů, omezení a závislosti v době nasazení.
Předčasné vydání Java 9
Přestože přesné datum vydání Java 9 zůstává záhadou, můžete si stáhnout vydání pro předčasný přístup na webu Java.net.
Závěrem
Tento článek představuje přehled modularity v rámci platformy Java, včetně vyhlídek na modularitu v prostředí Java 9. Vysvětlil jsem, jak dlouholeté problémy, jako je classpath hell, přispívají k potřebě modulárnější architektury Java a diskutoval jsem o nejnovějších nových modularitách funkce navržené pro Javu. Poté jsem popsal a kontextualizoval každý z návrhů nebo platforem Java modularity, včetně OSGi a Project Jigsaw.
Potřeba modulárnější architektury Java je jasná. Aktuální pokusy zaostaly, i když OSGi je velmi blízko. Pro vydání Java 9 budou Project Jigsaw a OSGi hlavními hráči v modulárním prostoru pro Javu, přičemž mezi nimi bude možná lepidlo Penrose.
Tento příběh „Modularita v prostředí Java 9: Stacking up with Project Jigsaw, Penrose a OSGi“ byl původně publikován společností JavaWorld.
