Přiznám se bez obalu, že nesnáším tyto nadšenecké články. Ve slaboduchých vyvolávají mylné dojmy iluzích různých pozitivních změn(revolucí), tvz. jsou manipulativní a ti jsou pak zklamaní . Jako člověk co využívá Javu tak vyjádřím aktuální negativa u Javy :
- změna licenčních podmínek u Oracle Java
- rychlejší vydávání verzí JavySE
- pomalé vydávání oprav JavaEE např. GlassFishu ( samozřejmě vím že přešel nedávno pod Eclipse, ale když byl pod Oracle vyšli pro EE7 pouze 3x opravy - za cca 3 roky )
- katastrofální podpora multimedií v API
- nekvalitní dokumentace k API ( jako kdyby to psaly Indové, triviální věci jsou napsané pod psa ale skutečně obtížné věc jenž se často nepoužívají jsou napsané katastrofálně )
Autore odkud bereš informaci že se jedná o native-image ? Dle specifikací se jedná o JEP 220 (Modular Run-Time Images), takže se jedná o run-time image. Já osobně na to čekal od Java6 ale faktem je že to přišlo příliš pozdě, tato věc tu měla být tak na konci 90.let a nikoliv 2017. Java prakticky DESKTOP sektor prohrála a ani toto to nezmění.
I kdyby byl PÁN BŮH, specifikace je jednou standardizovaná a pojmenovaná a tím to hasne.
https://openjdk.java.net/jeps/220
Vlastní označení(pojem) může neznalé vést ke zmatenosti.
Evidentně patříš mezi hlupáčky, na které podpis pod jménem dělá DOJEM. Doporučuji nejdříve si to nastudovat, naučit, pochopit a používat vlastní mozek. Stejným způsobem tu po revoluci přišel Kožený, oháněl se titulem s Hardwardu a naivní hlupáci(jejíchž si zjevně potomek dle zákonu genetiky) z něj padaly na hubu. A pak až si uvědomily, že s nimi bylo vymrdáno bylo už pozdě.
Mě přijde že mateš ty, a to dost šíleně. native-image vytvoří z javovských zdrojáků přeloženou nativní binárku, která už nepotřebuje k běhu virtuální stroj. JEP 220 mluví o reorganizaci JRE a JDK a změně formátu JARek (které se pak asi budou jmenovat jinak). Reálná souvislost mezi native-image a JEP-220 (a tedy i článkem a tvým komentářem) je velmi nízká, snad až na to že JEP 220 počítá s tím, že by v "nových JARkách" mohlo být možné mít uložené předkompilované verze bytekódu.
Už se moc nedivím, že ti dokumentace Javy přijde špatná. Porozumění ti moc nejde.
native-image není (zatím) specifikována žádným JEPem, takže to určitě není to samé jako JEP 220. Navíc GraalVM 1.0.0 RC9 je rozšířením JDK8 - a ten JEP 220 je jen v JDK9 a více.
Tomuto ty říkáš odpověď?
Proč v tvém příspěvku NENÍ jako argument použit standard(specifikace JEP) která v Javě tvz. native-image definuje nebo aspoň používá ? Takto to tvou odpověď dělá pouze lichou a bezpředmětnou, kdy opakuješ fráze které ví snad každý.
Jak další argument bych akceptoval kdybys popsal tedy "správnou "definici" "run-time image". Jenže jsi tak zjevně hloupí, že ani to tě nenapadlo.
Souvislost mezi JEP220 je zásadní a to proto hned z několik důvodů :
1) že JEP220 a odkazuje se na další JEP které jsou pro to nutná (proto jsem tu dal link) - ty jsi se na žádný url odkaz ani nevzmohl
2) je součástí specifikací Modularity, stejně jako jlink a bez modularity dané řešení nefunguje. Staré projekty v jar bez module-info.java by se tedy neměli takto převést.(ovšem aktuálně to nemám otestované, neboť v betě Java9 před 2 lety kdy jsem to zkoušel to nefungovalo)
PS. a ano, skutečně jako menza jedinec mám dost často problém s porozuměním výplodů slabomyslných mozečků. Dost často totiž pletou páté přes deváté(z důvodu zmatenosti) a nic jim pořádně nefunguje, často při výzvách selhávají, mají problémy se pořádně vyjádřit( tzv. vymáčkout ), ty jsi toho přímí důkaz.
PSS. Když ti je vše jasné, a domníváš že tomu rozumíš, co ti brání nechovat je jako LÍNÝ CIGÁN a udělat na to český tutoriál. Snad jenom to, že se domníváš chybně, uvědomuješ si to a proto se bojíš to zveřejnit(jít s kůží na trh). Anebo máš pravdu, já se mýlím a můžeš nás všechny poučit. Jak říkám stačí nebýt LÍNÝ JAKO CIGÁN.
PSSS. já už si v tom několik programů( to i vč. GUI - abych si to pořádně otestoval) za poslední dva roky udělal, co ty ?
PS. = post scriptum
PSS. = post scriptum scriptum
PSSS. = post scriptum scriptum scriptum
stejná logika jako u oblečení
S small
M medium
L large
XL extra large
XXL extra extra large
XXXL extra extra extra large
nebo označení pařby
party = hlavni událost večera(noci)
after party = mejdan u někoho po ránu(dopoledne)
after after party = další mejdan u někoho dalšího nebo pokračování chlastání v hospodě odpoledne
atd...
tedy tak to za nás aspoň 90tých fungovalo.
většinou nereaguji, ale ty se chováš jako bys spolkl všechen rozum světa - což je průvodní jev toho, že ve skutečnosti víš howno - ale kolega tu s tebou polemizuje o tom tvém PSSSSS - protože jsi opět odpověděl jako trotl, tak ti dám poslední šanci se opravit a zamyslet nad: post scriptum scriptum scriptum vs post post post scriptum - možná toto pomůže lépe chytrolíne: post scriptum scriptum scriptum == nesmysl vs post (post (post scriptum)) a na závěr, změň své vyjadřování, protože, když jsi d3bil, což zjevně jsi (hodnotím tvůj projev zde), tak aspoň zkus omezit svou aroganci, i když si myslíš, že jsi hrozně chytrej
Desktop sector? Native-image ma praveze velky zmysel v cloude,kde potrebujete okamzity start sluzby - idealne ak si pamata svoj stav a po vykonani zase uspat...aspom co sa tyka resource managementu...
Viete vy vobec ako dlho trva inicializacia springoveho (spring boot) kontaineru v beznych podmienkach?
"Viete vy vobec ako dlho trva inicializacia springoveho (spring boot) kontaineru v beznych podmienkach"
Jo, to nahodou vim.
Samotny spring boot container pro commandline plaikaci tak kolem 1 sekundy, s embedded Tomcatem cca 5 sekund, s navic pribalenym Apache CXF 7 sekud, s navic pribalenym Spring security, hibernate, primefaces (celkem 70 MB FAT JAR) cca 10 sekund.
Vse mereno na nobeooku Thinkpad T430 Core i5 z roku 2012.
Nespravne, je uplne jedno, jestli pul roku bezici microservice startuje sekundu nebo pet.
GO ma vyhodu u mikrotransakci hlavne z duvodu lehkych threadu channels/goroutines.
Java ma thready mnohem tezsi a s velkym overheadem pri vytvareni/zavirani.
Java se to snazi resit reaktivne, ale prace s takovym kodem je opruz.
Channely a gorutiny jsou jedina vec, co ma Go lepsi nez Jawa, jinak je to slabota.
Nespravne, je uplne jedno, jestli pul roku bezici microservice startuje sekundu nebo pet.
A BaaS ti nic nehovori ? Platite v cloude 24/7 cenu? No tak to sa nedivim, ze je to potom drahe !!! Je rozdiel, ked mam obsluhovat poziadavku raz za 5 sekund a kvoli tomu startovat springovy kontainer alebo pouzitim native-image mam perzistovany stav microsluzby... btw 1 za 5 sekundy znamena 80% usporu nakladov.
> změna licenčních podmínek u Oracle Java
Oracle Java je primarne urcena pro platici zakazniky. Nejsi jim? Tak potom je pro tebe AdoptOpenJDK.
> - rychlejší vydávání verzí JavySE
V cem je tohle presne nevyhoda?
> Java prakticky DESKTOP sektor prohrála a ani toto to nezmění.
Souhlas. Java desktop sektor prohrala a desktop trh navic jeste umrel:))
GraalVM je pro microservices a ne pro desktop.
Glassfish mal mat odnoz Paraya, vraj je to rychlejsie opravovane. Raz som to skusal, ani mi to neslo. S Glassfish som mal vzdy nejake problemy. Jedine co mi poriadne funguvalo z volne dostupnych bol Wildfly.
K spomenutym negativam Javy by som este pridal neistotu ohladom buducnosti (kvoli Oracle) a neexistenciu normalnych funckii. Nutnost trepat vsetko do tried je velke minus Javy. Dalej je to extremna celkova narocnost a strma krivka ucenia. Onedlho nebude nik, kto by chcel do toho ist.
Co se týče budoucnosti Javy, toho bych se nebál. Osobně vkládám velké naděje do Correto což je JDK od Amazonu, který se rozhodl udržovat vlastní verzi Javy 8 ještě dalších 5 let a plně zadarmo(plus nové verze také jsou). Myslím že Oracle na svou nenažranost dojede a změna licence javy se mu vymstí. Amazon to sice dělá kvůli cloudu ale je to bezproblému použitelné pro linux desktop i mac.