Zobrazení chyb v integrovaném vývojovém prostředí Eclipse

V závěrečné kapitole předchozí části seriálu o integrovaném vývojovém prostředí Eclipse jsme si řekli, že Eclipse dokáže ve zdrojových kódech napsaných v Javě automaticky zjišťovat některé typy chyb a taktéž tyto chyby v rámci možností opravovat. Dnes se touto problematikou budeme zabývat detailněji. Na prvním obrázku je zobrazen projekt v Javě, který byl vytvořený a otevřený v integrovaném vývojovém prostředí Eclipse. Projekt obsahuje pouze jedinou třídu nazvanou TestClass se statickou metodou main(). V této metodě je zapsán pouze jediný příkaz: volání metody System.out.printl(). Tato metoda však ve skutečnosti neexistuje, na což vývojové prostředí Eclipse programátora upozorňuje, a to hned několika způsoby (připomeňme si, že některé upozornění se zobrazí až ve chvíli, kdy je zdrojový text uložen pomocí klávesové zkratky Ctrl+S):

1. Chybně zapsaný příkaz (volání neexistující metody, použití objektu z balíčku, který není importován atd.) je podtržen červenou vlnovkou přímo v okně editoru zdrojových kódů. Pokud se textový kurzor nachází na chybném příkazu, lze použít klávesovou zkratku Ctrl+1 pro výběr takzvané rychlé opravy („Quick Fix“). Význam této klávesové zkratky si vysvětlíme v následujících kapitolách.
2. Na pravé straně editoru v prostoru napravo od scrollovací lišty je zobrazen červený obdélníček, na který lze najet kurzorem myši. V tomto případě se v místě kurzoru myši zobrazí, o jakou chybu se jedná. Popř. je alternativně možné na červený obdélníček kliknout levým tlačítkem myši; v tomto případě se textový kurzor přesune na vybraný chybný příkaz (výhodné ve chvíli, kdy je v jednom zdrojovém textu více chyb).
3. V okně „Problems“ zobrazeném ve spodní části Eclipse se pro každou chybu či varování vytvoří nový informační řádek obsahující chybové hlášení, soubor, v němž se chyba nachází, a taktéž číslo řádku. V případě, že je tento řádek aktivní, lze pro něj použít klávesovou zkratku Ctrl+1 pro vyvolání funkce „Quick Fix“ (viz též další kapitolu).
4. Vývojové prostředí Eclipse na chybu upozorní taktéž zobrazením červeného křížku na levé straně okna editoru. Podobný červený křížek se zobrazí i v „oušku“ (tabu) v horní části okna editoru, a aby toho nebylo málo, je podobný křížek zobrazen i v oknech „Package Exploreru“ a „Outline“.

Z předchozího textu je zřejmé, že integrované vývojové prostředí Eclipse dokáže upozornit na prakticky jakoukoli chybu ve vytvářeném projektu, a to hned několika způsoby. Na globální úrovni, zejména u projektů sestavených z desítek či dokonce stovek tříd a rozhraní, se jedná především o upozornění na chybu pomocí červeného křížku zobrazeného v okně „Package Exploreru“ a taktéž v okně „Problems“ (takto se chyba zobrazí i tehdy, pokud programátor nemá zobrazen zdrojový kód třídy obsahující chybu) a na úrovni lokální pak o upozornění na chyby přímo v editoru zdrojového kódu.

Obrázek 1: Javovský projekt vytvořený a otevřený v integrovaném vývojovém prostředí Eclipse, v jehož jediné třídě je chyba – volání neexistující metody System.out.printl(). Na tuto chybu dokáže Eclipse programátora upozornit, a to několika různými způsoby.

Poloautomatická oprava chyb ve zdrojových kódech

