Ջավա վիրտուալ մեքենա

Վիքիպեդիայից՝ ազատ հանրագիտարանից
Ջավա վիրտուալ մեքենա
Տեսակrun-time system?, Համակարգչային պլատֆորմ, cross-platform software? և Վիրտուալ իրականություն
Ենթադասrun-time system?
Նախագծումը՝Sun Microsystems
 Java Virtual Machine Վիքիպահեստում

Ջավա վիրտուալ մեքենա (անգլ.՝ Java Virtual Machine (JVM)), վիրտուալ մեքենա, որը թույլատրում է համակարգչին գործարկել Ջավա ծրագրեր, ինչպես նաև այլ ծրագրեր, գրված այլ լեզուներով, որոնք նույնպես կարող են թարգմանվել Ջավա բայթկոդի։ Ջավա վիրտուալ մեքենան ունի մանրամասն բնութագիր, որը պաշտոնապես նկարագրում է Ջավա վիրտուալ մեքենայի իմպլեմենտացման պահանջները։ Բնութագիր ունենալը ապահովում է Ջավա ծրագրերի տարբեր իմպլեմենտացիաներով փոխգործունակությունը, և ծրագրի հեղինակները, ովքեր օգտագործում են Java Development Kit (JDK) կարիք չունեն անհանգստանալու հիմքում ընկած սարքախմբի մասին։

Ջավա վիրտուալ մեքենայի նախնական իմպլեմենտացիան արվել է OpenJDK ծրագրի կողմից, որպես բաց կոդ և ներառում է HotSpot կոչվող JIT compiler-ը։ Կոմերցիոն Ջավա թողարկումները, որոնք հասանելի են Oracle-ում հիմնված են OpenJDK-ի գործարկման ժամանակի վրա։ Eclipse OpenJ9-ը մեկ ուրիշ բաց կոդով Ջավա վիրտուալ մեքենա է OpenJDK-ի համար։

Ջավա վիրտուալ մեքենայի բնութագիր[խմբագրել | խմբագրել կոդը]

Ջավա վիրտուալ մեքենան աբստրակտ համակարգիչ է սահմանված բնութագրով։ Այն Ջավա գործարկման ժամանակի (անգլ.՝ Java Runtime Environment) միջավայրի մաս է։ Օգտագործված է աղբահավաքման ալգորիթմը և վիրտուալ մեքենայի ցանկացած ներքին օպտիմիզացիա(դրանց թարգմանումը մեքենայական կոդի) հասանելի չէ։ Սրա հիմնական նպատակը իմպլեմենտացնողներին անիմաստ չսահմանափակելն է։ Ցանկացած Ջավա հավելված կարող է գործարկվել միայն Ջավա վիրտուալ մեքենայի աբստրակտ հատկանիշներով իմպլեմենտացիայում[1]։

Սկսած Java Platform, Standard Edition (J2SE) 5.0-ից Ջավա վիրտուալ մեքենայի հատկանիշները զարգացվել են Java Community Process -ի տակ, որպես JSR 924[2]։ 2006-ից, հատկանիշների փոփոխություններ են արվում, որպեսզի մեքենան կարողանա սպասարկել կլասի ֆայլ ֆորմատի փոփոխված տարբերակը(JSR202)[3]։ Դա արվել է, որպես սպասարկման թողարկում JSR 924։ Ջավա վիրտուալ մեքենայի բնութագիրը հրապարկվել է կապույտ գրքով[4], որի նախաբանում ասվում է․

Մենք նպատակ ենք դրել, որ այս բնութագիրը բավարար չափով թղթաբանական նկարագիր տա Ջավա վիրտուալ մեքենայի մասին, որպեսզի մրցունակ և մաքուր իմպլեմենտացիաները դառնան հնարավոր։ Oրաքլը տրամադրում է թեստեր, որոնք հաստատում են Ջավա վիրտուալ մեքենայի ճշգրիտ գործելակերպը։
- Sun Microsystems

Օրաքլի Ջավա վիրտուալ մեքենաներից մեկը անվանվել է ՀոթՍփոթ, մյուսը, որը ժառանգված է BEA Systems-ից անվանվել է ՋեյՌոքիթ։ Օրքալը Ջավա բրենդի սեփականատերն է և կարող է թույլատրել դրա գործածումը փաստելու համար, որ իմպլեմենտացիան համապատասխանում է և մրցունակ է Օրաքլի բնութագրի հետ։

