Porównanie obu bibliotek można znaleźć na stronie JSF Matrix, ale niewiele z niego wynika, jak to zazwyczaj bywa ze statystykami w rodzaju “liczba dostępnych komponentów”.

Kto i co robi
Zacznijmy od krótkiego przedstawienia obu bibliotek.

RichFaces. Biblioteka była produktem firmy Exadel, która połączyła się, albo została kupiona przez JBoss-a, czyli RedHata. Ehh, ten świat wielkich korporacji… Biblioteka jest dostępna na licencji Open Source, zawiera ponad 50 różnych komponentów JSF.

ICEFaces jest robiona przez firmę ICESoft i też jest opensorsowa.

Zalety RichFaces i wady ICE Faces
Dużą zaletą RichFaces jest pod-biblioteka Ajax4JSF, która pozwala “zajaksować” dowolny komponent JSF. Jest to bardzo wygodne, jeżeli mamy już napisany kawałek aplikacji i chcemy gdzieniegdzie ją upiększyć ajaksowymi wodotryskami.

Kolejną przyjemną cechą RichFaces jest możliwość określenia zachowania komponentów tak, żeby niekoniecznie za każdym razem łączyły się z serwerem (Ajaxa im można wyłączyć, innymi słowy). Można na przykład utworzyć stronę z zakładkami w ten sposób, że wszystkie są od razu ładowane i przy ich zmianie nie jest potrzebny kontakt z serwerem. Oczywiście można także skonfigurować sobie zachowanie ajaksowe, czyli zakładki będą doładowywane dynamicznie.

ICEFaces czegoś takiego nie potrafi, jego komponenty zawsze kontaktują się z serwerem, co jest trochę głupie w przypadku dajmy na to komponentu kalendarza – można go przecież zrobić łatwo po stronie klienta, każdorazowy kontakt z serwerem jest w 95% przypadków zbędny. Swoją drogą to jakaś obsesja, większość komponentów kalendarzowych ludzie robią ajaksem, tak przynajmniej mówi jsfmatrix.net.

ICEFaces pozwala używać JSF 1.2, ale wymaga używania trybu zgodności ze specyfikacją JSF 1.1. Trochę lipa.
W web.xml trzeba deklarować użycie starej wersji JavaServelts

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">

a w faces-config.xml:

<!DOCTYPE faces-config PUBLIC "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN" "http://java.sun.com/dtd/web-facesconfig_1_1.dtd">

Przez to nie możemy wykorzystać różnych fajnych rzeczy, które wniosło JSF 1.2.

Łatwiej jest testować aplikacje, które używają RichFaces, bo JSFUnit wspiera właśnie to rozwiązanie – nic w tym dziwnego, gdyż JSFUnita robi RedHat.

Zalety ICE Faces i wady RichFaces
Ok, wygląda na to, że RichFaces wygląda lepiej, ale parę rzeczy w ICE też mi przypadło do gustu. Przede wszystkim wygląd, komponenty są na prawdę dopracowane, wyglądają perfekcyjnie.

Druga rzecz, to sposób odświeżania strony JSF. ICE robią aktualizację wszystkich elementów ajaksowych na całej stronie, dzięki czemu nie musimy się martwić o synchronizację obsługi różnych żądań ajaksowych. W RichFaces trzeba to robić ręcznie, co ma swoje wady.

ICEFaces mają lepiej działającą obsługę ajaksa w trybie “push”, RichFaces też to potrafią, ale stosunkowo od niedawna, więc ciężko stwierdzić, na ile ich implementacja działa niezawodnie.

No i wreszcie na koniec ICEFaces dobrze integrują się nie tylko z Eclipse, ale także z NetBeansem (dla mnie to ważne, bo coraz częściej używam tego drugiego).

Decyzja?
Póki co, zdecydowanie RichFaces.