Vývojové prostředí Eclipse, přesněji řečeno jeho modul JDT, obsahuje nejenom funkce pro detekci chyb, ale i funkce pro jejich poloautomatickou opravu. Nejdříve si připomeňme, jakým způsobem lze opravit jednoduchý překlep v názvu třídy nebo metody. Nejjednodušší způsob opravy tohoto typu chyb spočívá ve stlačení klávesové zkratky Ctrl+1 na řádku, v němž byla chyba nalezena a označena vývojovým prostředím. Eclipse zobrazí nabídku možných oprav, kde se většinou nachází i seznam existujících metod či atributů, jejichž název se podobá jménu metody/atributu uvedeného ve zdrojovém textu. V dolní části dočasného okna s nabídkou oprav se taktéž nachází návrh nové podoby (opraveného) zdrojového textu – viz též snímek obrazovky na obrázku číslo 2.

Obrázek 2: Po stisku klávesové zkratky Ctrl+1 na řádku s chybou se zobrazí nabídka oprav, které dokáže Eclipse automaticky provést.

Alternativně je možné použít klávesovou zkratku Ctrl+1 i v okně „Problems“, které se implicitně zobrazuje ve spodní části Eclipse (ovšem za předpokladu, že je zvolena perspektiva „Java“). Ve chvíli, kdy je klávesová zkratka Ctrl+1 použita v okně „Problems“, zobrazí Eclipse poněkud odlišný dialog než v předešlém případě, ve skutečnosti se však i přes jiný způsob zobrazení použijí stejné nabídky oprav. Zmíněný dialog je zobrazen na třetím obrázku.

Obrázek 3: Po stisku klávesové zkratky Ctrl+1 v okně „Problems“ na řádku s nalezenou chybou se zobrazí toto nové okno, v němž lze zvolit způsob opravy chyby.

Poloautomatické doplnění chybějících importů balíčků či tříd

Podívejme se nyní na další typ oprav, který integrované vývojové prostředí Eclipse vývojářům nabízí. Jedná se o poloautomatické doplňování chybějících importů balíčků či tříd. Tuto funkci si opět ukážeme na jednoduchém ukázkovém příkladu, jenž je zobrazen na čtvrtém obrázku. Z tohoto obrázku je patrné, že v projektu jsou dvě chyby způsobené chybějícími importy tříd List a ArrayList (mimochodem si taktéž povšimněte, že Eclipse nemá žádné problémy se zpracováním většího množství chyb vyskytujících se na stejném programovém řádku):

Obrázek 4: Javovský projekt se zdrojovým kódem, který obsahuje dvě chyby způsobené chybějícími importy.

Na obrázku číslo 5 je dialog zobrazený ve chvíli, kdy je klávesová zkratka Ctrl+1 stisknuta v okně „Problems“ u chyby „ArrayList cannot be resolved to a type“. Eclipse pro tento případ nabízí buď import třídy java.util.ArrayList, což je pro tento případ korektní řešení. Druhá možnost spočívá ve vytvoření nové třídy pojmenované ArrayList a možnosti další pak v přejmenování identifikátoru (což je vlastně případ vysvětlený v předchozí kapitole). Z dosavadních zkušeností by se tedy mohlo zdát, že vždy první volba, kterou Eclipse programátorovi nabídne, je ta správná. To však není vždy pravda, což se projeví hned u opravy druhé chyby…

Obrázek 5: Dialog zobrazený po stisku klávesové zkratky Ctrl+1 v okně „Problems“ u chyby „ArrayList cannot be resolved to a type“.

Poněkud složitější situace nastane ve chvíli, kdy se budeme snažit pomocí klávesové zkratky Ctrl+1 přidat chybějící import pro třídu List. Vývojové prostředí Eclipse v tomto případě zobrazí dialog s odlišnými možnostmi. Na prvních dvou řádcích se nabízí import tříd java.awt.List a java.util.List, takže si programátor musí dát pozor na to, jakou třídu ve skutečnosti má importovat. Jen pro zajímavost se můžeme podívat i na další nabízené volby, například změnu na třídu Line či Listener – Eclipse se v těchto případech opět snaží uhodnout, jaký je správný tvar (prozatím neznámého) identifikátoru.

Obrázek 6: Dialog zobrazený po stisku klávesové zkratky Ctrl+1 v okně „Problems“ u chyby „List cannot be resolved to a type“.

Odstranění nepotřebných importů

