28. června 2009

Konec Spring Modules, nastupuje Spring Extensions

Opožděně jsem si všimnul, že projekt Spring modules již není aktivně podporován (je deprecated) a místo toho je doporučeno přejít na Spring Extensions.

Spring Modules obsahuje rozšíření, moduly, pro jednodušší napojení Spring frameworku na knihovny třetích stran. Kromě toho nabízí pro určité oblasti odstínění od konkrétních technologií, např. obsahuje jednotné rozhraní pro kešování bez ohledu na to, jaká implementace se vybere. Já osobně jsem používal moduly integrující Lucene, EhCache a Jackrabbit.

Již delší dobu jsem měl pocit, že projekt "moc neběží", proto mě ani konec nijak nepřekvapil. Ono je opravdu hodně těžké sledovat všechny ty verze různých knihoven a k tomu pořád dokola rozšiřovat své API a svoji funkčnost. Takto zní i oficiální stanovisko:
"Spring Modules was developed to serve a similar goal and was very successful. In fact, it was too successful and grew beyond anybody's expectations. As such, Spring Modules isn't really flexible enough or scaleable enough to manage a large number of independent projects. Spring Modules has now reached end of life. The modules that are still undergoing active development may be ported to Spring Extensions.".

Spring Extensions mají jiný koncept fungování. Snaží se přitáhnout třetí strany k tomu, aby oni vytvářeli tyto rozšíření (takže něco jako SourceForge, Google code). Rozdíl je zejména v tom, že kromě potřebné infrastruktury budete mít podporu během celého vývojového cyklu včetně podpory při propagaci projektu. Asi budete i zaplaceni - roli interního sponzora jsem moc nepochopil, ale když jim dáte práva na zdrojový kód, když s nimi uzavřete smlouvu, tak bych nějakou odměnu čekal.

Zatím v přehledu aktuálních projektů není ani jeden z původních Spring Modules a doufám, jak se uvádí, že dojde k přesunu.

24. června 2009

Spring ROO

Poprvé jsem o projektu Roo slyšel na konferenci SpringOne v červnu v roce 2007. Tehdy vlastně jen oznamovali začátek projektu a musím říct, že mě to nijak příliš nezaujalo. Dokonce jsem si na tento projekt vzpomněl minulý rok na podzim a myslel jsem si, že ten projekt již dávno skončil.

A neskončil. Po dvou letech se objevila první verze, oznámení proběhlo na SpringOne v letošním roce.

Obecně mám k různým generátorům negativní přístup, proto mi trvalo chvíli, než jsem si našel čas a podíval se na to, co vlastně Roo nabízí. A byl jsem pozitivně překvapen:

  • Roo shell se zdá být mocný nástroj.

  • Sami autoři také asi nemají nejlepší zkušenosti se "standardními" generátory kódu a již z deklarace hlavních myšlenek projektu je cítit jiný přístup. Tedy snaha o to, aby Roo byl pomocníkem a ne omezovačem. Roo je možné použít pro rychlé nastartování projektu, dokonce je možné zapojit Roo do již existujícího projektu. Nebo naopak kdykoliv Roo opustit. To je díky tomu, že Roo vlastně negeneruje přímo Java zdrojový kód, ale využívá AOP pro generování do zkompilovaného class souboru.

  • Vygenerovaný kód je postavený na jiných Springových projektech (Spring framework, Spring security), a proto mi nedělá žádný problém se orientovat v těchto souborech a případně je upravovat, doplňovat. Jediné co je navíc, jsou specifické @Roo anotace pro generování výsledného kódu resp. zkompilovaného kódu. Zde se intenzivně používá AspectJ inter-type declarations.

  • Líbí se mi, jak lidé ve Springu se stále drží svých ideologických představ o správném vývoji aplikací, což je vidět i zde. Kromě produkčního kódu se generují unit testy, dokonce s napojením na Selenium.

  • Samotný projekt Roo je napsán hodně flexibilně - kromě základních služeb Roo obsahuje rozšíření (tzn. add-ons), které právě dodávají Roo všechny ty možnosti generování. Takže teď je např. rozšíření pro Maven nebo Hibernate, ale do budoucna může být pro ANT nebo TopLink. Navíc je tu možnost vývoje vlastních rozšíření.


Někde jsem četl názor o tom, proč má Spring dva nástroje na generování kódu - nyní nově Roo a dříve získané Grails. Oba nástroje znám jen velmi povrchně, takže je nemohu moc porovnat. Snad jen, že Grails vyžadují Groovy oproti Roo. Určitě jsou nástroje z výsledného přínosu hodně podobné, ale Roo míří svými možnostmi o dost dále. Kromě toho byl projekt Roo spuštěn dávno před tím, než bylo jasné, že SpringSource získá G2One a tedy Grails. Navíc se domnívám, že hlavním důvodem akvizice nebyly Grails, ale jazyk Groovy. Co bude dále nevím, ale vypadá to, že oba dva projekty pojedou stále dále bez nějakého omezení.

Projekt je nyní ve verzi 1.0.0.M2 a v brzké době bude uvolnění verze 1.0. Hlavním představitelem projektu je Ben Alex, který je mimo jiné hlavním autorem Spring security. Tedy aspoň pro mě záruka kvality.


Odkazy pro více informací:

11. června 2009

Rozcestník knihoven

Na intranet jsem psal takový rozcestník odkazů na různé knihovny a třídy, který by měl posloužit k tomu, aby se programátoři nejdříve podívali, zda to co potřebují řešit, není již náhodou někde (lépe) vyřešeno. Myslím, že tento rozcestník se může hodit i někomu z vás.