Class loader[խմբագրել | խմբագրել կոդը]

Ջավա վիրտուալ մեքենայի խմբավորող միավորներից մեկը դասն է (անգլ.՝ class): Class loader-ի իմպլեմենտացիան պետք է ունակ լինի ճանաչելու և բեռնելու ցանկացած բան,որը համապատասխանում է Ջավա ֆայլ ֆորմատին։ Ցանկացած իմպլեմենտացիա ազատ է ճանաչելու այլ բինար ձևեր բացի դասային (անգլ.՝ class) ֆայլերից, բայց այն պարտավոր է ճանաչել դասային ֆայլը։

Class loader-ը կատարում է այս երեք հիմնական գործողությունները խիստ հերթականությամբ․

  1. Բեռնում։ գտնում և ներմուծում է բինար տվայալները համապատասխան տեսակի համար
  2. Կապում։ կատարում է հաստատում, պատրաստում և որոշում(ընտրովի)
    • Հաստատում։ հաստատում է ներմուծված տեսակի ճշտությունը
    • Պատրաստում։ դասի փոփոխականների համար հատկացնում հիշողության տարածք և սահմանում է հշողության նախնական արժեքները
    • Որոշում։ փոխարինում է սիմվոլիկ հասցեները որոշված հասցեով
  3. Սկզբնավորում։ կանչում է Ջավա կոդ, որը սահմանում է դասային փոփոխականները իրենց համապատասխան սկզբնական արժեքներով։

Ընդհանուր առմամբ, կան երեք տեսակի class loader-ներ․bootstrap class loader, լրացման class loader and Համակարգի / Հավելվածի class loader։

Ցանկացած Ջավա վիրտուալ մեքենայի իմպլեմենտացիան պետք է ունենա bootstrap class loader, որը ունակ է բեռնել վստահված դասեր, ինչպես նաև լրացման class loader կամ հավելվածի class loader։ Ջավա վիրտուալ մեքենայի բնութագիրը չի մասնավորեցնում,թե ինչպես class loader-ը պետք է տեղայնացնի դասերը։

Վիրտուալ մեքենայի կառուցվածքը[խմբագրել | խմբագրել կոդը]

Ջավա վիրտուալ մեքենան աշխատում է որոշակի տիպերի տվայլների հետ, ինչպես գրված է Ջավա վիրտուալ մեքենայի բնութագրում։ Տվյալի տիպերը կարող են բաժանվել[5] երկու պրիմիտիվ տիպերի(integers, Floating-point, long և այլն) և Reference տիպերի։ Ավելի վաղ JVM-ները միայն 32-բիթ մեքենաների վրա էին։ long և double տիպերը, որոնք 64-բիթ են, տեղային են, բայց զբաղեցնում են երկու միավոր հիշողության տարածք լոկալ փոփոխականների շրջանակում կամ օպերանդների stack-ում, քանի որ ամեն միավորը 32-բիթ է։ boolean, byte, short, and char տիպերը նշան-լրացվող են(բացի char -ից, որը զրո-լրացվող է) և գործածվում են որպես 32-բիթ ամբողջ թվեր, այնպես, ինչպես int տիպերը։ Ավելի փոքր տիպերը միայն ունեն մի քանի տիպին բնորոշ հրահանգներ բեռնելու, պահեստավորման և տեսակի փոփոխության համար։ boolean -ը գործածվում է, որպես 8-բիթ byte արժեք, որտեղ 0-ն ներկայացնում է false և 1-ը ներկայացնում է true։ (Չնայած, որ boolean դիտարկվել է որպես տիպ սկսած Ջավա վիրտուալ մեքենայի նկարագրի 2-րդ հրատարակությունից(Java Virtual Machine Specification, Second Edition), որը պարզաբանել է այս խնդիրը, կոմպիլացված և գործարկված կոդում քիչ տարբերություն կա boolean և byte-ի միջև, բացառությամբ մեթոդի ստորագրություններում անունների խառնման և boolean զանգվածների տիպերի։ boolean-ը մեթոդների ստորագրություններում նշվում է, որպես Z, իսկbyteը նշվում է, որպես B։ Բուլյան զանգվածները ունեն boolean[]-տիպը, բայց օգտագործում են 8-բիթ ամեն էլեմենտի համար և JVM-ը չունի ներկառուցված հնարավորություն փաթեթավորել բուլյանները բիթերի զանգվածում, հետևաբար չնայած իրենց տիպին իրենք իրենց դրսևորում են նույն կերպով, ինչպես byte զանգվածները։ Այլ բոլոր գրծածություններում boolean տեսակը էֆֆեկտիվորեն անհայտ է JVM-ին, քանի որ բոլոր բուլյանների հրահանգները օգտագործվում են նաև բայթերի համար)։ Այնուամենայնիվ, ավելի նոր JVM թողարկումները (OpenJDK HotSpot JVM) աշխատում են 64-բիթի համար, հետևաբար կարելի է ունենալ 32 կամ 64-բիթ JVM 64-բիթ օպերացիոն համակարգի վրա։ Ջավան 64-բիթ միջավայրի վրա գործարկելու հիմնական առավելությունն այն է, որ 64-բիթ միջավայրը ապահվում է ավելի մեծ տարածք հասցեների համար։ Սա թույլ է տալիս ունենալ ավելի մեծ Ջավա դինամիկ հիշողության տարածք և ավելի մեծ Java Threads, որը անհրաժեշտ է մեծ հավելվածների որոշ տեսակների համար․ այնուամենայնիվ կա կատարողականության տարբերություն 64-բիթ JVM և 32-բիթ JVM օգտագործելու մեջ։  

