Názory k článku Vyšla Java 11: menší core systém a experimentálne garbage collectory
-
technomaniak (neregistrovaný)
Spíš bych čekal místo shrnutí novinek od Java9, více info o Java11. Konkrétně poukázání na změny licenčních podmínek OracleJava vs OpenJava, poukázání na přechod na LTS a vysvětlení distribuci budoucích verzí, zjištění ceny za licencování OracleJava apod.. než podružné detaily o lokálních nových metodách a možnostech.
PS. Mimochodem Eclipse Photon tvz. 09-2018 bez rozšíření vytvoří projekt a spustí OpenJDK11 také, takže logicky bude fungovat i OracleJava.
-
$ /home/andrej/bin/jdk11/bin/java -version
java version "11" 2018-09-25$ head ./SimpleEx.java
#!/home/andrej/bin/jdk11/bin/java --source 11
package com.zetcode;public class SimpleEx {
...$ chmod +x ./SimpleEx.java
$ ./SimpleEx.java
./SimpleEx.java:1: error: illegal character: '#'
#!/home/andrej/bin/jdk11/bin/java --source 11
^
./SimpleEx.java:1: error: class, interface, or enum expected
#!/home/andrej/bin/jdk11/bin/java --source 11
^
2 errors
error: compilation failed#shedoesnotbang
-
Novy gc (neregistrovaný)
Uz od javy 8 slysim, jak je GC uzasny a vylepseny a s kazdou dalsi verzi prichazi novy a novy, jeste lepsi a belejsi, nez ten predtim.
Ma vize je, ze java zacne pomalu zanikat. Pro google je jeji implementace v androide nechtene dite, na serveru je cim dal tim min potreba....
Bohuzel to bude pomale odumirani....
-
Filip JirsákStříbrný podporovatelJá bych na to vůbec nevsázel, myslím, že Java tu bude ještě dlouho po té, co Kotlin zůstane kuriozitou pro pár fandů. Kotlin bych bral spíš jako prototyp, otestují se na něm nějaké věci, a pak přijde něco dalšího, kde budou převzaté věci z Kotlinu, které se osvědčily, a zapomene se na ty, které se nepovedly. Na Kotlinu je až příliš vidět, že je to jazyk psaný odspoda, programátory – chybí tam akademický nadhled, nějaký přesah. Kotlin vypadá, jako když pejsek a kočička vařili dort – aby byl dort dobrý, dali do něj všechno dobré. Akorát ty dílčí dobré věci nefungují spolu navzájem.
-
J. (neregistrovaný)
Cakali sme na prveho dementa , ktory v java vlakne napise nieco podobne. Blahozelam , ziskavas bobrika kratkozrakosti. Pre skusenych java backend vyvojarov , vyuzivajucich naplno vyhody serverovych frameworkov nie je nic horsie ako prebrat kod po developeroch , ktori si vsetko predsa napisu sami ...
-
Filip JirsákStříbrný podporovatel
. (neregistrovaný), 11:40: Porovnávat jazyk a součásti standardní běhové knihovny je jako porovnávat hrušky s přepravkou. Java má od verze 6 podporu skriptovacích jazyků (JSR-223), přímo součástí standardní knihovny JRE byl interpret JavaScriptu Rhino, který byl v JRE 8 nahrazen interpretrem Nashorn. Pokud dál chcete používat JavaScript pomocí JSR-223, budete muset k aplikaci přibalit interpret jako knihovnu, to je vše. Ale pokud to s JavaScriptem v kombinaci s Javou myslíte vážně, podívejte se raději na GraalVM, protože to je budoucnost kombinace Java+JavaScript (a dalších jazyků). Nedává moc smysl udržovat interpret JavaScriptu jako součást standardní knihovny, když máte podporu JavaScriptu zabudovanou přímo v JVM.
-
Filip JirsákStříbrný podporovatel
Například data classes nemohou být open (i když od verze 1.1 aspoň mohou být samy zděděné). Chápu proč to tak je, ale je to přesně ten přístup „přidáme dobrou věc, a už neřešíme, jak spolupracuje se ostatními dobrými věcmi“. Nebo při inicializaci property v primárním konstruktoru nejde použít delegated properties. Opět – inicializace property v primárním konstruktoru je pěkný syntaktický cukřík, delegované properties také. Ale neřeší se, co se stane, když to někdo bude chtít použít dohromady. Vlastně by to jít použít mělo, v dokumentaci jsem nenašel nic o tom, že to nejde, ale kompilátor to prostě nepřeloží, je to neznámá syntaxe. Víc mne z hlavy nenapadá, narazil jsem ještě asi na jeden nebo dva případy během snahy napsat reálný kód. Pak jsem si ještě procházel dokumentaci, a tam přímo bilo do očí, jak každá ta jednotlivá vlastnost je popsaná samostatně s několikařádkovým příkladem, kde je použitá přesně ta jediná vlastnost (pokud možno porovnaná s Javou), ale nikde tam nejsou větší příklady, kde by to bylo zkombinované. Nemůžu si pomoci, ale na mne z toho čiší postup vzniku „hm, tohle mne v Javě nebaví, to by šlo udělat lépe, přidáme na tuhle specialitu novou vlastnost do jazyka“.
Nápady jsou to často hezké, Kotlin se nepochybně nějakou dobu používat bude a určitě bude inspirací pro další jazyky, ale je až příliš viditelné, že je to Java se spoustou záplat. Navíc nemám rád jazyky, které mají tak košatou syntaxi a kdejaké zjednodušení se řeší přímo na úrovni jazyka. (Pro mne už je mírně za hranou Groovy, a Kotlin jde ještě podstatně dál.) Javě se vytýká, že je ukecaná, protože samotný jazyk je vlastně velmi jednoduchý a spousta věcí se řeší až v runtime knihovně. Jenže ono to má tu výhodu, že se pak knihovna může měnit a vyvíjet, nové konstrukce si může přidávat vlastně kdokoli, a jazyk je pořád stejný. Třeba když porovnám null safety, Kotlin si vystačí s jedním až dvěma znaky, Java máOptional<>. JenžeOptional<>mohl do Javy zavést kdokoli, stačilo napsat normální knihovnu (a různé knihovny podobnou funkcionalitu měly). Když se v budoucnosti ukáže, že by se to dalo řešit lépe, vymyslí někdo třeba inverzní tříduMandatory<>, a na syntaxi Javy se nemusí měnit nic. V Kotlinu budou shánět další symbol – a hlavně takovou novinku mohou zavést jenom autoři Kotlinu, nikdo jiný. -
Zrovna Optional je trochu nešťastný příklad:
* Může to teoreticky implementovat kdokoliv, ale úspěch zde dost závisí na tom, aby se to široce používalo. Ve Scale se to s podobným typem Option podařilo, v Javě zatím ne. Kdyby to někdo implementoval jako 3rd party knihovnu, šance na přijetí by byly IMHO celkem mizivé.
* V jazyce bez hodnoty null by to byla fajn věc, v Javě mám ve výsledku proměnnou, která kromě Optional.of(value) může obsahovat nejen Optional.empty(), ale také null. (Ve Scale je to ještě o kousek dál: Some(value), None, null a navíc Some(null).) V tomto směru je podpora přímo v jazyce elegantnější, nenabízí žádné podivné hodnoty, které nechceme.Tím nepopírám výhody implementace fíčur jako knihovny (ostatně Scala je na tomto principu postavená), čistě jen vyzdvihuju nevhodně zvolený příklad.
-
Filip JirsákStříbrný podporovatel
Šlo jen o porovnání toho, že je nějaká vlastnost implementována jako běžná třída, nebo že je implementována jako speciální operátory. Ostatně Kotlin má úplně stejný problém, pokud se v Kotlinovém kódu bude používat spousta Java knihoven, ze kterých Kotlin nebude schopen zjistit nullabilitu, bude jeho null safety také neúspěšné. Dichotomie mezi null a Optional.empty() je daná prostě tím, že Optional bylo zavedeno dodatečně.
Zkuste si to představit tak, že byste vytvářel nový jazyk, a rozhodoval se, zda null safety implementujete jako třídu Optional nebo jako „operátor“ otazník. -
Jsou pěkné argumenty pro Optional, ve Scale to ostatně celkem dobře funguje (dokud se nedotknu Javové knihovny s null), protože se tam null prakticky nepoužívá. Scala se z Javových API snaží napřímo používat co možná nejméně, spíše přes nějaký wrapper. Ve výsledku máme i celkem dobrou iluzi, že null neexistuje, a Option může dobře fungovat… Je to ale zásluha celého ekosystému, ne jen návrhu samotného typu v Javě.
V konzervativnější Javě s dekádami dědictví to ale s přechodem na Optional tak dobré už není. Máme – i v JRE – spoustu tříd, které prostě používají null, a nelze to jen tak změnit kvůli zpětné kompatibilitě.
U Kotlinu můžeme mít horší nebo lepší podporu v závislosti na tom, jestli jsou parametry a návratové hodnoty označeny anotacemi jako @Nullable a @NonNull (či podobnými). I bez těchto anotací by IMHO mělo jít využít některé výhody nových operátorů (např. Elvis operator), jen prostě kompilátor nebude tak přesně varovat. Navíc ten kód lze průběžně o anotace obohacovat, aniž bych rozbíjel kompatibilitu. To se o Optional říct nedá.
> Zkuste si to představit tak, že byste vytvářel nový jazyk, a rozhodoval se, zda null safety implementujete jako třídu Optional nebo jako „operátor“ otazník.
To bych asi rozhodl podle cílů, jaké by ten jazyk měl. Více se mi líbí Optional, ale pokud bych měl dobře zapadnout do existujícího ekosystému (což tvůrci Kotlinu AFAIR psali jako jeden z cílů), asi by se to nějak promítlo i do jazyka. Možná bych vymyslel nějaké lepší řešení, ale těžko by se to obešlo bez nějaké speciální vlastnosti jazyka.
-
Filip JirsákStříbrný podporovatel
To bych asi rozhodl podle cílů, jaké by ten jazyk měl. Více se mi líbí Optional, ale pokud bych měl dobře zapadnout do existujícího ekosystému (což tvůrci Kotlinu AFAIR psali jako jeden z cílů), asi by se to nějak promítlo i do jazyka. Možná bych vymyslel nějaké lepší řešení, ale těžko by se to obešlo bez nějaké speciální vlastnosti jazyka.
A to je právě to, co se mi na Kotlinu nelíbí. Řeší aktuální problém, tak přidají novou konstrukci do jazyka. Jenže za dvacet let tady ten problém už dávno nebude, ale konstrukce v jazyku zůstane pořád. V Javě do stejné kategorie patří primitivní typy, ale nic moc dalšího mne nenapadá. A i ty mají nakonec aspoň tu výhodu, že jsou not-null. -
gcx11 (neregistrovaný)
Upravený příklad z dokumentace by vypadal takto (nepovedlo se mi přijít na to, jak tu nějak rozumně zprovoznit formátování):
import kotlin.properties.Delegates
class User(name: String){
var name: String by Delegates.observable(name) {
prop, old, new ->
println("$old -> $new")
}
}
fun main(args: Array<String>) {
val user = User("initial value")
user.name = "first"
user.name = "second"
}Zaprvé, celý syntax je
val/var <property name>: <Type> by <expression>, nikde u toho není nastavování default value, protože někdo může chtít inicializovat delegated property přes její konstruktor (viz výše) anebo přes setter (na to jde použít init block). Nehledě na to, že delegated properties můžou být read-only, takže tam by ani inicializace přes setter nedávala smysl.> když porovnám null safety, Kotlin si vystačí s jedním až dvěma znaky, Java má
Optional<>. JenžeOptional<>mohl do Javy zavést kdokoli, stačilo napsat normální knihovnu (a různé knihovny podobnou funkcionalitu měly). Když se v budoucnosti ukáže, že by se to dalo řešit lépe, vymyslí někdo třeba inverzní tříduMandatory<>, a na syntaxi Javy se nemusí měnit nic. Kotlinu budou shánět další symbol – a hlavně takovou novinku mohou zavést jenom autoři Kotlinu, nikdo jiný.V Javě pak díky zpětné kompabilitě zůstane null,
Optional<>aMandatory<>. S tím se bude určitě dobře pracovat. Navíc v Kotlinu se mohou použít takové věci jako autocasting nebo safe calls, toho žádná knihovna v Javě docílit nemůže, nemluvě o runtime overheadu proOptional<>. -
Filip JirsákStříbrný podporovatel
Upravený příklad z dokumentace by vypadal takto
Jenže v tomhle příkladu právě delegát není definován v konstruktoru. Ta celá syntaxe s klíčovým slovembypři deklaraci property v konstruktoru nejde použít, takže jsou v jazyce dvě velmi podobné konstrukce – deklarace property v těle třídy a deklarace v konstruktoru. Ve spoustě případů je dokonce syntaxe stejná.V Javě pak díky zpětné kompabilitě zůstane null, Optional<> a Mandatory<>. S tím se bude určitě dobře pracovat.
Už jsem vysvětloval, že to porovnáváte nesouvisející věci. Popisujete zpětnou kompatibilitu a porovnáváte jí s novým jazykem. Já jsem ale psal o rozdílu implementace ve standardní knihovně vs. nová konstrukce v jazyce.safe calls, toho žádná knihovna v Javě docílit nemůže
Ve skutečnosti safe calls sOptional<>můžete použít a je to implementováno pouze ve standardní knihovně, není potřeba žádná magie kompilátoru.nemluvě o runtime overheadu pro Optional<>
To je pouze otázka implementace – když je to součástí standardní knihovny, nic nebrání kompilátoru nebo JVM dělat nad tou třídou nějakou „magii“. Třebajava.lang.Stringse „z venku“ také tváří jako úplně normální třída, ale kompilátor s ní občas zachází speciálním způsobem. -
Filip JirsákStříbrný podporovatel
Kotlin uz na Androidu oficiálně nahradil Javu. Už je to snad někdy od března.
Nenahradil, pouze se vedle Javy stal oficiálně druhým podporovaným jazykem. -
Petr Neni (neregistrovaný)
Asi vsichni tady vime, ze kdyby jsi psal GC ty, tak ho napises nejlepsi hned v prvni verzi a dal nepujde vubec optimalizovat bez ohledu na novy HW, SW atd. Soudruzi co pisou GC v jave nejsou tak uzasni a nemaji tolik vizionaru jako jsi ty, ktery umi predpovedet budoucnost optimalizaci ze sve ranni stolice. Treba by te zamestnali...
-
Jirka (neregistrovaný)
To je proto, že garbage collection je těžký úkol. Přesněji řečeno udělat garbage collector, který funguje vždy, rychle a účinně (ve smyslu toho, že hodně čistí paměť) je obecně nemožné, je to algoritmicky neřešitelný úkol. Proto GC používají různé chytristiky a heuristiky a ty je možné vylepšovat v podstatě donekonečna. Takže GC budou pořád lepší a lepší, ale nikdy nebudou "dokonalé" nebo "hotové". Kdyby GC byl jednoduchý problém, byl by už dávno vyřešený a nebylo by se o čem bavit.
-
uranix (neregistrovaný)
Jestli by nebylo lepší nepoužívat GC vůbec, jako to mají už vyřešené v jazyce Rust.
https://doc.rust-lang.org/book/2018-edition/ch04-01-what-is-ownership.html -
Jakub Valenta (neregistrovaný)
Se stack alokací popsanou v článku si většina programů nevystačí. A pokud nalistuješ v té knize o pár kapitol dál, tak zjistíš, že Rust používá pro sdílené vlastnictví smart pointery (což je automatická správa paměti). Navíc na rozdíl od javovského GC, přestanou smart pointery fungovat pokud vytvoříš cyklus a je na zodpovědnosti programátora, aby se to nestalo. Takže i autoři jazyků jako C++ nebo Rust si uvědomují, že manuální správa paměti je těžký úkol, který ve větším systému nikdo nezvládne dokonale a snaží se jim to ulehčovat i za cenu paměťových a výpočetních nároků (počítadlo referencí - alokace, dekrementace, inkrementace).
Pracuju jako C++ programátor pár let a nepracoval jsem s týmem, který by preferoval manuální správu paměti před smart pointery. Naopak obyčejné pointery jsou věc, na kterou se hned reaguje v code review a musíš si obhájit, proč použít zrovna je. Vsadím se, že doporučení pro rust budou podobná.
-
lopata (neregistrovaný)
Rust nerozlišuje mezi stack a heap alokací, v obou případech platí stejná pravidla pro vlastnictví objektu. Automatická správa paměti je v Rustu jak pro normální reference, tak pro smart pointery. Zjednodušeně řečeno vždy platí, že objekt může mít jen jednoho vlastníka pro zápis, nebo nekonečně mnoho vlastníků pro čtení.
Smart pointery v Rustu mají nějaké featury navíc oproti normálním referencím, nicméně je to něco za něco. Např. RefCell<T> řeší vlastnictví objektu až v runtime, takže to nejde kontrolovat při překladu. Pokud napíšeš v Rustu program, který porušuje pravidla vlastnictví, tak s referencemi případně s Box<T> se to vůbec nepřeloží. S RefCell<T> se to přeloží, ale spadne to až v runtime ve chvíli, kdy použiješ RefCell<T> špatně a pravidla vlastnictví porušíš.
-
judovana (neregistrovaný)
sak mame Epsilon ne - http://openjdk.java.net/jeps/318 :)
-
Tom (neregistrovaný)
ano, to byl plně stačilo ... https://googleprojectzero.blogspot.com/2018/09/a-cache-invalidation-bug-in-linux.html
-
creezo (neregistrovaný)
Nemyslím, že je java zrovna nenažraná co se týká JVM. Celkově jsou tady hlavní problémy dva. Prvním je neznalost programátorů, kteří často neví, jak se JVM chová k jejich datům v paměti, jak alokuje a uvolňuje prostředky. Neumí správně optimalizovat kód aby nevytvářel zbytečně nové "short lived" instance objektů, tedy nerecykluje. Využití profileru je bohužel u takových jedinců velkou neznámou. Druhým problémem pak je uživatel co aplikaci spouští s "default" nastavením JVM. Když mu dám 1 GB paměti, tak si to JVM prostě vezme, pak tu jsou ty neopodstatněné stížnosti na nenažrané aplikace, bohužel je to jen neznalost.
Když jsem psal aplikaci (computer vision a machine learning), tak mi úplně stačilo 64 MB aby to celé nespadlo na nedostatek paměti, ale čas procesoru strávený v GC byl už nad 10 %. Naopak, když jsem aplikaci dal 2 GB, tak se GC nespustil téměř nikdy, ale už je to celkem pořádný kousek paměti oproti minimu. Tím chci říct, že vždy jde o nalezení kompromisu mezi spotřebou RAM, CPU a programátorskou leností.
-
kimec (neregistrovaný)
ZGC a Shenandoah GC tento koncept kompletne rusia. Oba pouzivaju particie. Shenandoah fixne, ZGC variabilne velke. Oba sa uz nespoliehaju na generational hypothesis ale razia cestu kooperativnej concurrent kompakcie. Shenandoah myslim aplikuje aj back pressure na rogue thready, ktore vela alokuju.
-
ja. (neregistrovaný)
Nesetrna praca s pamatou aj vyplyva z principu, ktory JVM presadzuje: ked je kazdy objekt alokovany na heape a vsetko je by reference, tak holt musi pocitat s tym, ze bude vela kratko zijucich objektov. Keby bolo mozne alokovat na stacku, a bolo by mozne pouzivat by value, tak to by uvolnilo tlak na pamat.
Rovnako profiler: ked ma programator aplikaciu, kde mu bezi cely jboss, spring, hibernate plus nejake dalsie velke frameworky, tak sa necudujem, ze sa na neho vykasle. Vtedy je docela rad, ze to vobec funguje v ramci terminov, v ktorych sa moze pohybovat.
-
JJ (neregistrovaný)
Není jedním z hlavních „selling points“ Javy to, že se člověk nemusí starat o nízkoúrovňové věci jako je to, jak se JVM chová k datům, jak jsou tato data representována v paměti apod.? Pro většinu aplikací je dnes výkonu a paměti dost, takže není divu, že většina vývojářů tyhle nízkoúrovňové záležitosti neřeší. Další generace už to třeba ani nebude umět.
Další problém je to, že normální vývojář zákaznické aplikace pracuje s řadou různých knihoven a nemá čas na to, aby je všechny detailně zkoumal, nebo si psal vlastní. Takže i když budu optimalisovat co to jde a psát perfektní kód, stačí jedna problematická knihovna a chování celé aplikace jde do háje.
Ad garbage collector: mně více vyhovovalo ARC v ObjC, ale i s GC se žít dá. Velké problémy mi způsobil jen jednou (import a zpracování velkého množství nevhodně strukturovaných dat na hodně slabém hardware).
-
Filip JirsákStříbrný podporovatel
Není jedním z hlavních „selling points“ Javy to, že se člověk nemusí starat o nízkoúrovňové věci jako je to, jak se JVM chová k datům, jak jsou tato data representována v paměti apod.?
Ne. -
JJ (neregistrovaný)
Při přebírání zákazníkem to většinou nějak přijatelně funguje a dál holt spousta lidí nedohlédne, nebo to neřeší, protože jim většinou nikdo nezaplatí za to, aby nějaká funkce/aplikace byla napsána čistěji a běžela o 5 % rychleji nebo potřebovala o 2 MB méně paměti. No a když podobně postupují autoři knihoven a operačních systémů, tak se těch 5 % postupně nastřádá a je veselo.
IMHO jsou tyhle problémy odvrácenou stranou toho, že programování je čím dál tím více odděleno od železa a operačních systémů různými abstrahujícími vrstvami. Což má samozřejmě i spoustu výhod a je to svým způsobem nezbytné, protože v assembleru dnešních CPU se uživatelské aplikace reálně moc psát nedají.
-
j (neregistrovaný)
Ehm ... ne, nefunguje to ani pri predani. Opakovane a cim dal castejs se setkavam s tim, ze patlal prinese svuj vytvor, predvede ho na svych 10 zaznamech a ja mu to cely zbouram tim, ze mu tam tech zaznamu pustim 10 ... Mega.
A pak se dejou veci ... protoze ten idiot se trebas tech 10mega zaznamu snazi nacist do ramky ... nebo (protoze to je uber dizajn kodu) tam ma nejakou rekurzi, takze s kazdym dalsim zaznamem se zdvojnasobi cas pro ziskani vysledku .... atd atd.
A to vsechno proto, ze ten patlal nema ani paru o tom, jak ten HW(a vlastne i SW) pod tim vlastne funguje a co umi a co ne.
-
JJ (neregistrovaný)
Já jsem taky rozkopal spoustu báboviček různým bastlířům (a ano, ty konkrétní záležitosti, které uvádíte, jsem také zažil). Jenže ne vždy software přebírá někdo, kdo tomu rozumí tolik, jako Vy nebo já... A i pokud tam někdo takový sedí, ne vždy má právo veta resp. dost pevnou posici na to, aby odolal nátlaku managementu, který si to potřebuje odškrtnout jako „vyřešené“ s tím, že „drobné nedostatky“ se nějak doladí později.
-
Pro většinu aplikací je dnes výkonu a paměti dost? Jo? Tak si těch aplikací, pro které je dnes výkonu a paměti dost zkuste spusit deset vedle sebe. Ano, někde na serveru v jednom kontejneru, kde z principu nic jiného než váš javový backend neběží je to v pohodě. Jenže už když začnete něco stavětjako microservices, začnou tak nějak docela problémy. O desktopových aplikacích ani nemluvě.
-
O (neregistrovaný)
Tohle "začnete něco stavět jako microservices" zrovna zní jako typický případ, kdy se nevyplatí investovat čas a prachy do nějaké přehnané optimalizace. Jo, můžeš si to napsat celé v C nebo assembleru a uplatnit v tom všechny Berkeley/MIT/Matfyz triky, co znáš, ale pokud to není vyloženě trivialita, bude ti to nejspíš trvat násobně déle než v Javě. A celou tu dobu, co tím strávíš navíc, bys mohl dělat něco jiného. Mnohé firmy si už dávno spočítaly, že čas vývojářů je příliš cenný prostředek, než aby si mohly dovolit jím plýtvat na něco, co se dá jednoduše vykompenzovat navýšením výpočetního výkonu. Což samozřejmě neznamená, že bychom se měli na optimalizaci vykašlat úplně, spíš myslet na to, že technicky dokonalé řešení je v praxi mnohdy zbytečný overkill.
-
No jasně, nikdo (příčetný) je nebude psát v C nebo assembleru, ale Java (resp. JVM) je také docela nevhodné právě kvůli době startu a paměťovým nárokům. Paradoxně mnohé z těch alternativ mají naopak ještě horší než Java/JVM (node, cpython), ale to se 90% ani nedá poznat, protože to stejně celé 99% času čeká na I/O nebo dokonce na uživatele.
-
O (neregistrovaný)
Jasně, C a assembler jsou nadsázka, jen zkrátka poukazuji na to, že je v mnoha případech kontraproduktivní snažit se o maximální technickou efektivitu za každou cenu, protože technická efektivita nejde vždy ruku v ruce s produktovou nebo ekonomickou efektivitou. Java se pochopitelně nehodí na všechno, to se dá ovšem říct o každé technologii. Pokud ji použiju na aplikaci typu Hello World, která se spustí, vykoná pár triviálních kroků a skončí, tak ta efektivita samozřejmě bude beznadějná a bude to použitelné leda na věci, které se spouštějí jednou za čas (a i tak to bude prasárna, pokud lze to samé provést třeba jednoduchým shell scriptem). Pokud ji použiju na serveru v aplikaci, kde režie JVM tvoří zlomek celkového využití prostředků, tak získám robustní řešení bez velkých provozních nákladů navíc (a ty se mi snadno vykompenzují právě tou robustností, rychlejší implementací, snazší údržbou, nároky na schopnosti vývojářů atd.). A mezi těmihle póly je celá škála případů, kdy je třeba se rozhodnout, zda je Java ještě vhodná či použitelná, nebo už nikoli.
-
Filip JirsákStříbrný podporovatel
Java (resp. JVM) je také docela nevhodné právě kvůli době startu a paměťovým nárokům.
A pak vznikla GraalVM, která umožňuje vytvořit i binární obraz aplikace, a všechny tyhle argumenty o pomalém startu vzaly za své. -
SubstrateVM (nativní image u GraalVM) je sice pěkná věc, ale není to univerzální řešení. Musíte přijmout nějaká omezení, která musí splnit nejen váš kód (to je většinou celkem řešitelné), ale taky kód všech použitých knihoven – a to je někdy problém i se standardní knihovnou z JRE.
V praxi to vypadá asi takto: Větší aplikace jsou se SubstrateVM prakticky bez šance. Menší věci – pokud překousnete několikamegovou binárku (dnes snad není problém) – s trochou štěstí půjdou zkompilovat a bez problémů pojedou. Ale ne vždy, třeba u JDBC jsem si vylámal zuby.
A má to nějaké bugy (typicky se naštěstí projeví hned při kompilaci), na které není tak těžké narazit. A občas se mi stalo, že nějaký platform-specific code to považovalo za reachable a při kompilaci pro Linux jsem tomu musel na classpath dodat i třeba JNA pro Windows.
Zatím taky je omezený seznam platforem, kde to jede. Windows není zatím podporovaný, macOS nevím, z instrukčních sad jen x64. Což je vzhledem k potenciálu pro embedded škoda.
Stručně, je to užitečná věc, ale má celkem omezené možnosti. Do budoucna to může být i o poznání užitečnější, ale patrně nikdy nepůjde o obecnou náhradu za univerzální JVM.
-
Filip JirsákStříbrný podporovatel
Že to nefunguje pro větší aplikace nevadí, protože u nich je vám jedno, že startují déle. Aby to byla univerzální náhrada za JVM není potřeba, protože ta AoT kompilace je součástí GraalVM, takže její výhody můžete využít i tam. To vytváření nativního obrazu míří především na microservices spouštěné v cloudu, kdy obsloužení jednoho HTTP požadavku znamená spuštění a ukončení procesu. Půjde to použít i na nějaké utility, ale myslím že není ambice spouštět tím jakýkoli kód, není to potřeba.
Jinak GraalVM je teď ve verzi 1.0-rc6, takže je úplně na začátku. -
Filip JirsákStříbrný podporovatel
Asi jste špatně četl, je to prakticky použitelné. Teď to začal podporovat Micronaout Framework, aplikace nastartuje za 20 ms a potřebuje 20 MB RAM. To vám připadá jako dlouhá doba startu a velké paměťové nároky?
-
Filip JirsákStříbrný podporovatel
Pod Macem to funguje, pod Windows zatím ne, protože po tom není poptávka. Pod Windows dříve nefungoval ani Apache HTTP Server, PostgreSQL, vim – samé nepoužitelné programy. Které všechny platformy podle vás musí nějaká funkce podporovat, aby byla použitelná? Stejně tak je to použitelné i na větší aplikace – nezáleží totiž na velikosti aplikace, ale na tom, jaké používá funkce. GraalVM je zaměřený na budoucnost, ne na minulost. Takže momentálně nepodporuje třeba funkce, které mají modernější (rychlejší, bezpečnější) alternativy, a jejichž implementace by byla náročná. Důležité je, aby byla nová VM venku a mohla se používat alespoň pro něco, moderní aplikace z ní mohou těžit už teď. Staré neefektivní aplikace nejsou prioritou, když byly použitelné do teď s tradiční JVM, mohou tak fungovat i nadále.
Jak už jsem psal, Oracle tím s Javou míří do světa microservices a serverless architektury, kde teď Java nemohla moc obstát. Micronaut + GraalVM teď bude moci v této oblasti konkurovat NodeJS nebo Pythonu, přitom má za zády pořád celý obrovský ekosystém Javy. Monolitické Springovské aplikace bude možné postupně rozdělit na microservices, takže bude možné využít všech výhod cloudu nejen pro aplikace pro jednotlivce (jako dosud), ale i pro enterprise systémy (bankovní aplikace, telco, státní sektor). Vy si klidně dál spouštějte Springovský monolit pod Windows, ale smiřte se s tím, že ta vaše aplikace není celý svět.
-
Problém je, že to, co jste popsal není ve většině ostatních běžně používaných platforem víceméně vůbec třeba řešit. Takže nepište, že není. Je a dokázal jste to právě tím, co jste napsal. Bohužel je. Sice javu nepovažuji za něco extra překrásného -- na můj vkus je trochu robustní na cokoliv, co není vyloženě komplexní projekt -- ale kdyby se co se týká správy prostředků chovala více jako standardní binární aplikace nebo skriptovací engine, byla by rozhodně o dost použitelnější.
-
. (neregistrovaný)
Tak zdejší "mistři" samozřejmě nejlépe ví, že Java je lékem na vše. A nějak nedokážou pochopit, že je vždy něco za něco. Pokud předávám vše jako referenci, ušetřím za kopírování, ale pak zas musím uvolňovat. A z toho pak plynou stop-the-world pauzy, které třeba jiné jazyky s GC neznají.
A pohádky o možnosti náhrady GC si nechte na večer. Možnost není realita (viz vaše stížnost na nepoužívání profileru). -
null null (neregistrovaný)
@.
Varovat ... radši se vyvaruj plácání povýšených hloupých klišé.
Začni tím že nebudeš obviňovat školu kde někdo studoval. To jak je to hloupý přístup může ukázat třeba to, že i kdych ti teď nějakou nalhal, tak ji klidně popliveš. Pokud si na sebe tak hrdý, můžeš napsat tu svou a odměnit se bonbónkem.
-
j (neregistrovaný)
Sak to mas jedno, stejne na to potrebujes "starej a neaktualizovanej" browser, protoze v tom "novy a bezpecnym" to prece "ve tvym zajmu" nefunguje. A sjtene tak na to potrebujes mit nainstalovany vsechny verze (neaktualizovany) javy, ... protoze je to prece kompatabilni.
Pak si prijdes jak u blbejch na dvorecku, kdyz kvuli tomu, aby ses pripojila na 10 krabek potrebujes 10 ruznejch browseru a 10 ruznych verzi javy.
-
Filip JirsákStříbrný podporovatel
Na straně prohlížeče to fungovalo, na straně Javy s tím vždy byly problémy. On se totiž Web Start pokoušel řešit spoustu věcí navíc – cache JARek, aktualizace, verze JRE, instalace aplikace do systému pro off-line použití atd. Navíc to používalo stejný sandbox, jako Java applety, takže aplikace si teoreticky mohla říct jen o některá oprávnění. Jenže v tom sandboxu zase byla spousta děr (většina bezpečnostních děr v Javě se týkala právě toho sandboxu). Takže na jednu stranu chápu, že to Oracle zařízl, problémů s tím byla spousta. Ale že to nenahradili nějakou jednoduchou variantou „stáhni tyhle jarka a spusť java -jar hlavní.jar“, to je hloupé. Bohužel Oracle na Javu na desktopu zjevně kašle, akorát si nejsem jistý, jestli si uvědomují, kde běží ty aplikace, které konzumují služby běžící na těch jejich WebLogicech a ukládající data do Oracle SQL, a kde se ty aplikace programují…
-
Krysa11 (neregistrovaný)
Já jsem se s tímto naposled setkal u dellu, myslim, ze se to jmenovalo "drac" KVM. Pro neznale je to vzdaleny pristup k serveru, ve kterem se da vlezt i do biosu. nakonec jsem si na to musel udelat vlastni javaws xml generator, protoze v tom xml, co mi to davalo bylo potreba prepsat nativni knihovny, ktere si to stahovalo (nejspis na vykreslovani, co ja vim) z *.dll na *-native-i386.so, nebo tak nejak. Jako stalo me to chvilku trapeni a toho, ze se mi ostatni admini (co meli windows) posmivali, jak na tom linuxu nic nefunfuje, ale pak jsem diky tomu prisel, na to, ze se da v javaws prepsat i ip adresa ke ktere se ma ta konzola pripojit a pokud si tam predtim curlem vezmu session, tak vlastne nemusim ani spoustet prohlizec a nekam se logovat. Podle evidence verejna ip server -> ip kvm konsole potom vyhledat spravne ip a druhej den rano uz jsem to mastil pres konzoli "kvm-jws 280.155.103.25" a koukali na me jako na boha, protoze odpadlo hledani ip pro pripojeni, logovani do webu, stahovani javaws apod (coz s 280ms pingem nekde v kuola-lumpuru neni zadnej med).
-
Johanka (neregistrovaný)
JWS používá i třeba iLO od HP (minimálně ještě ve verzi 4, poslední pětku nikde nemám) nebo SuperMicro. No a samozřejmě vzdálené KVM v datacentrech. V jednom zahraničním pro jistotu ještě musím v Javě povolovat RC4 a MD5, protože jsou už v defaultu zakázané a ten letitej bazmek nic jiného neumí. Alespoň že to mají schované za VPN, byť PPTP taky není žádná výhra... :-/
Já naštěstí většinou používám SSH a přístup na virtuální sériový port, ale sem tam, tak jednou za rok, je potřeba i grafický terminál...
-
BobTheBuilderStříbrný podporovatelOno se to pomalu mění, SuperMicro (novější) už mají na IPMI konzolu v HTML5. Jenže než odejdou do šrotu ty starší, kde už firmware nepředělají, to bude ještě trvat dost dlouho.
-
Filip JirsákStříbrný podporovatel
Ono se to pomalu mění, SuperMicro (novější) už mají na IPMI konzolu v HTML5.
To je hezké, že se pomocí HTML5 nahrazují aplikace, které pomocí HTML5 jde napsat. Bohužel stále zůstávají aplikace, které pomocí HTML5 napsat nejdou, typicky přístup k hardwaru nebo ke službám systému. -
Krysa11 (neregistrovaný)
Jo, supermicro jsme měli taky, už je to řada let, nevzpoměl jsem si na nazev značky, jen jsem věděl, že je to byl, tehdy považovaný, levnější šunt a přecházelo se na "profesionální" dell, kde bylo kupodivu, alespoň z mojí pozice dvakrát víc problémů. IPMI jsem taky někde zažil, ale už si nevzpomenu kde.
Ostatně nechat si na disku starší javu kvůli javaws je ne-problém.
-
unicode (neregistrovaný)
Nadpis "experimentálne garbage collectory" bych četl tak, že se tomu ten článek bude alespoň trochu věnovat a ne jen to jen zmíní v "ostatních". Místo toho tu máme naservírované nové funkce pro práci s řetězci, ale už nevím, jestli jsou "nejrychlejší na světě" (kdo to tu sleduje ví na co narážím) :)
-
Krysa11 (neregistrovaný)
Vetšina nových věcí, které jsou uváděny za účelem jednoduché manipulace v triviálních případech nejsou nejryhclejší na světě asi už minimálně někdy od té doby, co jsem dostal commodore 128 ze západního německa na kterém byl kromě bytecode i BASIC interpretter na kterém jsem někdy v 3. třídě základní školy páchal první akční střílení čtverců čárami v rozlišení 320x240 v 16 předdefinovaných barvách.
To, že zmíněné vylepšení může vést ke geniálním úkonům jako načti 30MB xml, změn jednu hodnotu z true na false a ulož 30MB xml je pravda a taky to určitě povede, ale v tom základu načti/zapiš řetězec to podle mě bude výkonostně ok. Nadruhou stranu to jde naproti trendu, kde si každý ňouma stěžuje, že java ma moc steep-learning-curve a ukecaná. Tak to si potom vyber. Když na načítání stringu potřebujeě inicializovat InputFileReader, InputStringReader a BufferedReader kvuli UTF apod. Pak ti přijde kašpárek a řekne, že v javascriptu si uděláš http.server async a máš server, tak co řešit, když ten tomcat je takovej nějakej složitej. Jde lamám naproti. Já to nepotřebuju, ty to asi taky nepotřebuješ, potřebuje to lama? potřebuje to java? osobně je mi to jedno.
ČLÁNKY DO MAILU