Následující rozcestník slouží k rychlé navigaci, pokud potřebujete pracovat s určitými datovými typy nebo provést nějaké obecné operace:

  • řetězce (String) -> StringUtils, StringEscapeUtils, StrTokenizer nebo WordUtils z Commons Lang.
    • kontrola na prázdné řetězce, hledání a náhrada znaků (řetězců) v řetězci, mazání částí řetězce, převod na malá/velká písmena, dělení řetězce na části, mazání mezer a doplňování řetězců, kontrola na čísla, alfa znaky apod., otáčení řetězců, porovnání řetězců,
    • práce s escape znaky pro Java, Java Script, HTML, XML, and SQL
    • dělení řetězce, práce s částmi řetězců
    • práce se slovy v řetězci

  • datumy (Date) -> DateUtils
    • posun datumů, zaokrouhlování, získání určité složky z datumu

  • čísla (Number) -> NumberUtils
    • převod řetězců na čísla, min. a max. hodnoty, porovnání desetinných čísel

  • boolean -> BooleanUtils
    • převod řetězců na boolean, převod čísel na boolean a obráceně

  • pole (Array) -> ArrayUtils
    • přidávání, mazání, hledání prvků v polích, vytváření pod-polí, převod na pole primitiv

  • kolekce (Collection) -> ListUtils, MapUtils nebo SetUtils z Commons - Collections
    • množinové operace s kolekcemi

  • equals() a hash() -> EqualsBuilder a HashCodeBuilder
  • toString() -> ToStringBuilder
  • soubory, adresáře (File) -> FileUtils nebo FilenameUtils z Commons IO
    • vytváření, mazání souborů a adresářů, čtení a zápis dat, kopírování souborů a adresářů, porovnání obsahu souborů
    • práce se jménem souborů a celou cestou k souboru

  • streamy (InputStream, OutputStream) -> IOUtils
    • čtení a zápis dat, kopírování mezi streamy, zavírání streamů, porovnání streamů

  • kódování (Base64, Hex, SHA, MD5, ...) -> Common Codes


Pokud hledáte snad ještě něco jiného, tak doporučuji se podívat na následující projekty:

2. června 2009

Jaký máte vztah k Java anotacím? - výsledky

Poslední anketa se týkala anotací a dopadla následovně (hlasovalo 125 lidí):

  • Používám, ale jen někde (43%)
  • Mám je rád, používám, kde se dá (38%)
  • Nemám je rád, snažím se jim vyhnout (10%)
  • Nevadí mi (8%)


Já sám jsem hlasoval pro "Používám, ale jen někde" a nejsem moc zastáncem používání anotací všude, kde se dá. Osobně nejčastěji používám Hibernate Annotations nebo JPA anotace a Spring a jUnit anotace při psaní testů.

Zeptal jsem se pár kolegů na jejich názor na anotace (1, 2) a v následujícím resumé se to pokusím nějak shrnout:

Argumenty pro:
  • jednoduché, intuitivní - toto se může lišit anotace od anotace, ale dost často je zápis pomocí anotace jednodušší než nějaká jiná podoba konfigurace.

  • větší flexibilita - díky používání anotací může být určité řešení flexibilnější než standardní verze bez anotací. Jako příklad bych uvedl Spring MVC - klasická verze vs. verze s anotacemi. Anotace přináší určitě větší flexibilitu, asi i větší jednoduchost používání a menší nároky na učení se klasického API kontrolerů, ale dle mého názoru to jeden nedostatek má. Zejména u větších projektů se hodí, když má projekt nějakou strukturu, nějaká pravidla a toto se hůře vynucuje pomocí anotací než při používání klasického API. Uvedu jeden konkrétní příklad: myslím, že je vhodné mít odkazy na JSP stránky a URL adresy mimo vlastní Java kód kontrolerů. V klasickém API mám settery na viewname, ale co u anotací? Vytvořím si vlastní předky, ale už to zase bude na úkor nějaké funkcionality, které mi anotace nabízejí.

  • pro popis metadat - anotace mi umožňují přidat klasickým třídám (POJO) nové vlastnosti, které není potřeba implementovat přímo v Java kódu. Např. že je třída resp. metoda deprecated, že je třída volána v transakci pouze pro čtení, že je metoda pouze pro uživatele s rolí READ apod.


Argumenty proti:
  • již není POJO - pokud chcete psát "lehké", testovatelné a flexibilní aplikace (z pohledu budoucích změn), pak je určitě dobré používat POJOs. Jen pak je možné používat dané objekty v různých scénářích a prostředích - testy vs. produkční nasazení, objekty ve webové vrstvě vs. DAO vrstva apod. Neplatí to obecně pro všechny anotace, ale některé anotace vyjadřují určitou implementační závislost nebo předepisují dané třídě určité chování, které je platné jen pro určité použití. Konkrétně třeba @Transactional. Nebo nastavení zabezpečení objektů pomocí anotací, EJB anotace apod.

  • konfigurace aplikace nepatří do Java kódu - já sám mám raději několik konfiguračních souborů, kde najdu veškerou konfiguraci než to vše mít roztroušené po jednotlivých Java třídách. Na to zase většina řekne, že je super vidět u každé třídy hned dané vlastnosti (např. nastavení transakce, zabezpečení) než to hledat někde v separátních souborech. Dle mého názoru je lepší mít konfiguraci oddělenou od Java kódu a mít tak možnost nezávislého nastavení aplikace (nebo jejich částí) pro více prostředí.


Anotace mi přijdou jako velice flexibilní nástroj, ale i tak pořád spíše tíhnu ke klasickému vývoji bez anotací. Ale zase je potřeba se na vše dívat z různých pohledů, takže vlastně nelze obecně říci, co je lepší - takto dopadly i výsledky ankety :).