Jízda na Tigrovi, aneb káva s novými příchutěmi

19.9.2006 21:51 | Přečteno: 1900× | Jen tak |

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.

for each

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) {}

Generické datové typy a šablony

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 chybu

Dí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 ).

Autoboxing

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.

Proměnný počet parametrů

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.

Typově bezpečný výčet

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?

       

Komentáře

[Pavel 'lingeek' Szalbot]

Nejdříve musíš ovládnout J2SE a J2EE a potom pod tíhou skutečnosti, že jednoduchá aplikace se bez kontejnerů, servletů, filtrů, adapterů a fazolí neobejde, uvěřit ve své schopnosti. Takový foreach už pak nikdyt nebudeš potřebovat, protože by svým zjednodušením značně znepřehlednil kód...

[Luk]

Nějak jsem to nepochopil

[Pavel 'lingeek' Szalbot]

Člověk se často nevymotá ze snahy pochopit zmíněné frameworky a nové rysy jazyka práci zjednodušující mu v jejich světle přijdou naopak matoucí.

Spousta serverů dodnes běží dokonce na JRE 1.3, ve fórech jsem zachytil nářky lidí, co bojují se špatnou koncepcí a rychlostí Swingu, EJB, Web Start... Novinky v 1.5 jsou pěkné, ale že je vývojáři nepoužívají napovídá, že mají jiné starosti:/.

[Lukáš Zapletal]

Tak tak, programuju s Eclipse RCP a tam se budou změny hodně težko prosazovat. Je to stará Java1.1 škola, řekl bych (není to až tak hrozné, ale jako přirovnání se to dá použít).

[Bubak]

Neexistence promenneho poctu parametru me stve pokazde, kdyz pisu pet konstruktoru.

Foreach bych taky bral. Uz jen kdybych nemusel u nekterych veci zachovavat kompatibilitu s 1.2, to by se to zilo ...

[Ladislav Thon]

foreach: jak by se mělo iterovat přes 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...

[Michal Vyskočil]

Tak, jak to dělají ostatní jazyky. Po znacích. Kdo, chce, může si napsat vlastní třídu, která může iterovat třeba po slovech, nebo po větách. Ale z hlediska konzistence jazyka by byly iterátory ve Stringu imho přínosem.

[Filip Jirsák]

Ostatní jazyky mají většinou definován String jako pole znaků. V Javě je String prostě neměnný text. Skoro bych řekl, že jestli někdo potřebuje v Javě často procházet String po znacích, dělá něco špatně

[Kyosuke]

Heh, když si čtu některé tyhle věci, začínám chápat, že C++ není tak ošklivé. Ad generika – jsou i skeptici.

http://weblogs.java.net/blog/arnold/archive/2005/06/generics_consid_1.html

http://lambda-the-ultimate.org/node/804

defmacro forever!

[Michal Vyskočil]

To je tak, generika do Javy přináší zesílení typového systému, což se někomu může, nebo nemusí líbit. Na druhou stranu vlastně emulují dynamické jazyky, proto je to tak složité na zápis.

Navíc psát List<Object> může člověk pořád, ne?

[VícNežNic]

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)

[Michal Vyskočil]

Řešení je snadné, nepoužívat Eclipse

[VícNežNic]

Nebo nepoužívat Javu, případně oboje. Ať žijí velkolepá řešení

[Michal Vyskočil]

No, pokud vývojové prostředí neschroustne zápis, který je v pořádku, zdá se mi logické je vyměnit za jiné (anebo reportovat bug).

[VícNežNic]

Vypisuje pouze varování, ne že by to nesežralo. Něco ve smyslu: a co tak kdybys tam hodil ty generika, he?

[Filip Jirsák]

Ovšem tohle není problém vývojového prostředí, ale toho, že dotyčný nejspíš moc neví, co dělá.

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

[Michal Vyskočil]

Aha, no tak to jsem pochopil špatně . Jako bych nic neřekl.

[VícNežNic]

To je zase trochu blbý v tom, že zápis List je sice jistě správně, ale v Javě 1.4 a - vám stejně neprojde. Takže takový zápis je v zásadě dobrý jenom k tomu, že se zbytečně zbavujete možnosti (byť třeba pro vás zbytečné) použít to i ve starším kódu. Opravte mě, mýlím-li se

[VícNežNic]

Hm, napsal jsem List<?> jenom ne s entitama a ábíčko se zase postavilo na hlavu. Chjo.

[Michal Vyskočil]