JVM-ը ունի աղբահավաքման կույտ օբյեկտներ և զանգվածներ պահեստավորելու համար։ Կոդերը, կոնստանտներըը կամ այլ դասի տվյալներ պահեստավորվում են «մեթոդի տարածքում»։ Մեթոդի տարածքը տրամաբանորեն դինամիկ հիշողության մասն է, բայց իմպլեմենտացիաները հնարավոր է մեթոդի տարածքին վերաբերվեն որպես դինամիկ հիշողությունից առանձին բան և հանարավոր է աղբահավաքը չհավաքի այն։ Ամեն JVM thread-ը նույնպես ունի իր կանչերի stack-ը, որը պահեստավորում է շրջանակներ (անգլ.՝ frame): Նոր շրջանակը ստեղծվում է ամեն անգամ երբ մեթոդը կանչվում է և ոչնչացվոըմ է, երբ մեթոդը գոյություն ունի։

Ամեն շրջանակը ապահովում է operand-ների stack-ը և լոկալ փոփոխականների զանգվածը։ Օperand-ների stack-ը օգտագործվում է operand-ների համար, որպեսզի գործարկեն հաշվարկները և ստանան կանչված մեթոդի վերադարձնող արժեքը, իսկ լոկալ փոփոխականները ծառայում են նույն նպատակին, ինչ ռեգիստրները և նույնպես օգտագործվում են մեթոդին արգումենտներ փոխանցելու համար։ Այսպիսով, JVM-ը, և՛ stack մեքենա է, և՛ ռեգիստրի մեքենա։ Պրակտիկայում HotSpot-ը ամբողջապես ջնջում է ամեն stack-ը բացի native thread/call stack-ի նույնիսկ, երբ գործարկված է Interpreted mode-ում, քանի որ դրա Templating Interpreter-ը տեխնիկապես աշխատում է ինչպես կոմպիլյատորը։  

Բայթկոդ հրահանգներ[խմբագրել | խմբագրել կոդը]

JVM-ը ունի հրահանգներ առաջադրանքի հետևյալ խմբերի համար․բեռնում և պահեստավորում, թվաբանություն, տիպի փոփոխություն, օբյեկտի ստեղծում և փոփոխում, operand-ների stackի կառավարում(push/ pop), տրանսֆերի կառավարում(branching), մեթոդի կանչում և վերադարձ, excpetion-ների նետում, մոնիտորի վրա հիմնված զուգորդում։

Նպատակը բինար մրցակցումն է։ Ամեն հյուրընկալ օպերացիոն համակարգը կարիք ունի իր ուրույն JVM իմպլեմենտացիայի և գործարկման միջավայրի։ Այս JVM-ները նույն կերպ են ընկալում բայթկոդը իմաստային առումով, բայց իրական իմպլեմենտացիան կարող է լինել տարբեր։ Ավելի բարդ քան բայթկոդը կրկնօրինակելը, մրցունակ ու էֆեկտիվ Java core API-ի իմպլեմենտացումն է, որը պետք է կապվի ամեն օպերացիոն համակարգի հետ։ Այս հրահագները աշխատում են ավելի շատ տարածված,քան native տվյալների տիպերի որոշակի հրահանգների խմբի ճարտարապետության հետ։

