Názory k článku
UJO Framework pro Javu

Jezisi kriste .. pred casem jsem narazil na oznam o UJO frameworku na theserverside.com a aspon podle precteni autor ponekud nepochopil pointu a naprogramoval reflektivni datovou knihovnu. Tedy misto toho, aby primarne pouzival v Jave silne typovani a reflexi jenom pro obecne operace pres vsechny (nezname) datove typy, pouziva primarne reflektivni pristup i pro specificka volani datoveho modelu se vsemi nectnostmi (bez kontrol, pomaly).

Posleze autor oznamoval kazdou dalsi mikroverzi tohoto veledila k mohutnemu pobaveni a pozdejsimu nastvani ctenarstva TSS

Viz puvodni diskusi zde: http://www.the­serverside.com/new­s/thread.tss?thre­ad_id=50604#268193

… pouziva primarne reflektivni pristup i pro specificka volani datoveho modelu
opak je pravdou, na rozdíl od konkurenčních ORM frameworků UJO-ORM se při vlastním zpracování SQL dotazu Java reflexe nepoužívá

… se vsemi nectnostmi (pomaly)
obejití reflexe je právě jeden z důvodů, proč je UJO-ORM rychlejší než jeho konkurence ;)

… nectnostmi (bez kontrol)
typové kontroly fungují nejen při zápisu/čten dat do objektu ale i při vkládání parametrů k dotazu

Kazdopadne pred investici casu do ‚UJO‘ doporucuji precist odkazovany thread na theserverside.com.

But Hibernate uses so much runtime reflection?

Many former C or C++ programmers prefer generated-code solutions to runtime reflection. This is usually justified by reference to the performance red-herring. However, modern JVMs implement reflection extremely efficiently and the overhead is minimal compared to the cost of disk access or IPC. Developers from other traditions (eg. Smalltalk) have always relied upon reflection to do things that C/C++ needs code-generation for.

In the very latest versions of Hibernate, „reflection“ is optimised via the CGLIB runtime bytecode generation library. This means that „reflected“ property get / set calls no longer carry the overhead of the Java reflection API and are actually just normal method calls. This results in a (very) small performance gain.

Hibernate Performance Q&A

Posleze autor oznamoval kazdou dalsi mikroverzi tohoto veledila k mohutnemu pobaveni a pozdejsimu nastvani ctenarstva TSS

Mozna by to prorazilo v Greenie? :-D

Musim rict ze mi unika k cemu by mel tento framework slouzit, co je na nem revolucniho a jak ma dosahovat lepsiho performance.

V cem je lepsi UJO Object pred clasickou beanou (POJO)? Kod POJO mi pripada jednodussi a prehlednejsi nez implementace nejakeho ciziho rozhrani pripadne extend z nejakeho ciziho objektu. Set a Get metody krome nastaveni hodnoty casto slouzi k validaci (korekci) vstupnich (vystupnich) parametru. Predpokladam ze udelat toto v UJO properties znamena prepsat metody vaseho UJO objektu pro kazdy parametr zvlastni trida…

Revolucni: co je na ukladani objektu do mapy revolucniho? to snad lze uz od javy 1.1. Akorat ze s javou 5 mate i kontrolovani typu pri kompilaci. Jen pripominam ze to je pouze pri kompilaci a nikoli v runtime. Klasicke POJO ale ma to same dokonce i v runtime.

Performance: memory footprint UJO objektu musi byt radove vyssi nez u POJO (pouziti hashmap implementovani predka … ). Stejne tak jako kazde volani pro nastaveni (cteni) hodnoty musi byt zakonite pomalejsi nez u POJO. Ze serializace do xml je rychlejsi je dano tim nez nemusite delat introspekci objektu ale jenom vypisete hodnoty z mapy. To vzhledem k vetsi pametove narocnosti a k tomu ze jendoduche zapsani nebo cteni hodnoty bude radove pomalejsi mi neprijde jako vyhra. Nezminuji to ze v pripade pouziti mapy JIT compiler nejspis neudela takove optimalizace jake by mohl pri pouziti POJO.

Nechci zbytecne hanet cizi praci jen prijde ze vasemu frameworku davate privlastky ktere mu neprislusi …