Integrované vývojové prostředí Eclipse taktéž umožňuje provést organizaci použitých importů, popř. odstranění těch importovaných balíčků a tříd, které nejsou ve zdrojovém textu zapotřebí. Organizace použitých importů spočívá v jejich seřazení, většinou takovým způsobem, že se nejdříve uvedou v abecedním pořadí importy tříd tvořících standardní API Javy, poté se uvádí (opět v abecedním pořadí) importy tříd z externích archivů a naposled pak importy tříd, které jsou deklarovány přímo v otevřeném projektu. Odstranění nepotřebných importů je založeno na analýze zdrojových kódů. Pokud nejsou některé balíčky nebo třídy ve zdrojovém kódu použity, zobrazí Eclipse varování, které je na rozdíl od chyby zvýrazněno žlutou barvou, namísto barvy červené.

Obrázek 7: Varování zobrazené ve zdrojovém kódu, který obsahuje dva nepotřebné importy. Třetí varování je poněkud odlišného charakteru – zvýrazňuje lokální proměnnou, která není nikde použita.

Pro odstranění nepoužívaných importů lze opět použít magickou klávesovou zkratku Ctrl+1, přičemž se v možnostech objeví nabídka pro pouhé odstranění importu, odstranění importu společně s přeorganizováním všech importů podle pravidel popsaných v předchozím odstavci, nebo lze alternativně do zdrojového kódu přidat anotaci typu @SuppressWarning, pomocí níž se varování skryje (obecně se však přikláním k tomu, aby se tento typ anotace používal pouze ve skutečně odůvodněných případech).

Obrázek 8: Dialog zobrazený po stisku klávesové zkratky Ctrl+1 ve chvíli, kdy se výběrový kurzor nachází nad jedním z nepoužívaných importů. Povšimněte si, že lze současně opravit obě varování – postačuje označit oba výběrové boxy ve spodní části dialogu.

Jednoduchý refaktoring – přesun příkazů do nové metody

Konečně se dostáváme k mnohem zajímavější a pro naprostou většinu programátorů velmi užitečné technologii – k podpoře takzvaného refaktoringu (refactoring). Integrované vývojové prostředí Eclipse totiž dokáže na žádost programátora měnit obsah zdrojových kódů, a to mnohdy i velmi radikálním způsobem. Mnoho změn je prováděno na globální úrovni celého projektu, což například znamená, že přejmenování metody je provedeno ve všech částech projektu, kde se tato metoda volá. Ovšem v žádném případě se nejedná o primitivní operaci typu „najdi a nahraď zadaný řetězec“, protože Eclipse dokáže v naprosté většině případů zjistit, kde je použita přejmenovávaná metoda a kde je naopak použita sice metoda stejného jména, ale patřící k jiné třídě.

Obrázek 9: Zdrojový text před provedením refaktoringu. Naší snahou bude přemístit všechny čtyři příkazy System.out.print() do samostatné metody. Program byl před provedením změn spuštěn a v dolní části okna Eclipse („Console“) je zobrazen text, který program vypsal na standardní výstup.

V této kapitole si ukážeme, jakým způsobem je možné přesunout jeden či několik vybraných příkazů do nové metody. Jedná se o poměrně často používaný způsob refaktoringu, který je založený na myšlence, že by každá metoda měla provádět jen jednu funkci, kterou lze v ideálním případě popsat jedinou větou v dokumentaci (resp. v JavaDocu). Pokud je popis funkce vykonávané metodou příliš dlouhý, znamená to, že metoda je zbytečně překomplikovaná a s velkou pravděpodobností je vhodné její tělo rozdělit do většího množství jednodušších metod. Důvod, proč někteří programátoři tento typ refaktoringu nedělají, spočívá v jeho obtížnosti v případě, že by se všechny změny musely ručně zapisovat v textovém editoru. Právě zde nám může pomoci Eclipse. Celý postup je vysvětlen na následující trojici obrázků:

Obrázek 10: Všechny příkazy, které se mají přenést do nové metody, se nejprve vyberou do bloku. Pro tuto operaci je možné použít myš, klávesy Shift+kurzorové šipky i další příkazy nabízené interním textovým editorem (Edit/Extract Selection To atd.).

Obrázek 11: Následně se v hlavním menu vybere příkaz Refactor/Extract Method. Pokročilejší uživatelé Eclipse namísto výběru příkazu z menu většinou používají klávesovou zkratku Alt+Shift+M. Zobrazí se první část dialogu, do něhož se zapíše jméno nové metody, a ve druhé části dialogu je ukázáno, které operace se skutečně provedou a jak se tyto operace projeví na obsahu zdrojového kódu. Pokud by se změna dotkla většího množství souborů, byly by všechny navrhované změny zobrazeny v horní části dialogu ve stromové struktuře.

Obrázek 12: Výsledek refaktoringu. Eclipse vytvořilo novou metodu, do níž byla přenesena vybraná čtveřice příkazů. Navíc bylo volání této metody doplněno do main(), takže se funkce programu nijak nezměnila. To je patrné i z obsahu okna „Console“, v němž je zobrazen výstup programu.

Změna parametrů metody na základě analýzy jejího volání

V úpravách demonstračního příkladu můžeme pokračovat dále. Metoda printSalutation() vytvořená pomocí postupu popsaného v předchozí kapitole není příliš obecná, protože vypisuje text pouze na standardní výstup představovaný třídou System.out. Ovšem úprava metody printSalutation() takovým způsobem, aby ji bylo možné použít například i pro tisk textu do souboru, je v Eclipse poměrně jednoduchá. Celý postup (založený na ručních úpravách i použití funkcí z Eclipse) je opět ukázán na sekvenci snímků obrazovky:

Obrázek 13: Po ručním doplnění parametru metody printSalutation() označí Eclipse celé volání metody za chybné, protože ve zdrojovém textu je sice deklarována stejně pojmenovaná metoda, ale ta je bezparametrická.

Obrázek 14: Po stisku klávesové zkratky Ctrl+1 se zobrazí nám již známý dialog Quick Fix, v němž Eclipse kromě několika dalších možností opravy chyby nabízí i přidání parametru do existující metody. Právě tuto možnost si vybereme. Povšimněte si, jaký typ parametru byl zvolen – je jím instance třídy PrintStream. Tento typ Eclipse zjistilo ze skutečně použitého parametru.

Obrázek 15: Po provedení opravy lze v metodě printSalutation() ručně odmazat slovo „System“, čímž se namísto volání metody System.out.print() bude volat metoda out.print(), kde out je parametr metody typu PrintStream.

Obrázek 16: Nyní je již možné metodu printSalutation(PrintStream out) volat s předáním libovolné instance třídy PrintStream, takže se tato metoda stala univerzálnější – lze ji použít například pro tisk do standardního výstupu, chybového výstupu, otevřeného souboru atd.

• Eclipse – integrované vývojové prostředí pro Javu i další programovací jazyky
• Využití Eclipse pro vývoj aplikací v programovacím jazyku Java

Podrobný program konference najdete na devconf.cz.