JVM լեզուներ[խմբագրել | խմբագրել կոդը]

JVM լեզուն ցանկացած լեզու է, որի ֆունկցիոնալությունը կարող է արտայատվել վավեր դասի ֆայլի մոդելով, որը կարող է հյուրընկալվել JVM-ի կողմից։ Դասի ֆայլը պարունակում է JVM հրահանգներ(Ջավա բայթ կոդ) և սիմվոլների աղյուսակ, ինչպես նաև այլ օժանդակ ինֆորմացիա։ Դասի ֆայլի ֆորմատը -սարքախմբից և օպերացիոն համակարգից անկախ բինար ֆորմատ է, որը օգտագործվում է ներկայացնելու կոմպիլացված դասեր և interface-ներ[6]։

Կան մւ քանի JVM լեզուներ, որոնց թվում կան և՛ հին, և նոր լեզուներi։ JRuby-ն ու Jython-ը երևի թե ամենահանրաճանաչ լեզուների են․ լեզուների օրինակ են Ruby-ն և Փայթոնը համապատասխանաբար։ Clojure, Groovy, Scala և Kotlin-ը այն ամենահայտնի լեզուներից են, որոնք ստեղծվել են զրոյից Ջավա բայթկոդի կոմպիլացվելու համար։ Scala- գրադարանները կարող են օգտագործվել Ջավա ծրագրերի հետ և հակառակը[7]։

Java 7 JVM-ը իմպլեմենտում է JSR 292: Supporting Dynamically Typed Languages[8] Ջավա պլատֆորմի վրա, որը նոր հատկանիշ է JVM-ում դինամիկ գրված լեզուների համար։ Այս հատկանիշը զարգացվել է դա Վինչիի մեքենայի պրոեկտի ընթացքում, որի առաքելությունն էր ընդլայնել JVM-ը, ոևպեսզի այն կարողանա սպասարկել Ջավայից բացի այլ լեզուներ[9][10]։

Բայթկոդի վավերացում[խմբագրել | խմբագրել կոդը]

Ջավայի պարզ փիլիսոփայությունը այն է, որ այն ժառանգաբար ավելի ապահով է ընդհատվելուց և ոչ մի օգտատերի ծրագիր չի կարող ձախողել հյուրընկալ մեքենայի աշխատանքրը կամ խանգարել դրան այլ անտեղի գործողություններով։ Հնարավոր է նաև պաշտպանել որոշակի մեթոդներ և տվյալի կառույցներ հասանելիությունից կամ զանցանքներից, որոնք պատկանում են վստահված կոդին։ Ավելին, տարածված ծրագրավորողների սխալները, որոնք հաճախ տանում են զանցանքի կամ անկանխատեսելի վարքի, ինչպիսիք են փորձել հասանելիություն ստանալ զանգվածի վերջին ինդեքսից ավելի բարձր ինդեքսի, կամ օգտագործել չսահմանած pointer թույլատրված չեն։ Որոշ Ջավա հատկանիշներ միավորում են ապահովություն, ներառելով դասի մոդելը, աղբաքավաքված կույտը և վավերացնողը։

JVM-ը վավերացնում է ամբողջ բայթկոդը մինչև դրա գործարկվելը։ Այս վավերացումը կազմված է հիմնականում այս 3 տեսակի ստուգումներից․

  • Branch-ները միշտ վավերացնում են տեղորոշումները
  • Տվյալները միշտ սահմանված են և հասցեները միշտ տիպերից ապահովված են
  • Հասանելիությունը private կամ package private տվյալներին և մեթոդներին խստորեն վերահսկվում է

Առաջին երկուսը սրանցից ստուգում են տեղորոշումը հիմնականում վավերացման քայլում, որը հայտնվում է, երբ դասը բեռնվում է և դառնում է օգտագործման համար հասանելի։ Երրորդը հիմնականում դինամիկ է կատարվում, երբ տվյալների մասերը կամ դասի մեթոդները սկզբում հասանելի են ուրիշ դասերից։

