Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.6.
Po Red Hat Enterprise Linuxu a AlmaLinuxu byl v nové stabilní verzi 10.0 vydán také Rocky Linux. Přehled novinek v poznámkách k vydání.
Bylo vydáno Eclipse IDE 2025-06 aneb Eclipse 4.36. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Americká filmová studia Walt Disney a Universal Pictures podala žalobu na provozovatele populárního generátoru obrázků pomocí umělé inteligence (AI) Midjourney. Zdůvodňují to údajným porušováním autorských práv. V žalobě podané u federálního soudu v Los Angeles označují firmu za „bezednou jámu plagiátorství“, neboť podle nich bez povolení bezostyšně kopíruje a šíří postavy z filmů jako Star Wars, Ledové království nebo Já, padouch, aniž by do nich investovala jediný cent.
Ultra Ethernet Consortium (UEC), jehož cílem je optimalizace a další vývoj Ethernetu s důrazem na rostoucí síťové požadavky AI a HPC, vydalo specifikaci Ultra Ethernet 1.0 (pdf, YouTube).
Francouzský prezident Emmanuel Macron chce zakázat přístup na sociální sítě pro děti do 15 let. Francie podle něj tento krok udělá sama do několika měsíců, i pokud se na něm neshodnou další státy Evropské unie. Reaguje tak na úterní vraždu vychovatelky, kterou ve východofrancouzském městě Nogent pobodal 14letý mladík. Jednotlivé sociální sítě podle něj mají možnost věk ověřit a vymáhat zákaz pomocí systémů na rozpoznávání tváří.
Byl aktualizován seznam 500 nejvýkonnějších superpočítačů na světě TOP500. Nejvýkonnějším superpočítačem zůstává El Capitan od HPE (Cray) s výkonem 1,742 exaFLOPS. Druhý Frontier má výkon 1,353 exaFLOPS. Třetí Aurora má výkon 1,012 exaFLOPS. Nejvýkonnější český počítač C24 klesl na 165 místo. Karolina, GPU partition klesla na 195. místo a Karolina, CPU partition na 421. místo. Další přehledy a statistiky na stránkách projektu.
Oficiálně byl vydán Android 16. Detaily na blogu a stránkách věnovaných vývojářům.
Byla vydána nová verze 14.3 svobodného unixového operačního systému FreeBSD. Podrobný přehled novinek v poznámkách k vydání.
CSIRT.CZ upozorňuje, že na základě rozhodnutí federálního soudu ve Spojených státech budou veškeré konverzace uživatelů s ChatGPT uchovávány. Včetně těch smazaných.
Na javapolis.com byly zveřejněny návrhy komunity pro novou generaci jazyka Java. Rovněž můžete navštívit výsledky hlasování, které jsou tematicky rozdělené na uzávěry (closures), různé změny v jazyce, používané aplikační servery a (nejen javovské) webové frameworky
Tiskni
Sdílej:
enum
ů, takže požadují switch
na String
, ale hlavně že požadují closures, se kterými nebudou umět pracovat už vůbec… Proč by nebyl užitečný switch na string? Třeba pro konverzi řetězce ze vstupu na enum?Myslíte jako vždy ručně znovu implementovat metodu
Enum.valueOf(String)
? K čemu by to bylo dobré?
To je jako módní mezi javisty, že zesměšňují každého, kdo požaduje užitečné featury?Nevidím nic užitečného na „featuře“, která s větším množstvím kódu umožňuje něco, co umožňuje už jiná stávající vlastnost (enumy), které jsou navíc kontrolovatelné už v době kompilace.
Umožnění switch na string umožňuje více, než ten váš enum. To, že nemáte dostatek fantazie beru. Sice nepřehledně se to dá emulovat - vytvořit třeba naprosto zbytečný enum s hodnotami všech stringů co potřebuji ve switchi, zkonvertovat string na enum, a pak šup s enum hodnotami do switche, ale považuji to za zbytečnou buzeraci - a přehlednost výsledného kódu bude podstatně nižší, než když v tom switchi budou stringy rovnou.Ty Stringy stejně musím někde vyjmenovat, ať ve switchi, nebo v enumu. Jenom ten enum dává programátorovi i překladači jasně najevo, že je to nějaká omezená množina řetězců, a kompilátor to pak také může kontrolovat (např. kontrolovat, že jste ve switchi ošetřil všechny možné hodnoty). Takže jediný případ, kdy by použití switche místo enumu mělo smysl, je potenciálně nekonečný počet možných vstupních řetězců. Jenomže nekonečný switch taky nejde udělat. Navíc pokud ten program bude mít alespoň nějakou kulturu, nebudete mít řetězce přímo v kódu, ale budete je mít jako konstanty – takže kód bude vypadat skoro stejně, jako s použitím enumu, ale nebude tam ta kontrola v době překladu. Jinak v kódu je rozdíl mezi enumem a switchem volání jediné metody, což těžko výrazně sníží přehlednost kódu.
A kompilátor ve switchi nemůže zkontrolovat to všechno co tu píšete? Kompilátor nemůže zkontrolovat, že jste ve switchi ošetřil všechny možné hodnoty? To jsou mi novinky. Znovu opakuji, že to, že Vaše fantazie je omezená na to, kde se dá použít string ve switch - není problém stringu ve switchi.Pokud kompilátoru předem nedám seznam všech přípustných hodnot, nemůže zkontrolovat, že jsem pro každou přípustnou hodnotu napsal odpovídající větev
case
. Pokud by switch pro Stringy přinášel i tu možnost určit všechny přípustné hodnoty, dostanete enum
. Tak proč ho vymýšlet podruhé?
Pokud kód bude mít kulturu, tak bude psán tak, aby byl co nejpřehlednější, nejudržovatelnější a nejčitelnější - což nutně neevokuje mít všechny literály jako konstanty - to tu zase tvrdíte něco co není pravda.Hodnoty ve
switchi
nejsou jen tak nějaké hodnoty spadlé z nebe, ale je to několik hodnot z omezené množiny. Místo takových hodnot se typicky používají konstanty, protože je většinou používáte na více místech. Jenomže pro omezenou množinu hodnot už má Java vlastní datový typ – enum
. A jsme zase zpátky na začátku.
Rozdíl mezi enumem a switchem není volání jedné metody.Najděte víc jak jeden rozdíl:
private static final String ONE = "ONE"; private static final String TWO = "TWO"; private static final String THREE = "THREE"; switch (str) { case ONE: doOne(); break; case TWO: doTwo(); break; case THREE: doThree(); break; }
private enum Numbers { ONE, TWO, THREE}; switch (Numbers.valueOf(str)) { case ONE: doOne(); break; case TWO: doTwo(); break; case THREE: doThree(); break; }Já v tom z hlediska kódu vidím jediný rozdíl, volání metody
Numbers.valueOf(String)
. Z hlediska významu tam vidím minimálně další dvě věci, obě ku prospechu enumů:
private enum Numbers { ONE, TWO, THREE}; switch (Numbers.valueOf(str)) { case ONE: doOne(); break; case TWO: doTwo(); break; }Kompilátor může dát varování, že je switch neúplný, a:
private enum Numbers { ONE, TWO, THREE}; switch (Numbers.valueOf(str)) { case ONE: doOne(); break; case TWO: doTwo(); break; case THREE: doThree(); break; case WINTER: doWinter(); break; }Tohle vám kompilátor s enumem ani nepřeloží. Se Stringem to v obou případech projde, a divit se budete až za běhu programu.
Znovu opakuji, že to, že Vaše fantazie je omezená na to, kde se dá použít string ve switch - není problém stringu ve switchi.Mohl byste napsat nějaký konkrétní příklad? Podle mne 99,99 % užití Stringu ve switchi je případ, kdy mám předem známou množinu řetězců, které očekávám někde na vstupu, a potřebuju zjistit, která konkrétní hodnota na tom vstupu je. Přesně k tomuhle ale má Java enum, a není důvod zavádět další konstrukci (Java není Perl). Ta zbývající desetina promile jsou případy, kdy by se autor kódu měl přeci jen zamyslet, zda to nemá být enum… Napadá mne vlastně jediný případ, kdy nejde enum použít přímočaře, a to je nemožnost dědění enumů. A i v takovém případě je implementace s využitím enumu lepší, než switch se Stringy, které se vám náhle z ničeho nic zjeví v kódu.