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

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