Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Filip Jirsák

Stran: 1 ... 188 189 [190] 191 192 ... 375
2836
Vývoj / Re:Java 11 JRE se nedá stáhnout
« kdy: 20. 11. 2018, 11:53:02 »
Tak samozřejmě stále existují systémy a programy které po uživateli chtějí běhové prostředí Javy. Instalovat celé JDK mi přijde jako kanón na vrabce.
Na desktopu nemá smysl velikost JRE a JDK porovnávat, obojí je v porovnání se spoustou dnešních programů vlastně malé. Jinak v tom JDK je jenom pár nástrojů, které určitě nebudete pro běh Javovských aplikací potřebovat – kompilátor, disassembler, generátor hlaviček pro C a pack200. Tím to asi končí, protože různé ladicí nebo profilovací nástroje se mohou hodit i pro běh aplikací. Takže byste ušetřil nanejvýš pár mega. Mimochodem, JRE bylo součástí JDK a ty soubory tam byly zkopírované (alespoň na Windows), takže zrušením JRE se velikost JDK zmenšila.

2837
Vývoj / Re:Java 11 JRE se nedá stáhnout
« kdy: 20. 11. 2018, 10:52:04 »
Pokud to má pro osobní použití, tak OracleJDK. Pokud pro firemní a nechce platit podporu, pak Oracle OpenJDK.

V případě té banky by to měla banka popsat v dokumentaci – navíc od Javy 11 není podporován Java Web Start, a Java Applety už nejsou většinou prohlížečů podporované několik let, takže pokud potřebuje Javu v kombinaci s prohlížečem (např. pro elektronický podpis), bude nejspíš potřebovat starší verzi Javy a buď starší verzi prohlížeče, nebo Internet Explorer. Ale zase jinak se rozumně elektronický podpis v prohlížeči udělat nedá (tohle se tvůrcům prohlížečů a potažmo Oraclu opravdu moc nepovedlo), takže s těmi staršími verzemi Javy budeme muset ještě nějakou dobu vydržet. Nejlepší je, pokud je to Java SE 8 – tu bude Oracle i pro osobní použití vydávat nejméně do konce roku 2020.

2838
Vývoj / Re:Java 11 změna licence
« kdy: 20. 11. 2018, 10:23:25 »
Ano, vyloženě kvůli tobě jsem jej vyrobil. (myšleno ironicky) Ty jsi fakt "mudla".  Ten obrázek jsem si na jaře sosnul, z nějakého blogu vývojáře z Oracle. Možná jsem si někde uložil url, ale fakt mě to za to nestojí hledat. Po novém roce uvidíš jestli to sedí nebo ten obrázek je blábol.
To, že reagujete na něco jiného, než jsem napsal, je váš problém. Já jsem nikde nepsal, že takhle releasy Oracle OpenJDK vycházet nebudou. Naopak jsem napsal, že na základě různých neoficiálních vyjádření jsem přesvědčený, že to tak bude. Psal jsem, že to ale Oracle nikde oficiálně neuvádí. „Nějaký blog vývojáře“ není oficiální informace Oracle. Za oficiální považuju například to, co je odkazované přímo ze stránky Oraclu o změnách v podpoře Javy: Oracle Java SE Support Roadmap.

2839
Vývoj / Re:Java 11 JRE
« kdy: 20. 11. 2018, 09:50:00 »
Trochu se mění licenční model Oraclu. Oracle už bude poskytovat jen JDK, a od ledna 2019 bude zdarma jen pro osobní použití, pro vývoj a testování. Na produkci bude potřeba placená verze se supportem. Vedle toho bude existovat Oracle OpenJDK pod GPL licencí, ta je také jen ve variantě JDK. Univerzální JRE už se nedělá, protože Java byla rozdělená na moduly a očekává se, že pokud někdo chce malé JRE, poskládá si JRE přímo na míru jen s potřebnými moduly pomocí nástroje jlink, který je součástí JDK.

2840
Hardware / Re:UPS pre domáce použitie / router
« kdy: 20. 11. 2018, 08:47:08 »
Tu UPS nejde nakonfigurovat, aby po obnovení napájení a nabití na nějaké minimum na chvíli odpojila výstup, čímž z pohledu připojeného zařízení dojde ke ztrátě a obnově napájení a zapne se?

