Byla vydána nová verze 9.16 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
Americká vláda se po převzetí zhruba desetiprocentního podílu ve výrobci čipů Intel chystá na další investice do vybraných firem. Na sociální síti Truth Social to napsal prezident Donald Trump. Jeho ekonomický poradce Kevin Hassett v rozhovoru v televizi CNBC řekl, že nemusí jít pouze o firmy z technologického sektoru, ale i z jiných odvětví.
V Amsterdamu probíhá Open Source Summit Europe. Organizace Linux Foundation představuje novinky. Pod svá křídla převzala open source dokumentovou databázi DocumentDB.
Přesně před 34 lety, 25. srpna 1991, oznámil Linus Benedict Torvalds v diskusní skupině comp.os.minix, že vyvíjí (svobodný) operační systém (jako koníček, nebude tak velký a profesionální jako GNU) pro klony 386 (486), že začal v dubnu a během několika měsíců by mohl mít něco použitelného.
86Box, tj. emulátor retro počítačů založených na x86, byl vydán ve verzi 5.0. S integrovaným správcem VM. Na GitHubu jsou vedle zdrojových kódů ke stažení také připravené balíčky ve formátu AppImage.
Vláda Spojených států získala desetiprocentní podíl v americkém výrobci čipů Intel. Oznámili to podle agentur americký prezident Donald Trump a ministr obchodu Howard Lutnick. Společnost Intel uvedla, že výměnou za desetiprocentní podíl obdrží státní dotace v hodnotě 8,9 miliardy dolarů (zhruba 186 miliard Kč). Částka podle Intelu zahrnuje dříve přislíbené subvence 5,7 miliardy dolarů z programu CHIPS na podporu výroby čipů v USA,
… více »Organizace Apache Software Foundation (ASF) vydala verzi 27 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Knihovna FFmpeg byla vydána ve verzi 8.0 „Huffman“. Přibyla mj. podpora hardwarově akcelerovaného kódování s využitím API Vulcan, viz seznam změn.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) vydal Zprávu o stavu kybernetické bezpečnosti ČR za rok 2024 (pdf). V loňském roce NÚKIB evidoval dosud nejvíce kybernetických bezpečnostních incidentů s celkovým počtem 268. Oproti roku 2023 se však jedná pouze o drobný nárůst a závažnost dopadů evidovaných incidentů klesá již třetím rokem v řadě. V minulém roce NÚKIB evidoval pouze jeden velmi významný incident a významných incidentů bylo zaznamenáno 18, což oproti roku 2023 představuje pokles o více než polovinu.
Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie). Servo mimo jiné nově zvládne animované obrázky APNG a WebP.
S nástupem Javy 1.5 došlo k mnoha vylepšením jazyka. Přesto, že už je tomu nějaký pátek, překvapilo mě, že mnoho programátorů v Javě nové možnosti nevyužívá. No a k nim se řadím i já (na mou (vý)omluvu, dělám v Javě pár měsíců). Určitě jsou kvanta stránek, které se tím zabývají, ale stejně si musím napsat vlastní poznámky.
Jediná věc, kvůli které jsme postoupili martýrium výměny vlastního překladače z jbosse/tomcatu na jdk 1.5 od Sunu. Sice je deploy pomalejší, ale i za tuto jedinou konstrukci se to vyplatí.
O co jde. Návrháři jazyka Java bohužel povětšinou tupě kopírovali C++, zapomínajíc, že nedělají další nadstavbu nad C, ale nový vysokoúrovňový jazyk. Takže pro mě dost nepochopitelně přebrali i cyklus ala C — for(inicializace; podmínka; další akce)
. Díky tomu se procházení třeba polem rovnalo "hezkému" kódu jako
for (int i = 0; i != argv.length; i++) { ... }Jistě, příchozí z C je jako doma, ale toto má být vysokoúrovňový jazyk, kde ne pro procházení obecnou kolekcí nemusí zjišťovat meze. Navíc, pokročilejší datové struktury již nabízejí iterátory, takže ty se procházejí s jejich pomocí (ale jinak, než pole). Na tomto místě musím pochválit krásnou javovskou vlastnost, že je délka pole
length
, zatímco všude jinde je to size()
. Moc hezké.
Iterator i = o.iterator(); while (i.hashNext()) { ... i.next()}
Java 1.5 má naštěstí již foreach a pole podporují iterátory, takže je možné i v Javě procházet kolekce a pole (bohužel ne třeba řetězce, holt konzistence se v některých jazycích nenosí) stejným způsobem a elegantním způsobem. O střeva v podobě iterátorů se stará jazyk sám
for (String arg : argv) {}
Velice hezká vlastnost, která v Javě (z mě nepochopitelných důvodů) chyběla. Díky tomu je možné za pomocí trochy syntaxe navíc alespoň částečně emulovat dynamické jazyky a psát jeden kód, který je na datových typech nezávislý, čímž se typová kontrola naopak posílí.
Hezky to ilustruje příklad ze samotného Sunu. Třída LinkedList obsahuje hnusné metody jako add, které jako parametr berou Object
. Kampak se nám asi ztratila ta proklamovaná typová bezpečnost?
Generické datové typy umožňují parametrizovat třídy, které dopředu neznají typy. V podstatě, jedna implementace (například třídy LinkedList) může obsahovat libovolný datový typ, přičemž můžeme její typ definovat:
List<String> lst = new LinkedList<String>(); lst.add(4); // prekladac ohlasi chybuDíky tomu můžeme psát funkčnost jednou a znovupoužívat ji pro odlišné datové typy. Navíc se nezbavujeme silné typové kontroly (pokud nepoužijeme Object
Další bolístka Javy je v tom, že mimo objektových datových typů jako Integer, používá i vestavěné primitivní datové typy jako int. Tato nekonzistence v jazyce ovšem přináší potíže, které jsou navíc umocněny tím, že většina metod samotné standardní knihovny vrací spíše primitivní int, než Integer. Ovšem int není objekt, to znamená, že je nemožné ho použít třeba jako šablonu. Takže místo List<int>
je nutné psát List<Integer>
Do verze 1.5 bylo potřeba mezi int a Integer převádět "ručně" za pomocí třeba Integer i = new Integer(115)
. Což je otravné, protože překladač má v době překladu všechny informace k dispozici a konverzi může udělat sám.
Integer i = 115; /* java 1.4 found : int required: java.lang.Integer Integer i = 115; ^ 1 error */Což je právě autoboxing, kdy Java obaluje/rozbaluje objekty do primitivních typů a naopak zcela automaticky.
Tohoto využívá nová statická metoda format
třídy MessageFormat, která je definována jako
public static String format(String pattern, Object... arguments);No a dají se s tím dělat hezké věci, jako třeba (viz odkazovaná dokumentace)
int planet = 7; String event = "a disturbance in the Force"; String result = MessageFormat.format( "At {1,time} on {1,date}, there was {2} on planet {0,number,integer}.", planet, new Date(), event);Ti, co znají
printf
z C asi budou překvapeni, Javovská verze toho umí víc. Ovšem, jak vidíme Object, tak je jasné, že opět obcházíme typový systém.
Java před tím nic podobného neměla, takže se výčty dělaly jako
class en1 { public static final int FOO = 0; public static final int BAR = 1; } class en2 { public static final int HAM = 0; public static final int SPAM = 1; }Potíž je v tom, že podle překladače platí
en1.BAR == en2.SPAM == 1
. Takže, pokud očekáváme položku z nějakého výčtu, můžeme tam napsat prakticky cokoliv, protože se jedná jenom o číslo.
Java 1.5 naštěstí má typově bezpečné výčty, takže
enum en1 {FOO, BAR}; enum en2 {HAM, SPAM};A teď už neplatí, že
en1.BAR1 == en2.SPAM == bulharska_konstanta
No a na spousty věcí (třeba anotace, nebo statické importy) jsem tu ani nezmínil. Novinky v 1.5 hodnotím pozitivně, protože pomáhají napravit bolavá místa Javy a zjednodušují programování. Ovšem je nutné podotknout, že se o vývoj této verze Javy paradoxně nejvíce zasloužil právě Microsoft, protože pánové ze Sunu usnuli na vavřínech a libovali si, jaký to mají krásný a dokonalý jazyk.
Doufám, že verze 1.6 bude v nastoleném trendu pokračovat, i když věcí, které bych rád v jazyce viděl, jako jsou ntice, operátory, anebo properties, se asi hned tak nedočkám. Je někde na webu přehledný seznam nových vlastností Javy6?
Tiskni
Sdílej:
String
? Po znacích? Po slovech? Po větách? Je fakt, že StringTokenizer
a podobné záležitosti by Iterable
implementovat mohly...
autoboxing: spíš bych ocenil, kdyby se součástí Collections Frameworku stalo něco jako Primitive Collections for Java, než součástí Javy tohle zatemňovátko. Třikrát fuj autoboxingu/-unboxingu (a statickým importům)!
enum: typově bezpečné výčty se dříve dělaly takto:
public class Enum1 { public static final Enum1 FOO = new Enum1(); public static final Enum1 BAR = new Enum1(); private Enum1() { } }Java 5 pro to akorát přinesla syntaktický cukr, který občas chutná trochu jako sůl, ale co už. Java 6: pokud vím, tak žádné změny v jazyce by nastat neměly. V Javě 7 bychom se zato mohli dočkat těch halasně proklamovaných closures (já bych tomu česky říkal uzávěry a podle definice closure by to mohlo být správně, ale nešť) a s nimi souvisejících referencí na metodu (což je z historických důvodů docela vtipné, ale aspoň že neobšlehli od Microsoftu delegáty). A integrace XML... hm, to už nebezpečně zavání sýšárpem...
defmacro
forever! List<Object>
může člověk pořád, ne? Ano, takový zápis má hrozně rádo Eclipse. (páč když si nastavíte Javu 5 a uděláte seznam bez generik, tak to podtrhne a varuje)To podtržení skutečně znamená varování, a to varování kompilátoru. Eclipse s tím nemá téměř nic společného - akorát to varování kompilátoru prezentuje graficky. Když si ten samý kód zkusíte přeložit sunovským
javac
se zapnutými varováními, dostanete na stejném místě stejné varování. Pokud opravdu chcete, můžete příslušné varování potlačit anotací @SuppressWarnings("unchecked")
. Eclipse varovat přestane, ale mám pocit, že sunovský javac
kompilátor ve verzi 5 tuhle anotaci ignoruje.
Pokud chcete používat kolekci, ve které může být libovolný objekt, není správné používat nekontrolovanou (unchecked) kolekci, ale použít zástupný znak. Místo např. List
použít List<?>
.
Myslím, že vy byste byl první, kdo by odsoudil vývojové prostředí, které ignoruje nebo zatajuje oprávněná varování kompilátoru -source
?
List<?>
nebo List<? extends Object>
. Pokud vím, že to budou vždy potomci třeba JComponent, pak List<? etends JComponent>
atd.
List>
, aby bylo hned jasné, že tam míchám všechno možné. Teda většinou se spíš zamyslím, zda opravdu očekávám, že v tom List
u bude kde co Java před tím nic podobného neměla, takže se výčty dělaly jako...
Slušný programátor by nikdy nenapsal výčet takovým způsobem, jaký byl popsán v blogu. Používají se mnohem lepší způsoby, jak nahradit výčet pomocí tříd a přinášejí s sebou větší výhody, než původní "enum".
typedef
for(Type type: (List<Type>) netypovyList )A celý tenhle problém vzniká při míchání kódu <1.5 a 1.5 dohromady, až bude všude kód pro 1.5, budou všechny kolekce typové