Վավերացնողը թույլատրում է միայն որոշ բայթկոդի հաջորդականություններ վավեր ծրագրերում, օրինակ jump (branch) հրահանգ-ը կարող է միայն թիրախավորել հրահանգը նույն մեթոդում։ Ավելին, վավերացնողը հաստատում է, որ ցանկացած տրված հրահանգը աշխատում է ֆիքսված stack-ի հատվածում[11], թույլատրելով JIT կոմպիլյատորին փոխակերպել stack-ի հասանելիությունը ֆիքսված ռեգիստրի հասանելիության։ Նրա պատճառով, որ JVM-ը stack ճարտարագիտություն է չի նշանակում, որ արագության տուգանք է լինելու ընդօրինակման համար ռեգիստրի վրա հենված ճարտարագիտություններում, երբ օգտագործվում է JIT կոմպիլյատոր։ Կոդով վավերացված JVM ճարտարագիտության վրա տարբերություն չկա, թե JIT կոմպիլյատորը անվանվում է երևակայական ռեգիստրերի կամ երևակայական stack-ի տեղակայումների, որոնք պետք է հատկացվեն թիրախային ճարտարագիտության ռեգիստրներին։ Փաստացի, կոդի վավերացումը JVM-ին դարձնում է տարբեր դասական stack-ի ճարտարագիտությունից, որի էֆֆեկտիվ կրկնօրինակումը JIT կոմպիլյատրով ավելի բարդ է և հիմնականում արվում է ավելի դանդաղ interpreter-ով։ Ավելին, Interpreter-ը,որը օգտագործվում է նախնական JVM-ի կողմից հատուկ տիպ է, հայտնի որպես Template Interpreter, որը թարգմանում է բայթկոդը ուղիղ դեպի native, ռեգիստրի վրա հենված, մեքենայական լեզվի, ոչ թե կրկնօրինակում է stack-ը, ինչպես սովորական interpreter-ը[12]։ HotSpot Interpreter ավելի շատ առումներով կարող է համարվել JIT կոմպիլյատոր, քան իրական Interpreter, քանի որ stack-ի ճարտարագիտությունը,որը բայթկոդը թիրախավորում է իրականում չի օգտագործվում իմպլեմենտացիակում, դրա փոխարեն օգտագործվում է պարզապես միջին ներկայացման բնութագիրը, որը կարող է լավ իմպլեմենտացվել ռեգիստրի վրա հիմնված կառույցում։ Stack-ի ճարտարագիտության պարզապես բնութագիրի և իմպլեմենտացված ռեգիստրի վրա հիմնված վիրտուալ մեքենայի այլ օրինակ է Common Language Runtime[13]։

Բայթկոդի վավերացման օրիգինալ բնութագիրը օգտագործում է բնական լեզում որը ոչ ամբողջական է և սխալ որոշ բաներում։ Շատ փորձեր են արվել JVM-ը, որպես պաշտոնական համակարգ սահմանելու։ Անելով սա, ներկա JVM իմպլեմենտացիաների ապահովությունը կարող է ավելի մանրամասնորեն վերլուծվել, և պոտենցիալ ապահովության շահագործումները կկանխվեն։ Հնարավոր կլինի նաև օպտիմիզացնել JVM-ը խուսափելով ոչ անհրաժեշտ անվտանգային ստուգումներից, եթդ հավելվածը գործարկվում է, կամ ապացուցված է, որ պահով է[14]։

Հեռավար կոդի ապահով գոծարկում[խմբագրել | խմբագրել կոդը]

Վիրտուալ մեքենայի ճարտարագիտությունը թույլ է տալիս ամեն տեսակի մանրամասն գործողությունների կառավարման, որոնց մեքենայական կոդը ունակ է կատարել։ Այն ենթադրում է, որը կոդը իմաստային առումով ճիշտ է, այն հաջողությամբ անցնում է բայթկոդի վավերացման պրոցեսի, մեքենայացված գործիքի միջոցով հնարավոր է վիրտուալ մեքենայից դուրս։ Սա արված է թույլ տալու համար, որ չվստահված կոդը հեռավար աղբյուրներից կարողանա գործարկվել, մոդելը օգտագործված է Java applets-ի կողմից և այլ ապահով կոդի ներբեռնումներից։ Հենց բայթկոդը վավերացվում է, ներբեռնված կոդը աշխատում է սահմանափակված «ավազարկղում», որը պատրաստված է, որպեսզի պաշտպանի օգտատիրոջը սխալ աշխատող կամ վտանգավոր կոդից։ Որպես լրացում բայթկոդի վավերացման պրոցեսին, հրատարակողները կարող են գնել վկայական, որը կարող է թվային ստորագրությամբ հաստատել, որ applet-ները ապահով են, տալով դրանց խնդրել օգտվողին դուրս գալ ավազարկղից և մուտք գործել տեղական ֆայլային համակարգ, clipboard, գործարկել ծրագրային ապահովման արտաքին մասերը կամ network-ը։