2841
Vývoj / Re:Java 11 změna licence
« kdy: 20. 11. 2018, 08:17:37 »
Ha, este pred par rokmi vsade, kde sa porovnavalo C# a Java, javisti tvrdili, ze toto sa jave stat nemoze, lebo je open a komunita a ved to poznate...
Co „toto“ se stalo? Že si můžete vybrat mezi několika dodavateli komerční podpory a nebo můžete používat OSS variantu bez komerční podpory? Nevím, proč by někdo tvrdil, že se to nemůže stát, když to tak bylo vždycky – a navíc je to pozitivní. Nebo vy v možnosti výběru vidíte nějaký problém?

2842
Vývoj / Re:Java 11 změna licence
« kdy: 19. 11. 2018, 21:28:47 »
Nový licenční model bude fungovat až od ledna 2019, takže to, jak to funguje teď, není směrodatné. Ten váš odkaz nevypadá, že by vedl na oficiální dokument Oracle. Já si myslím, že Oracle OpenJDK bude vycházet stejně, jako OracleJDK (maximálně s nějakým drobným zpožděním), ale oficiální prohlášení Oraclu jsem k tomu nikde nenašel.

2843
Vývoj / Re:Java 11 změna licence
« kdy: 19. 11. 2018, 17:28:48 »
Mas zdroj? Myslel sem, ze to je ten hlavni duvod proc to delaji...
Mluvil jsem se o tom s IT architektem z českého Oraclu, který řeší právě Javu a související technologie (WebLogic apod.). Takže žádný odkaz nemám. Ale všimněte si, že o frekvenci vydávání patchů Oracle OpenJDK není v oficiálních materiálech ani slovo – pokud by nechtěli žádné patche vydávat a chtěli takhle tlačit na nákup podpory, bylo by to podle mne všude napsané. „Žádné patche nebudou vydávány, takže jakmile se objeví jakákoli bezpečnostní chyba, budete mít nezáplatovanou verzi až do příští major verze – to nemůžete dopustit, kupte si podporu.“ Nic takového nikde není.

Cim kostnatejsi korporace, tim pomalejsi upgrady a tim vic penez za podporu a non-public security patche...
Prislo mi to jako pekny zpusob jak vytriskat prachy z korporatu, ale mensi rybky nechat dychat...
K tomu ale právě stačí podporovat Orace OpenJDK jenom půl rok, a po půl roce přejít na vyšší major verzi. Korporátem za půl roku teprve probublá, že nějaká nová verze vůbec existuje, takže ten bude potřebovat tu podporu. Navíc ten support často potřebuje nakupovat jenom proto, že prostě musí být na všechno a nemůžete mít něco jen tak zdarma. A ostatní budou používat záplatovanou Oracle OpenJDK a Java tak nedostane nálepku nebezpečné aplikace, kterou nikdo rozumný nemá nainstalovanou. Oracle asi nebude chtít Javu dostat do pozice, v jaké je dnes třeba Flash (Sun už tímhle směrem s Javou mířil).

2844
Vývoj / Re:Java 11 změna licence
« kdy: 19. 11. 2018, 16:14:40 »
A má tohle java web start? Zulu I adopt ho nemají.
Java Web Start nebude mít nikdo, protože ta technologie s Javou 11 skončila. Jediná možnost je, že by někdo implementoval něco podobného (a třeba jednoduššího a funkčního). Navíc ta technologie je založená na tom, že to skoro všichni mají „automaticky“ v prohlížeči – to se jen tak někomu novému nepovede.

2845
Vývoj / Re:Java 11 změna licence
« kdy: 19. 11. 2018, 15:37:48 »
Pro vývoj můžete dál používat OracleJDK. Pro produkční nasazení si můžete zaplatit podporu Javy od Oracle, od někoho jiného, nebo můžete používat nepodporovanou (ve smyslu „bez podpory“) Oracle OpenJDK – s tím, že pak musíte přecházet každý půl roku na novou major verzi (starší nebudou v Oracle OpenJDK podporované).

Ještě není jisté, jak často budou vycházet patche pro Oracle OpenJDK, poslední neoficiální zprávy z Oraclu jsou takové, že si nemohou dovolit nechávat Oracle OpenJDK bez bezpečnostních patchů. Podle mého názoru by tedy alespoň bezpečnostní patche měly vycházet průběžně, tedy asi s stejnou frekvencí, jako ty pro OracleJDK. Prý o tom rozhoduje engineering a ne obchod, takže snad nebude snaha zdržováním bezpečnostních patchů pro Oracle OpenJDK tlačit k přechodu na OracleJDK.