Jiří Eischmann	organiser
Marek Poláček	Introduction to ELF
Jan Kratochvíl	Introduction to ELF
Jakub Jelínek	GCC news
Jakub Hrozek	FreeIPA/SSSD + intro to MIT kerberos
Jan Zelený	FreeIPA/SSSD + intro to MIT kerberos
Alexander Bokovoy	Cross-realm trusts in FreeIPA v3.0
Andreas Schneider	Cross-realm trusts in FreeIPA v3.0
Peter Vrabec	security compliance check in Fedora
Eduard Beneš	SELinux news in Fedora 16
Miroslav Grepl	SELinux news in Fedora 16
Miloslav Trmač	Concise overview of security
Dmitri Pal	Identity Management Roadmap + MIT and kerberos
Steve Grubb	Government Security
Jan Hutar	Software robot competitions around the world and our way
Stanislav Kozina	What can Linux learn from the others
Jared Smith	Swimming Upstream; Creating technical documentation with DocBook and Publican
Bryn Reeves	Supporting the Open Source enterprise
Jaroslav Kysela	ALSA – High Definition Audio (HDA) driver
Bryn Reeves	How to lose data and implicate people
Milan Brož	Disk encryption (not only) in Linux
Edward „Joe“ Thornber	Thin provisioning and snapshots in device-mapper
Zdeněk Kabeláč	Thin provisioning and snapshots in device-mapper
Edward Shishkin	Modular approaches in file system development
Tom Coughlan	Trends in the Enterprise Storage Market
Lukáš Czerner	Btrfs – Design, Implementation and the Current Status
Jiří Pírko	Teaming network device (teaming multiple physical ethernet devices into one logical one)
Ondřej Žižka	Web apps developer’s dream
Vlastimil Eliáš	Centralized Identity management and SSO for jboss.org community systems
Vojtěch Juránek	Continuous integration with Jenkins CI
Christian Sadilek	JBoss Errai Framework
Karel Piwko	Arquillian Drone Helping Ike Get Rid of the Bugs
Pavol Pitoňák	RichFaces – Testing on Mobile Devices
Marek Baluch	RiftSaw 2 or RiftSaw 3
Michal Linhard	Hibernate OGM
Peter Skopek	PicketBox in AS7
Martin Kouba	CDI for Seam2
Jiří Vaněk	New Features in JDK8
Miroslav Novák	HornetQ – fastest JMS (Jave Message Service) provider
Pavel Tišnovský	JSR 223: Scripting for the Java Platform
Lukáš Krejčí	RHQ 4 – what’s new
Martin Malina	What’s new in JBDS 5.0
Mladen Turk	Tomcat 7 and Tomcat 8; Apache httpd 2.4: The Web Server for the Cloud
Geoffrey De Smet	What are Drools, Guvnor and Planner?
Jonathan Blandford	Spice + Gnome 3.x
Matthias Clasen	GTK+ 3 and beyond
Simon Schampijer	Sugar: using the GNOME platform to build a learning platform
Shaun McCance	The GNOME Help System
Jaroslav Řezník	Qt 5 GUI hereafter
Hans de Goede	SPICE
František Řezníček	Towards Unified Messaging
Adam Tkáč	DNSSEC in Fedora 17
Lennart Poettering	Do’s and Don’ts when Writing System Services
Kay Sievers	Do’s and Don’ts when Writing System Services
Kamil Dudka	Common C/C++ error patterns & Static analysis
Ondřej Vašík	Common C/C++ error patterns & Static analysis
Pavel Šimerda	IPsec in Fedora
Rainer Gerhards	rsyslog future
Marcela Mašláňová	Dynamic Software Collections
Jindřich Nový	Dynamic Software Collections
Jaroslav Škarvada	Power management SIG
Harald Hoeyer	A streamlined and fully compatible Linux Filesystem Hierarchy
Phil Knirsch	The future of yum and rpm
Michal Fojtík	Cloud in the wild
Francesco Vollero	Cloud in the wild
Alan Pevec	oVirt overview
Niels De Vos	GlusterFS

Případné chyby nebo chybějící údaje prosíme uveďte v komentářích nebo rovnou pošlete na redakce@fedora.cz.

„Někteří z vás, kteří strkají ten svůj zatrolený frňák do věcí, do kterých jim nic není, si možná všimli adresáře pojmenovaného 17-Alpha.RC1/ na této adrese:

http://dl.fedoraproject.org/pub/alt/stage/

Takže, pokud jste nějaký potížista, komouš a fanda konspiračních teorií ve staniolovém čepci, možná byste si mohl myslet, že jde o vydání Fedora 17 Alpha RC1. To je nejen směšně naivní, ale také zrada! Okamžitě očistěte svou mysl od takových myšlenek. Hned. Varuji vás. Moji přátelé z Googlu mi řeknou, jestli neuposlechnete.“

Pokračování výhružného e-mailu můžete číst v konferenci test-announce. Na stejném místě se také dozvíte, že o necelé tři hodinky později Andre Robatino oficiálně oznámil vydání verze RC2: Fedora 17 Alpha Release Candidate 2 (RC2) Available Now! Stahujte z adresáře 17-Alpha.RC2/.