Բայթկոդի վավերացնողների պաշտոնական ապացույցը արված է Javacard-ի արդյունաբերությունում (Formal Development of an Embedded Verifier for Java Card Byte Code[15]

Բայթկոդ interpreter և just-in-time կոմպիլյատոր[խմբագրել | խմբագրել կոդը]

Ամեն սարքախմբի ճարտարագիտության համար տարբեր Ջավա բայթկոդ interpreter է անհրաժեշտ։ Երբ համակարգիչն ունի Ջավա բայթկոդի interpreter, այն կարող է գործարկել ցանկացած Ջավա բայթկոդ ծրագիր, և նույն ծրագիրը կարող է գործարկվել ցանկացած համակարգչի վրա, որն ունի այդպիսի interpreter։ Այս խնդիրը մեղմացվել է just-in-time (JIT) compiler- ների կողմից Ջավա կոդը գործարկելու համար։

Երբ Ջավա բայթկոդը գործարկվում է interpreter-ով, գործարկումը միշտ կլինի ավելի դանդաղ, քան եթե նույն ծրագիրը կոմպիլացվի native մեքենայական կոդի։ JIT կոմպիլյատորը կարող է թարգմանել Ջավա բայթկոդը native մեքենայական լեզվի, երբ գործարկի ծրագիրը։ Ծրագրի թարգմանված մասերը կարող են հետո կատարվել ավելի արագ, քան դրանք ինտերպրետացվել են։ Այս տեխնիկան կիրառվում է ծրագրի այն մասերի վրա, որոնք հաճախ են կատարվում։ Այս կերպ JIT կոմպիլյատորը կարող է մեծապես արագացնել ընդհանուր կատարման ժամանակը։

Ջավա ծրագրավորման լեզվի և Ջավա բայթկոդի մեջ չկա անհրաժեշտ կապ։ Ծրագիրը, որը գրված է Ջավայով, կարող է ուղիղ կոմպիլացվել իրական համակարգչի մեքենայական լեզվի և այլ լեզվով գրված ծրագրերը Ջավան կարող է կոմպիլացնել բայթկոդի։

Ջավա բայթկոդը նպատակաուղված է լինել հարթակից անկախ և ապահով[16]։ Որոշ JVM իմպլեմենտացիաներ չեն ներառում interpreter, այլ միայն կազմված են JIT կոմպիլյատորից[17]։

JVM-ը ցանցային զննիչում[խմբագրել | խմբագրել կոդը]

Ջավա հարթակի կյանքի սկզբից ի վեր, JVM-ը շուկա է հանվել, որպես ցանցային տեխնոլոգիա նախատեսված հարուստ ցանցային հավելվածների ստեղծման համար։ 2018-ից ցանցային զննիչների և օպերացիոն համակարգերի մեծ մասը չեն մատակարարվում Java plug-in-ով և չեն թույլատրում կողային բեռնում որևէ ոչ Flash plug-in-ի։ Ջավա զննիչի plugin-ը հնացած է JDK 9-ից սկսած[18]։

NPAPI Java բրաուզերի plug-in-ը նախատեսված է JVM-ին թույլ տալու համար HTML էջերում ներկառուցված այսպես կոչված Java հավելվածներ գործարկել։ Տեղադրված plug-in-ով զննիչների համար aplet-ին թույլատրվում է ներքաշվել իրեն հատկացված էջի ուղղանկյուն հատվածը։ Քանի որ plug-in-ը ներառում է JVM, Java applet-ները սահմանափակված չեն Java ծրագրավորման լեզվով. ցանկացած լեզու, որը թիրախավորում է JVM-ը, կարող է գործարկվել plug-in-ում։ API-ների սահմանափակ հավաքածուն թույլ է տալիս հավելվածներին մուտք գործել օգտատիրոջ խոսափող կամ 3D acceleration, թեև հավելվածները չեն կարողանում փոփոխել էջը իր ուղղանկյուն շրջանից դուրս։ Adobe Flash Player-ը՝ հիմնական մրցակցող տեխնոլոգիան է, որն առումով նույն կերպ է աշխատում։

2015 թվականի հունիսի դրությամբ, ըստ W3Techs-ի, Java applet-ի և Silverlight-ի օգտագործումը նվազել է մինչև 0.1% բոլոր կայքերում, մինչդեռ Flash-ինը նվազել է մինչև 10.8%[19]:

JavaScript JVM-ներ and interpreter-ներ[խմբագրել | խմբագրել կոդը]

2016 թվականի մայիսի դրությամբ JavaPoly-ն օգտատերերին թույլ է տալիս ներմուծել չփոփոխված Java գրադարաններ և դրանք կանչել անմիջապես JavaScript-ից։ JavaPoly-ն վեբկայքերին թույլ է տալիս օգտագործել չփոփոխված Java գրադարաններ, նույնիսկ եթե օգտագործողի համակարգչում Java տեղադրված չէ[20]։

JavaScript-ի transpilation-ը[խմբագրել | խմբագրել կոդը]

JavaScript-ի կատարման արագության շարունակական բարելավումներով զուգորդված շարժական սարքերի ավելացված օգտագործման հետ, որոնց վեբ բրաուզերները չեն ապահովում plugin-ների օգտագործումը, ջանքեր են գործադրվում թիրախավորել այդ օգտվողներին JavaScript-ի transpilation-ի միջոցով։ Հնարավոր է կա՛մ ելակետային կոդը, կա՛մ JVM բայթկոդը փոխարկել JavaScript-ի։

JVM բայթկոդը կոմպիլացնելը, որը համընդհանուր է JVM լեզուների համար, թույլ է տալիս հիմք ընդունել լեզվի գոյություն ունեցող կոմպիլյատորի բայթկոդը։ JavaScript transpiler-ների հիմնական JVM բայթկոդը TeaVM-ն է[21], որը պարունակվում է Dragome Web SDK-ում[22], Bck2Brwsr-ում[23] և j2js-կոմպիլյատորում[24]։

JVM լեզուներից JavaScript-ի առաջատար փոխարկիչները ներառում են Java-to-JavaScript transpiler-ը, որը պարունակվում է Google Web Toolkit-ում, Clojurescript-ում (Clojure), GrooScript-ում (Apache Groovy), Scala.js-ում (Scala) և այլն[25]։

Ծանոթագրություններ[խմբագրել | խմբագրել կոդը]

  1. Bill Venners, Inside the Java Virtual Machine Արխիվացված 2021-01-25 Wayback Machine Chapter 5
  2. «The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 924». Jcp.org. Արխիվացված օրիգինալից 2020 թ․ դեկտեմբերի 24-ին. Վերցված է 2015 թ․ հունիսի 26-ին.
  3. «The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 202». Jcp.org. Արխիվացված օրիգինալից 2012 թ․ փետրվարի 26-ին. Վերցված է 2015 թ․ հունիսի 26-ին.
  4. The Java Virtual Machine Specification Արխիվացված 2008-07-09 Wayback Machine (the first Արխիվացված 2008-10-12 Wayback Machine and second Արխիվացված 2011-09-25 Wayback Machine editions are also available online).
  5. «Chapter 2. The Structure of the Java Virtual Machine». Արխիվացված օրիգինալից 2021 թ․ սեպտեմբերի 15-ին. Վերցված է 2021 թ․ սեպտեմբերի 15-ին.
  6. «The Java Virtual Machine Specification : Java SE 7 Edition» (PDF). Docs.oracle.com. Արխիվացված (PDF) օրիգինալից 2021 թ․ փետրվարի 4-ին. Վերցված է 2015 թ․ հունիսի 26-ին.
  7. «Frequently Asked Questions - Java Interoperability». scala-lang.org. Արխիվացված օրիգինալից 2020 թ․ օգոստոսի 9-ին. Վերցված է 2015 թ․ նոյեմբերի 18-ին.
  8. «The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 292». Jcp.org. Արխիվացված օրիգինալից 2020 թ․ դեկտեմբերի 20-ին. Վերցված է 2015 թ․ հունիսի 26-ին.
  9. «Da Vinci Machine project». Openjdk.java.net. Արխիվացված օրիգինալից 2020 թ․ նոյեմբերի 11-ին. Վերցված է 2015 թ․ հունիսի 26-ին.
  10. «New JDK 7 Feature: Support for Dynamically Typed Languages in the Java Virtual Machine». Oracle.com. Արխիվացված օրիգինալից 2018 թ․ սեպտեմբերի 13-ին. Վերցված է 2015 թ․ հունիսի 26-ին.
  11. «The Verification process». The Java Virtual Machine Specification. Sun Microsystems. 1999. Արխիվացված օրիգինալից 2011 թ․ մարտի 21-ին. Վերցված է 2009 թ․ մայիսի 31-ին.
  12. «HotSpot Runtime Overview - Interpreter». OpenJDK. Արխիվացված օրիգինալից 2022 թ․ մայիսի 21-ին. Վերցված է 2021 թ․ մայիսի 24-ին.
  13. «Why not make CLR register-based? · Issue #4775 · dotnet/runtime». GitHub. Արխիվացված օրիգինալից 2023 թ․ ապրիլի 20-ին. Վերցված է 2021 թ․ մայիսի 24-ին.
  14. Freund, Stephen N.; Mitchell, John C. (1999). «A formal framework for the Java bytecode language and verifier». Proceedings of the 14th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications - OOPSLA '99. էջեր 147–166. CiteSeerX 10.1.1.2.4663. doi:10.1145/320384.320397. ISBN 978-1581132380. S2CID 14302964.
  15. Casset, Ludovic; Burdy, Lilian; Requet, Antoine (2002 թ․ ապրիլի 10). «Formal Development of an Embedded Verifier for Java Card Byte Code» (PDF). Inria - National Institute for Research in Digital Science and Technology at Côte d'Azur University. Արխիվացված (PDF) օրիգինալից 2022 թ․ հոկտեմբերի 3-ին.
  16. David J. Eck, Introduction to Programming Using Java Արխիվացված 2014-10-11 Wayback Machine, Seventh Edition, Version 7.0, August 2014 at Section 1.3 "The Java Virtual Machine"
  17. Oracle JRockit Introduction Արխիվացված 2015-09-06 Wayback Machine Release R28 at 2. "Understanding Just-In-Time Compilation and Optimization"
  18. «Oracle deprecates the Java browser plugin, prepares for its demise». Ars Technica. 2016 թ․ հունվարի 28. Արխիվացված օրիգինալից 2016 թ․ ապրիլի 8-ին. Վերցված է 2016 թ․ ապրիլի 15-ին.
  19. «Historical yearly trends in the usage of client-side programming languages, June 2015». W3techs.com. Վերցված է 2015 թ․ հունիսի 26-ին.
  20. Krill, Paul (2016 թ․ մայիսի 13). «JavaPoly.js imports existing Java code and invokes it directly from JavaScript». InfoWorld. Արխիվացված օրիգինալից 2016 թ․ հուլիսի 25-ին. Վերցված է 2016 թ․ հուլիսի 18-ին.
  21. «TeaVM project home page». Teavm.org. Արխիվացված օրիգինալից 2015 թ․ հունիսի 27-ին. Վերցված է 2015 թ․ հունիսի 26-ին.
  22. «Dragome Web SDK». Dragome.com. Արխիվացված օրիգինալից 2015 թ․ օգոստոսի 1-ին. Վերցված է 2015 թ․ հունիսի 26-ին.
  23. «Bck2Brwsr - APIDesign». Wiki.apidesign.org. Արխիվացված օրիգինալից 2015 թ․ հունիսի 27-ին. Վերցված է 2015 թ․ հունիսի 26-ին.
  24. Wolfgang Kuehn (decatur). j2js-compiler Արխիվացված 2013-09-29 Wayback Machine GitHub
  25. «List of languages that compile to JS · jashkenas/coffeescript Wiki · GitHub». Github.com. 2015 թ․ հունիսի 19. Արխիվացված օրիգինալից 2020 թ․ հունվարի 31-ին. Վերցված է 2015 թ․ հունիսի 26-ին.