Někteří z vás si možná všimli, že jsem dlouho nic nenapsal. Neměl jsem moc času, programoval jsem si prográmek pro usnadnění práce s Mavenem. Kdo s Mavenem pracujete, asi víte, že jeden z největších problému při práci s ním je hledání artefaktů (knihoven) ve vzdáleném repository. Pro Eclipse existuje plugin (http://m2eclipse.codehaus.org/), který by to měl usnadňovat. Ale nemám s ním moc dobré zkušenosti. Není příliš stabilní. Dále existuje stránka http://www.mvnrepository.com/, která umožňuje artefakty hledat. Ta mi také moc nevyhovovala.

Když jsem se snažil portovat aplikaci sestavovanou Antem do Mavenu, tak mi po hledání veze a umístění desátého jaru došla trpělivost. Napsal jsem si prográmek s poetickým jménem m2-repoindex (http://m2-repoindex.krecan.net/), který moje potřeby řeší.

Takže ve zkratce, je to Java Web Start aplikace, která umožňuje hledat artefakty podle jména nebo regulárního výrazu viz. obrázek

Věc která mi ve všech programech dosud chyběla, je identifikace jarů. Asi to znáte, máte na disku jar a potřebovali byste znát verzi a kde ho v Maven repositáři najdete. m2-repoindex vám s tím pomůže. Načte jar, spočítá jeho MD5 a podle něj se pokusí najít odpovídající artefakt.

Docela užitečná věc, zvláště když těch jarů máte několik desítek.

Co jsem se z toho naučil?

1. Java Web Start je docela zajímavá technologie. Umožňuje snadnou instalaci Java aplikací a to včetně ikony na ploše a ve start menu. Stačí jen kliknout na odkaz. Měly by fungovat i automatické updaty, ale to se mi zatím nepodařilo zprovoznit.
2. Potvrdil jsem si, že dělat aplikaci ve Swingu jde už docela dobře dělat i v Eclipse.
3. Zjistil jsem, že psát i takto malou aplikaci po večerech zabere dost času. Prvotní napsání jde snadno, ale dostat ji do stavu, kdy se dá zveřejnit je dost náročná činnost. Připadá mi, že přítelkyně začíná žárlit na můj počítač, chodí kolem nás se sekyrou v ruce a nějak divně se usmí

Ano přiznávám se jsem staromilec. Možná dokonce i zpátečník. Mám rád get a set metody a nerad vidím snahu se jich zbavit. Občas se na internetových diskuzích setkám s návrhy jak „lépe“ řešit přístup k vlastnostem objektu. Dokonce se jeden takový návrh dostal do návrhu změn v Javě 7. Návrhy jsou podobné následujícímu:

Místo

private String foo;
public String getFoo() {..}
public void setFoo(String foo){..}

budeme psát

public property String foo;

nebo ještě lépe

@property
private String foo;

Tím si ušetříme spoustu práce s nudným psaním get a set metod. Kompilátor všechno krásně vygeneruje za nás.

Nejvíc mi vadí to, že nikde nevidím problém, který se těmito návrhy má řešit. Nikdo přece už dávno get a set metody nepíše, všechno to za nás dělá vývojové prostředí. Napadá mě jediný argument, a to že tím pomůžeme Javě v nesmyslné válce o implementaci čehokoli na co nejméně řádek. Dosáhneme tím o trochu lepší výsledky při porovnávání počtu řádek s implementací v Ruby nebo C#. To si opravdu všichni myslí, že počet potřebných řádek kódu je to co určuje kvalitu jazyka?

Zpět ale k uvedeným návrhům. Odhlédněme od toho, že ve skutečnosti neřeší žádný reálný problém. Podívejme se co by jejich přijetí znamenalo. Za předpokladu, že by za nás get a set metody generoval kompilátor bychom nezískali vůbec nic. To už rovnou můžeme psát

public String foo;

a přistupovat k poli přímo. Jediné v čem by nám „zjednodušený zápis“ mohl pomoci by mohlo být nějaké automagické sledování změn hodnot a generování příslušných událostí. To bych ale raději řešil aspekty.

Co mi na druhou stranu get a set metody přinášejí? To samé co objektově orientované programování! Možnost skrytí implementace, možnost defenzivního programování a obecně možnost volby. Je totiž mnoho případů, kdy get a set metoda nejsou v té triviální podobě tak jak nám je generuje GUI. Často potřebuji zařídit, aby bylo pole jenom pro čtení. Například když píši neměnitelnou (immutable) třídu. V tom případě udělám set metodu private. Nebo ji udělám protected, když chci, aby ji mohly měnit jen spřátelené třídy. Už vidím návrh, že by se to dalo řešit takto:

public property readonly change protected String foo;

Krása. Neřeší to ale defenzivní programování. Případy, kdy místo

public void setDate(Date date)
{
this.date = date;
}

píši

public void setDate(Date date) {
this.date = new Date(date.getTime());
}

To za mě jazyk nemá šanci vyřešit. To si musím napsat sám. Počítač neví, že chci zabránit tomu, aby mi kdokoliv kdykoliv změnil datum, které mám uložené a proto si chci vytvořit defenzivní kopii. Podobně u vracení kolekcí neví, že nechci aby mi ji někdo měnil a chci ji vracet neměnitelnou.

public List getList() {
return Collections.unmodifiableList(list);
}

A to už vůbec nemluvím o kontrole vstupních parametrů přicházejících do set metody.

Teď se můžeme začít hádat o procenta. Kolik je metod, u kterých mi stačí jednoduchý standardní tvar a kolik je těch, které potřebuji nějak modifikovat? Nemohli bychom náhodou tu většinu řešit magickou anotací a těch pár co potřebujeme změnit napsat postaru? Ne nemohli! Dostali bychom dva různé zápisy pro tu samou věc, museli bychom nějak řešit co dělat, když použijeme anotaci i get metodu a ze všeho by vznikl hrozný zmatek. Ano mohlo by to být stejné jako u implicitních konstruktorů, ale nemyslím si, že nám to všechno stojí za to, jenom kvůli pár ušetřeným řádkům kódu.