To se Eclipse neumí chovat podle toho, jaký je nastavený -source?

[VícNežNic]

Eclipse umí kdeco. Jenom já s tím neumím

[Filip Jirsák]

Java 1.4 a Java 5 jsou vlastně dva různé jazyky. Můžete si vybrat, zda budete psát pro 1.4, nebo pro 5 – kompilátor verze 5 vám umožní přeložit obojí. Navíc verze 5 je do značné míry zpětně kompatibilní s verzí 1.4, takže kód pro verzi 1.4 většinou jde přeložit i jako kód verze 5, ale to už je samozřejmě s varováním – protože používáte zastaralé konstrukce.

[Leoš Literák]

Jenze nechapu, co je spatneho na tom pouzivat List v JDK 1.5? Co kdyz do nej strkam ruzne objekty? To je prece validni use case. Tyhle generics jsou prece jen nepovinnym rozsirenim, proc potom warningy?

[Filip Jirsák]

List samotný v Javě 5 vlastně zastaralý. Pokud dávám do listu opravdu různé objekty, má to být List<?> nebo List<? extends Object>. Pokud vím, že to budou vždy potomci třeba JComponent, pak List<? etends JComponent> atd.

[Leoš Literák]

A proto jsem se tak dlouho branil. Tahle nova syntaxe se mi hnusi. Kdyz je to obecny List, necht se to pise jako List. Tohle zacina vypadat stejne hnusne jako C++ a jeho sablony

[Filip Jirsák]

On obecný List je takový zvláštní objekt. Pokaždé, když na něj někde narazím, je to pro mne varování, že ten můj program asi není tak úplně objektový, jak by měl být. Takže obecný List je pro mne vždycky varování, a už proto tam napíšu 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 Listu bude kde co

[Lukáš Zapletal]

No tak pravda je asi taková, že Eclipse má vlastní kompilátor ECJ, takže s ním má společného dost. Jinak slouhlasím

[Heron]

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".

[Michal Vyskočil]

Slušný programátor ... byl jsem přesvědčen, že ja Java primárně pro neslušné programátory. Tj. jazyk má bránit prasení co nejvíc.

[Heron]

Nejsem si příliš jistý, jak jazyk (tedy hlavně syntaxe) zabrání prasení. Ono totiž vše lze napsat několika způsoby, některé jsou vhodné, jiné běžné a další nevhodné, jenže všechny syntakticky správné. To, že programátor zvyklý na procedurální kód napíše "enum" tak jak jsi napsal, je chyba toho programátora, že neumí OOP nikoliv Javy. Celkem mě zaráží, že zavedli strukturu "enum", doufám, že se nedočkáme také "struct" .

[Michal Vyskočil]

Ale enum není struktura. Enum v Javě je objekt. Může být použit jako šablona, nebo se dá rozšířit.

[Leoš Literák]

Take pomalu zacinam pouzivat nove vlastnosti JDK 1.5, ale nejak unesen z nich nejsem. Napriklad foreach nad netypovanym listem znamena nutnost pretypovat si Object uvnitr smycky na to, co potrebuji (foreach (Object o : list) { MyObject my = (MyObject my)} - v deklaraci foreahc to nejde.

Typovane listy ci mapy maji silene dlouhy podpis, zkuste si predavat jako parametr typovanou mapu a typovany list . Metoda pak bude mit signature dlouhy stovky znaku

Nejlepsi je autoboxing, pouzivat konstruktory a intValue() atd me nikdy nebavilo a prislo mi uhozene.

[Kyosuke]

Já jsem extrémista: U takovýchhle komplexních jazyků buď důsledná typová inference a pořádný typový systém, nebo radši úplná dynamičnost a pozdní vazba. Signatury funkcí můžou mít pak i tisíce znaků, ale člověk se s tím nemusí psát…

[Michal Vyskočil]

Java 1.8 přinese typedef

Ad to přetypování ve foreach, to je pravda, nemůžeš to zkusit navrhnout do verze 6?

[Filip Jirsák]

Jednodušší je nejprve přetypovat netypový list na typový:

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é

Mně osobně se zase líbí generiky (typované kolekce apod.) a nemám rád autoboxing

[Lukáš Zapletal]

Hezké je, že generiky jsou zpětně kompatibilní. V .NETu to tak myslím není (jsou tam dva typy tříd - pro verzi 1.X a verzi 2.0).

Pokud vím, tak Java 1.6/6.0 bude mít novinky spíše co se týká API a také přepracované AWT...