Hi omnes! Haec est secunda tabella in nostra serie de Quarkus - hodie de compilatione nativi loquemur.
Est Java BIBLIOTHECA ad formandam . Dum certe hic multum est, multum boni operis in multis aspectibus egimus, etiam JVM optimizing et aliquot compages. Una linearum Quarkus quae ab cyclis auctam attulit usuram habet comprehensivam, inconsutilem accessum ad convertendum in codice Javae in lima exsecutabile pro specifica systemate operante (sic dicto "cogilation nationale"), simile cum C et C++, ubi talis compilatio plerumque occurrit in fine cycli aedificandi, experiendi, instruere.
Et dum vernacula compilatio interest, ut infra ostendemus, notandum est Quarkus re vera bene currere in machina communissima Java, OpenJDK Hotspot, propter emendationes effectus per acervum perficiendum. Quapropter compilatio vernacula censenda est ut bonus adiectio quae pro desiderato vel necessario adhiberi potest. Re vera, Quarkus graviter innititur in OpenJDK cum ad imagines indigenas venit. Modus autem dev, ab tincidunt benigne acceptus, prope momentaneum experimentum mutationum efficit ob progressas facultates dynamici codicis exsecutionis in Hotspot effectae. Praeterea, cum imagines indigenae GraalVM creant, bibliotheca classis OpenJDK et facultates HotSpot adhibentur.
Cur ergo indigena compilatione opus est, si omnia iam perfecte optimized sunt? Hoc infra respondere conabimur.
Incipiamus cum manifesto: rubrum Hat amplam experientiam optimizing JVMs, acervos et compages in progressione project. , comprehendo:
- Primum application server ad operandum in nube in suggestu .
- Primum application servo pro currit in computers .
- Primum application servo currere on .
- In rhoncus inceptis currit adinventiones .
Cum provocationibus applicationum Javaum in nube currendi et de machinationibus resource constrictis (lege: IoT) per multos annos tractavimus, et plus e JVM in terminis agendi et memoriae optimizationis obtinere didicerunt. Sicut multi alii, cum indigena compilatione applicationum Javae per longum tempus laboravimus , , atque adeo bene novimus de pros et cons huius adventus (exempli gratia, dilemma eligendi inter universalitatem "aedificandi semel - currendi-usquam" et quod applicationes compilata minores sunt ac celerius currunt.
Quid interest has pros et cons considerare? Quia in aliquibus in adiunctis earum proportio fit decisiva;
- Exempli gratia, in culturae / eventus agitatae ambitus ubi in (difficile vel molle) verum tempus ut tempus ad respon- dendum. Dissimilis diuturna officia persistentia, hic duratio principii frigoris critico responsionem postulat tempus auget. JVM adhuc notabile temporis initium sumit, et dum in aliquibus casibus meris ferramentis modos minui potest, differentia unius secundi et 5 millium secundorum inter vitam et mortem potest esse differentia. Ita, hic circum ludere potes cum subsidiis calidis machinarum Javarum (quod, exempli gratia, cum "fecerimus" ) , sed hoc per se non spondet satis esse JVMs ad processum petitiones ut onus librae. Et ex parte oeconomica, verisimile non est optio rectissima.
- Praeterea, alia ratio est quae saepe poplitem: multitudo. Quamvis JVMs propemodum accesserint ad systemata operandi in suis facultatibus, tamen non possunt facere id quod in Linux in processibus separatis consuevimus. Ergo, defectus unius fili totam machinam Javam deducere potest. Multi circa hoc incommodum conantur dedicare singulas JVM pro singulis applicationibus usoris ut minuere consectaria defectio. Consentaneum hoc est, sed scalis non decere.
- Praeterea, ad applicationes nubilum ordinatae, index magni momenti est densitas servitiorum in exercitu. Transitus ad methodologiam , microservices et Kubernetes per applicationem machinarum Javarum numerum augent. Hoc est, ex una parte, haec omnia elasticitatem et constantiam praebet, sed simul sumptio turpium memoriae pro servitio etiam augetur, et quaedam huiusmodi expensae non semper stricte necessariae sunt. Statice imagini exsecutabiles compilavit hic ob varias optimizationes technicas, ut low-gradu cadaveris eliminationis, cum ultima imago illas tantum partes compagum (inclusa ipsa JDK) includit, qua servitium actu utitur. Ideo Quarkus indigena compilatio adiuvat ut instantiae servitutis locum dense ponat in securitate hospitii sine detrimento.
Profecto argumenta praedicta satis iam sunt ad intellegendam iustificationem compilations vernaculae ex parte consilii participes Quarkus. Alia tamen est, non-technica, sed etiam magni momenti ratio: in annis multis programmatibus et societatibus evolutionis Javam in favorem linguarum programmandi novarum reliquerunt, credens Javam, una cum suis JVMs, acervis et compagibus nimis factum esse. memor famelicus, segnius, etc.
Solet tamen eodem instrumento ad solvendam quaestionem esse . Aliquando melius est pedem recipere et aliud quaerere. Et si Quarkus homines morari et cogitare facit, tum illud bonum totius Javae ecosystematis facit. Quarkus porttitor conspectum repraesentat quomodo applicationes efficaciores aedificandi, faciens Javam magis ad novas applicationes architecturas quasi ministras pertinentes. Praeterea, propter eius extensionem, Quarkus spem integram extensionum ecosystematis Iavae habebit, signanter numerum compagum augens quae compilationem in applicationibus ex archa sustentabunt.
Source: www.habr.com