Společnost JetBrains se stala platinovým sponzorem multiplatformního open source herního enginu Godot. K vývoji her lze používat Rider for Godot. Zdarma pro nekomerční účely.
Byla vydána verze 9.0 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Verze 9.0 je založena na Debianu 13 Trixie. Přehled novinek v poznámkách k vydání a informačním videu.
Operátor O2 dává všem svým zákazníkům s mobilními službami poukaz v hodnotě 300 Kč na nákup telefonu nebo příslušenství jako omluvu za pondělní zhoršenou dostupnost služeb.
Společnost NVIDIA vydala verzi 13.0 toolkitu CUDA (Wikipedie) umožňujícího vývoj aplikací běžících na jejich grafických kartách. Přehled novinek v poznámkách k vydání.
Byly vyhlášeni vítězové a zveřejněny vítězné zdrojové kódy (YouTube, GitHub) již 28. ročníku soutěže International Obfuscated C Code Contest (IOCCC), tj. soutěže o nejnepřehlednější (nejobfuskovanější) zdrojový kód v jazyce C.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za červenec (YouTube).
Konečně se ochladilo, možná i díky tomu přestaly na chvíli padat rakety jako přezrálé hrušky, díky čemuž se na Virtuální Bastlírně dostane i na jiná, přízemnější témata. Pokud si chcete jako každý měsíc popovídat s dalšími bastlíři, techniky, vědci a profesory u virtuálního pokecu u piva, Virtuální Bastlírna je tu pro Vás.
Ještě před ochlazením se drát na vedení V411 roztáhl o 17 metrů (přesné číslo není známé, ale drát nepřežil) a způsobil tak… více »Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
PixiEditor byl vydán ve verzi 2.0. Jedná se o multiplatformní univerzální all-in-one 2D grafický editor. Zvládne rastrovou i vektorovou grafiku, pixel art, k tomu animace a efekty pomocí uzlového grafu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GNU LGPL 3.0.
Byly představeny novinky v Raspberry Pi Connect for Organisations. Vylepšen byl protokol auditu pro lepší zabezpečení. Raspberry Pi Connect je oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče. Verze pro organizace je placená. Cena je 0,50 dolaru za zařízení za měsíc.
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é