… k cemu by mel tento framework slouzit
Oznámení se týká především nové implementace ORM nad UJO objekty, stejně tak jako i výše zmíněné vlastnosti.

•  – jednoduše lze překopírovat atributy jednoho objektu do druhého
•  – klonování objektu do zvolené hloubky
•  – k dispozici generický validátor a komparátor
•  – snadné vyhledání property podle jeho názvu
•  – obnova výchozích hodnot
•  – podpora textových konverzí
•  – serializace do různých formátů atd.

… Predpokladam ze udelat toto (korekci, validaci) v UJO properties znamena prepsat metody vaseho UJO objektu pro kazdy parametr zvlastni trida
Pouze překryjete metody writeValue/re­adValue v předkovi. V metodě máte možnost provádět kontrolu nejen na vybrané property, ale třeba jen pro vybrané datové typy.

… Performance: memory footprint UJO objektu musi byt radove vyssi nez u POJO
Jen připomínám, že UJO-ORM používá implementaci UJO postavenou na poli objektů (nikoli na objektu HashMap) kde výkonnostní/pa­měťové rozdíly nejsou tak významné. Situace se však zásadně změní v okamžiku, kdy do objektu musí zapisovat nějaký framework. Zápis do UJO objektů je pak řádově rychlejší, protože Java reflexi nepoužívá. Výkonu UJO objektům je věnována jedna kapitola v dokumentaci:
http://ujofra­mework.org/ja­vadoc/org/ujo­framework/pac­kage-summary.html#per­formance

… Nechci zbytecne hanet cizi praci
Díky za ohlas, člověk si pak spíše vyjasní, co by se dalo zlepšit v dokumentaci.

Zbytecna prace – Apache BeanUtils resp. ObjectUtils maji vetsinu vyjmenovanych veci nejmene 4 roky. Ostatne i drtiva vetsina „UJO“ vlastnosti se da ziskat z Apahce DynaBean tridy, kdyz na to prijde.

>> Kod POJO mi pripada jednodussi

> Máte pravdu. Výhoda UJO

je v úplně něčem jiném :-D

JavaBeany jsou vrcholem omezenosti. Zásadní výhoda UJO je v tom, že u objektu není předem dáno, jaké má atributy, a každý uživatel objektu si k němu může uložit, co uzná za vhodné. Typ objektu pak, dotaženo do extrému, není dán jeho třídou, ale atributy, které má. _To_ je teprve zajímavé!

V práci něco takového máme, včetně persistence do databáze, a flexibilita je oproti obvyklému doménovému modelu postavenému nad JavaBeanami přímo neuvěřitelná.

Nejsem si ovšem jistý, zda je persistence do databáze postavená na klasických ORM principech, to pravé – ORM je Vietnam of Computer Science a osobně ho považuju za skvělou ukázku toho, jak se po všech stránkách nemá dělat software.

A podle toho, co jsem tak letmo skouknul, je UJO-ORM totéž v bledě modrém, a výše popsanou výhodu úplně pohřbívá. Když mne vyvedete z omylu, budu rád :-)

>Zásadní výhoda UJO je v tom, že u objektu není předem dáno, jaké má atributy, a každý uživatel objektu si k němu může uložit, co uzná za vhodné. 

No musim se priznat ze jsem to moc nestudoval ale z ukazek na homepage plyne ze kazdy UJO objekt ma predem dane parametry stejne jako beany viz vsechny ty public static UJOProperty… takze teto poznamce moc nerozumim protoze to je stejne u POJO.

>každý uživatel objektu si k němu může uložit, co uzná za vhodné. Typ objektu pak, dotaženo do extrému, není dán jeho třídou, ale atributy, které má. 

Jiste dokazu si predstavit vyuziti ale pouze ve specifickych pripadech rozhodne ne jako nahradu POJO pro vsechno kde se da.

V okamziku kdy mate rozsahle projekty date prednost citelnosti a pred flexibilitou. Jendim z kamenu OOP je zapouzdrenost a rozdeleni odpovednosti v okamziku kdy mate mega flexibilni tridu ktera same nevi jake atributy bude mit jak pak o se neda hovorit o Encapsulation.

Jeste jedou dokazu si predstavi pripady kdy se takova trida bude hodit, ale jsou velmi specificke a rozhodne to neni jako nahrada za POJO…