V první řadě je to aplikace pro mobilní telefony:

• WebOS
• Nokia N9/N9x
• Nokia N900 (.deb), vyžaduje balíky qt-components a libqtm12 z -extras
• Android

Pro ostatní mobilní zařízení je k dispozici adresa m.devconf.cz a nakonec pro všechny účastníky konference, kteří se chtějí pobavit po konferenci a vyrazit do okolních restauračních zařízení, vznikla přehledná mapka na map.devconf.cz.

Pátek: GTK+ Hackfest a válka frameworků

V pátek bude jeden z labů kompletně vyhrazen pro GTK+ Hackfest. V plánu je zapojit se do vývoje několika různých projektů, například zlepšení podpory pro dotykové obrazovky, vylepšení integrace clutteru do GTK+ a další. Druhý lab bude určen „frameworkovým válkám“. Klasická hospodská diskuse programátorů o tom, který z jejich oblíbených frameworků je lepší, přerostla v nápad zorganizovat porovnání přímo na konferenci. Můžete si tak vyzkoušet naimplementovat jednoduchý projekt v Ruby On Rails, frameworku Sinatra nebo Django. Poslední páteční workshop je zaměřený na SELinux, jak vytvářet vlastní moduly a jak správně pochopit AVC zprávy a zpracovat je.

Sobota: Java, fedora-review a speciální architektury

Sobota patří Javě. V první části pátečního labu se zaměří kolegové z JBossu na vývoj aplikací Java EE a použití různých produktů JBoss. Dozvíte se, jaké vývojářské nástroje použít, jak nastavit aplikační server, jak nasadit a debugovat aplikace atd. Odpoledne naváže workshop o Portlet Bridge a o tom, jak portlety integrovat do JBoss portálu. Pavel Tišnovský je určitě známý čtenářům Fedora.cz a ROOT.cz, kam neúnavě přispívá svými články. Jeho lab je zaměřený na práci s IDE Eclipse (seriál o Eclipse na Fedora.cz), a to nejen na to, jak používat základní vlastnosti Eclipse, ale i jak využít různá rozšíření jako např. integraci s vašimi repozitáři, profiling, debugování apod.

V druhém labu bude v sobotu po obědě probíhat praktická ukázka toho, jak použít nástroj fedora-review na ověření a následné začlenění balíčku do distribuce Fedora. Můžete si tak přinést svůj vlastní projekt nebo zabalit a zkontrolovat oblíbenou aplikaci, která ve Fedoře stále chybí. A na závěr bude Dan Horák předvádět své oblíbené hračky. Dan má na starosti sekundární architektury ve Fedoře, včetně PowerPC a s390. V jeho labu se dozvíte o úskalích práce s nestandardní architekturou, jaké jsou časté chyby, které v balíčcích musí řešit, a jak vůbec rozjet a začít kompilovat Fedoru na speciální architektuře.

• Developer Conference 2012 – co přinese pátek?
• Developer Conference 2012 – a co ta sobota?

FPL je placená pozice, ale přestože lídra projektu zaměstnává Red Hat, výběr vždy konzultuje s Fedora Board. FPL je však vůči Red Hatu zodpovědný za správnou činnost projektu.

Jared je zejména hrdý na to, že se během jeho působení coby FPL podařilo rozšířit mezinárodní působnost projektu, což zahrnuje i více mezinárodních členů Fedora Board (včetně jednoho z ČR), projekt dostal aktualizovaný web, zlepšil se systém překladů atd. Jared změnu na postu FPL oznámil dnes ve zprávě Change in Fedora leadership.

Určitou šanci má Unity 2D, které nevyužívá Compiz. Před časem se o portování do Fedory pokoušel Jaroslav „Rezza“ Řezník a zabalíčkování Unity 2D mu přišlo jednodušší než 3D verze. Nicméně nyní, když se k problému opět vrátil, zjistil, že do 2D verze přibyly závislosti, které to výrazně ztěžují.