pátek 21. března 2008

Používáte v equals metodě getClass a nebo instanceof?

Jak jinak začít, než střelbou do vlastních řad. Tak jsem byl pro změnu zase jednou za blbce... V několika třídách jednoho modulu jsme měli následující implementaci equals metody.

01   public boolean equals(Object obj) {
02     if (this == obj)
03       return true;
04     if (obj == null)
05       return false;
06     if (getClass() != obj.getClass())
07       return false;
08     final Foo other = (Fooobj;
09     if (something == null) {
10       if (other.something != null)
11         return false;
12     else if (!something.equals(other.something))
13       return false;
14     return true;
15   }
Java2html

Na první pohled nic zvláštního, kód bude fungovat. Až do chvíle kdy se rozhodneme, že třídu s takto naimplementovanou metodou equals začneme používat v Hibernatu resp. stane se z ní entity beana. V takovém případě nám možná řádek číslo šest způsobí nemalé problémy. Co se stane? Hibernate nám totiž může podstrakovat proxy objekty (na tuto informaci mě úplně prapůvodně upozornil Lukáš Bartoň) a v takovém případě bude volání této metody vždy false. Řešení je prosté, nikoliv však samospásné a to používat instanceof.

Proč ne samospásné? Protože pokud takto použijeme instanceof, pourušíme symetričnost kontraktu equals pro případ předek (A) potomek (B). Nebude totiž platit, že a.equals(b) == b.equals(a). Samozřejmě můžeme upravit equals tak, aby to prošlo. Osobně mi přijde lepší použití instanceof.

Problematika instanceof versus getClass in equals Methods celkem pěkně rozebrali Joshua Bloch a Bill Venners. Článek vřele doporučuji přečíst.

Když jsem ve třídách opravoval equals metody, tak mě trklo, kde se tam ten kód vzal. Samozřejmě jsme si jej nechali vygenerovat Eclipsem. Chtěl jsem tedy spílat na Eclipse, že negeneruje kód podle mých představ. Naštěstí jsem to neudělal, protože Eclipse při generování equals metody přímo nabízí možnost použití instanceof. Což me vede ke konstatování, že to IDE je chytřejší než opice...

Zdroje

středa 19. března 2008

EJB 3.1 první verze specifikace je venku

Když jsem si tu dělal minule trochu legrace z EJB 3.1 ani ve snu by mě nenapadlo, že brzo spatří světlo světa první verze specifikace.

Pokud jste zmeškali anoncovaný výčet novinek, tak tady je ještě jednou ve zkratce a z rychlíku (detailní popis najdete v odkazovaném článku).

  • .war packaging of EJB components
  • Optional Local Business Interfaces
  • Portable EJB Global JNDI Names
  • Singletons
  • EJB "Lite"
  • EJB Timer Service Enhancements
  • Simple Asynchrony

Dnes budu volit trochu smířlivější rétoriku. Ač jsem byl hodně skeptický ohledně EJB 3.1 a přišlo mi, že tuto technologii nikdo nepotřebuje tak musím uznat, že by mohla vyřešit hodně současných problému v EE oblasti. Každé zjednodušení se cení a třeba v oblasti deploymentu je to více než dobrá zpráva. Pokud bude EJB "Lite" opravdu Lite pak se možná dočkáme toho, že bude například v Tomcatu, Jettym a nebo dokonce naimplementovaný přímo Springem.

Radost mi trochu kazí dvě věci. Za prvé je to doba, než se EJB 3.1 dostane do produkčního nasazení. Kolik z vašich aplikací může využít J2EE 5? Naše aplikace jedou stále nad J2EE 1.4 a horko těžko jsem prosazovali alespoň přechodu na pětkovou řadu standardní Javy. Druhým problémem je přenositelnost, stejně jako v případě jiných standardů mají specifikace bílá místa a ne všechno odhalí testy kompatibility. Jediné na co se dá snad opravdu všude spolehnout je Servlet API.

Z pohledu Springu jsem se zkoušel zamyslet nad tím, co pro něj bude EJB 3.1 znamenat. Populární otázka, která vyvolá řadu emocí je:" přinese EJB 3.1 konec Springu?". Osobně si to nemyslím ba naopak. EJB 3.1 přinese zjednodušení věcí, kterým se ani ve Springu nevyhenete - deployment, přenositelné JNDI jména.

Již nyní je Spring certifikovaný pro nejpoužívanější komerční aplikační servery jako WebSphere a WebLogic. V případě EJB lite, tedy jakéhosi subsetu EJB 3.1 API, je to příležitost jak by se mohl Spring ještě oficiálněji uchytit v těchto aplikačních serverech. O open source řešeních ani nemluvě.

Související články:

.