2846
Cookies s bezpečností nijak nesouvisí. Je to jen krátká textové informace, kterou server pošle prohlížeči, ten si ji uloží a při příštím požadavku ji pošle serveru zpět.

2847
Vývoj / Re:Proč se v Javě XML nahrazuje YML?
« kdy: 17. 11. 2018, 12:23:00 »
To se cte jako napinava detektivka s prekvapivymi dejovymi zvraty. A jak to teda dopadne?
:-) Prohlížeč usoudí, že autor je nemehlo a zapomíná uzavírat elementy (protože se někde dočetl, že je to úžasná vlastnost HTML, že se mohou uzavírací tagy vynechávat), takže uzavře ten aktuální element <a> a tím pádem může uzavřít i <p>. Pak konečně může zpracovat <hr>. Tím to ale ještě nekončí, protože tam přece bylo to neuzavřené <a>, to se nemůže nechat jen tak. Takže až za to <hr> parser nakopíruje znovu ten otevírací tag <a> se všemi jeho atributy (takže v DOMu ten element bude dvakrát). Pak je konečně <a> uzavřené autorem a dál už je zdroják validní.

Mimochodem, kdyby si s tímhle nevalidním kódem nějaký parser poradil jinak, není kompatibilní s HTML5 standardem. Protože ten definuje i způsob, jak se má parser chovat při jaké chybě. Pokouší se to definovat pro všechny možné chybové stavy, nevím a nechci vědět, zda se jim to podařilo. Takže autor může psát validní HTML5, ale i když napíše nevalidní HTML5, všechny HTML5 prohlížeče by to měly interpretovat (a tedy i zobrazit) stejně. Takže proč by se autor s nějakou validitou dokumentu obtěžoval. Ale určitě se dozvíme, že to, že dokumenty nemusí být validní, také zásadně zlepšuje jejich čitelnost a přehlednost.

2848
Vývoj / Re:Proč se v Javě XML nahrazuje YML?
« kdy: 17. 11. 2018, 09:46:21 »
Ano, nesmíte být hloupý, o jednoduchosti tu nebyla řeč.
Byla, jenže vy jste to stále nezaregistroval. Přehlednost a srozumitelnost je mimo jiné podmíněna jednoduchostí.

Přehledné to ale právě proto je a je lepší když se stroje přizpůsobí lidem a mají složitější parser než když se lidé přizpůsobují strojům.
Opět nechápete, že ten dokument čtou i lidé, a pro jeho pochopení tedy musí text parsovat podobně, jako to dělá stroj. Složitější parser pro stroj znamená složitější a méně přehledný formát pro člověka.

Na první pohled to nevidí nikdo, protože je to neformátovaná zmrdovština, ale jakmile splníte premisu, že je to zavedeno pro potřeby ručně psaných formátovaných dokumentů, což tu musím opakovat jako kolovrátek, protože jste to dosud nepochopil, a dáte to sem naformátované,  pak bude na první pohled zřejmé, že odkaz který začíná v půlce jednoho odstavce a končí v druhé je chybně a je to nevalidní. Nevalidní je proto i ten třetí příklad.
Tím, že budete opakovat jako kolovrátek to, co všichni vědí, se nevyhnete tomu, co stále nechápete – že to vynechávání koncových tagů bylo sice zavedeno pro potřeby ručně psaných dokumentů, ale moc se to nepovedlo. Až později se dostalo do všeobecného povědomí, že zdrojové kódy programů ale i ručně editované *ML dokumenty se mnohem častěji čtou, než píšou, takže zápis musí být optimalizován především pro čtení, ne pro psaní. Holt ten, kdo to píše, musí občas napsat pár znaků navíc, aby se to pak lépe četlo. Navíc těch pár znaků navíc umí napsat každý slušnější editor.

Vidím, že jsem vaše znalosti HTML přecenil. A u toho prvního příkladu jste mě dobře nachytal – já jsem tam přichystal chyták v chytáku, a jak se teď ukázalo, vy jste tam neodhalil ani ten první chyták – takže jste sice napsal správně, že je dokument nevalidní, ale z úplně jiného důvodu.

Když ten třetí příklad přepíšu tak, aby tam byly všechny nepovinné tagy, vypadá takhle:

Kód: [Vybrat]
<!DOCTYPE html>
<html>
  <head></head>
  <body>
    <p>
      text
    </p>
    <p>
      text
      <a href="">text
        <p>text</p>
        <hr>
        text
       </a>
       text
    <p>
      text
    </p>
  </body>
</html>

Problém je v tom, že v HTML nemůže být element p vložený v jiném elementu p. Takže když to bude prohlížeč parsovat a narazí na to vnitřní p, pokusí se ten vnější tag p ukončit (bude předpokládat, že tam je to vynechané koncové p), jenže ho ukončit nemůže, protože má ještě neuzavřený element a a ten má koncový tag povinný.

Z úplně stejného důvodu je nevalidní i tenhle dokument:
Kód: [Vybrat]
<p>text<p>text<a href="">text<hr>text</a>text<p>text
Opět, hr nemůže být uvnitř p, takže se prohlížeč pokusí p uzavřít, ale nemůže, protože je parser vnořený v otevřeném a, které musí být vždy uzavřeno explicitně.

Je hezké, že tady obhajujete to, jak jsou pravidla pro parsování HTML strašně jednoduchá, a sám je přitom neznáte.

2849
Vývoj / Re:Proč se v Javě XML nahrazuje YML?
« kdy: 17. 11. 2018, 08:56:23 »
Důkaz je zjevný, neúspěch xhtml.
Ten váš důkaz je ovšem chybný. Za prvé je spousta dokumentů servírovaných jako HTML ve skutečnosti XHTML dokument. Za druhé, ty dokumenty se označují jako HTML a ne XHTML proto, že prohlížeče parsují HTML a XHTML jinak – parsery HTML jsou v prohlížečích implementované tak, že se zotaví z jakékoli chyby a něco zobrazí. Naproti tomu XML prasery v prohlížečích jsou naprogramované striktně a jakmile je dokument nevalidní, zobrazí jen chybu.

Naopak máme pádné důkazy pro to, že vynechávání koncových značek je hloupost. Za prvé to ani v HTML, kde je to možné, skoro nikdo nepoužívá. Za druhé, po HTML vzniklo mnoho formátů, které mají mít jednodušší zápis, než HTML – např. wiki wiki, Markdown a asi milion dalších. Žádný z nich nezopakoval tu hloupost, že by některé koncové značky udělal nepovinné.

2850
Vývoj / Re:Proč se v Javě XML nahrazuje YML?
« kdy: 16. 11. 2018, 22:25:40 »
Vynechávání zbytečných koncových značek je výborná featura pro vytváření dobře čitelných ručně psaných a formátovaných dokumentů, na což se xml nehodí, což jsem tady nucen opakovat jako kolovrátek.
Nejste nucen opakovat to jako kolovrátek, úplně by stačilo, kdybyste ráčil zaregistrovat, že už jsem vám to mnohokrát vyvrátil. Koncové značky nejsou zbytečné, slouží pro zlepšení čitelnosti dokumentu.

Snaha zpochybňovat to onelinerow kodem ukazuje zaslepenost a zásadní nepochopení téma diskuse.
Jenom jsem za účelem přehlednosti vynechal zbytečné konce řádků… Ono jaksi nejde dokument přehledně zformátovat tak, aby to zároveň nenapovídalo, jak je dokument strukturován. Přece právě proto, aby napovídalo strukturu, se formátování používá.

Ano, takto to validní je, figure ukončuje odstavec. Počet odstavců se rovná počtu tagů p. Tak moc je to jednoduché.
Takže si musíte pamatovat tagy ukončující odstavec a tagy, ve kterých musí být odstavec explicitně ukončen… Opravdu strašně jednoduché a přehledné. Zajímalo by mne, kolik lidí v téhle diskusi na první pohled vidí, proč jsou ty první dva příklady nevalidní a ty další dva validní.

Kód: [Vybrat]
<p>text<p>text<a href="">text<p>text</a>text<p>text

Kód: [Vybrat]
<p>text<p>text<a href="">text<p>text<br>text</a>text<p>text

Kód: [Vybrat]
<p>text<p>text<a href="">text<p>text<hr>text</a>text<p>text

Kód: [Vybrat]
<p>text<p>text<figure>text<p>text</figure>text<p>text

Stran: 1 ... 188 189 [190] 191 192 ... 375