Są artykuły, po których czasem spać nie można nocą... do takich należy wpis "Critical security issues found in the Spring Framework".
Gorąco polecam bo niby wszyscy tyle wiemy...ufamy wszelakim 'frejmłorkom' a czasem z lenistwa czy nieświadomości możemy się narazić na bardzo przykre konsekwencje.
Wystarczy ktoś komu się będzie chciało ciut bardziej niż nam...i zrobi coś więcej niż wciśnięcie 'Back' w przeglądarce.

<j./> 

 

Błądzić jest rzeczą ludzką...ale są pewne granice.
Ostatnio spotkałem się z następującą 'genialną' (i zupełni niepotrzebną) implementacją komparatora.

class FirstElementComparator implements Comparator {
    private  int EQUAL = 0;
    private  int LESS_THAN = -1;
    private  int GREATER_THAN = 1;
    public FirstElementComparator() {
       
    }
   
    /**
     Always puts the first element at the top of the TREE and so on
     */
    public int compare(Object key1, Object key2) {
        int result = GREATER_THAN;
        if(key1.toString().equals(key2.toString())) {
            result = EQUAL;
        }
        return result;
    }
}


i weźmy teraz fragment kodu, który wykorzystuje powyższą klasę:

    void testTree(){
   
        Map map = new TreeMap(new FirstElementComparator());
       
        map.put("KEY1", new Integer(0));
        map.put("KEY2", new Integer(1));
        map.put("KEY3", new Integer(2));

        Collection keys = map.keySet();
        Iterator it1 = keys.iterator();
        while(it1.hasNext()){
            Object key = it1.next();
            System.out.println("key = " + key + " value = " + map.get(key));
        }
               
    }


a oto wynik testu ;-)

 

key = KEY1 value = null
key = KEY2 value = 1
key = KEY3 value = 2


Hmm...trzeba przyznać, że nawet Sun nie docenił niewiedzy programistów...a swoja drogą..do tej pory się zastanawiam co autor tego komparatora chciał osiągnąć...

<j./> 

Trochę rozmyślań o tym co się wydarzyło związanego z Javą w ciągu ostatnich kilku miesięcy. Niestety ostatnie półrocze optymizmem nie napełnia.
W zasadzie niewiele się dzieje. Java EE 5 nie podbija świata, mało kto używa Java SE 6. W dodatku  co widać na filmach na JavaOne też wiało nudą.
Jedyne Rod Johnson i jego SpringSource pracują w pocie czoła i nie ustają w obdarowywaniu świata ;-)
A to wszystko przez fanatyczną awersje do EJB...jak widać takie emocje mogą być wyjątkowo owocne.
Czyżby świat Javy zmierzał do swego kresu...jako język (polecam przemyślenia na blogu N.Gaftera) i jako technologie?...Hmm...mam nadzieje, że nie...bo inaczej będę musiał zmienić zawód, a na murarce się nie znam.

<j./> 

No tak...ostatecznie dostałem kosza z firmy na literkę G.

Trzeba się pozbierać i żyć dalej...

może trzeba sobie postawić inne priorytety? 

<j./> 

Sporo się dzieje ostatnio w świecie...wyprzedaże...wyprzedaże...
O ile zakup MySQL 'a przez Sun Microsystems to po prostu uzupełnienie oferty produktów.
To druga informacja nie nastraja mnie optymistycznie.
Oracle wreszcie dopieło swego i kupuje firmę BEA.
Pomijając osobisty uraz do Oracle'a i jego produktów...to chyba niezbyt dobra wiadomość dla kientów.
BEA ma naprawdę dobre aplikacje...ale obawiam się, że wkrótce to zdanie trzeba będzie powiedzieć w czasie przeszły.
Czy będzie lepiej? Wątpie. Czy taniej? No nie wiem.

Jakie to ma znaczenie dla J2EE?...wrodzony optymizm mówi, że dobijające.
Na placu boju zostają Oracle (+BEA), IBM i Sun (tak trochę dalej), a z otwartego oprogramowania JBoss, Geronimo (czyli IBM) i Glassfish (czyli Sun).
Ale tak naprawdę z ostatniej trójki jedynie JBoss liczy się komercyjne (tylko to zarządzanie jak promem kosmicznym...).
I tak z 6 zrobiła się 4. Pewnie entuzjaści Spirng'a są w siódmym niebie...ale mi jakoś żal Weblogic'a...i zimy też żal.

<j./>

Ze wzdlędu na różnorodność wsparcia poszczególnych JSRów w telefonach komórkowych oraz wraz ze wzrastającymi możliwościami telefonów komórkowych pojawiła się idea większego niż dotychczas ujednolicenia specyfikacji bazowej dla urządzeń mobilnych zwana Mobile Service Architecture (JSR 248 ).
Określa ona grupę obowiązkowych funkcjonalności, oraz kilka opcjonalnych API.

Copyright 1994-2007 Sun Microsystems, Inc. (źródło http://java.sun.com/javame/technology/msa/ )

 

Do ciekawych stron związanych z tą tematyką zaliczyć należy:

• phoneME mający na celu ujednolicenie środowiska w urządzeniach mobilych jak i udostępnienia go dla takich platform jak PSP czy iPod.
• Mobile Ajax for Java ME pochodzący z bardzo ciekawej witryny ME application developers project, na której znaleźć można wiele ciekawych aplikacji mobilnych wraz z kodem źródłowym.

Głodnych nowych informacji w tej tematyce należy odesłać na strony Mobile & Embedded Community.

<j./> 

 

Stephan Janssen główny organizator konferencji JavaPolis przedstawił nową wersję serwisu parleys.com.
Trzeba przyznać, że aplikacja której front napisany jest w Flex'ie prezentuje się znakomicie co doskonale widać na przykładzie takich aplikacji jak książka Anatomii.
Do pobierania danych wykorzystana została technologia Adobe BlazeDS, której to protokół AMF (Action Message Format) został niedawno przekazany w formule open source. Porównanie tej technologii z innymi sposobami przesyłania danych można znaleźć na BlazeBench.
Jednak technologie Adobe nie są pozbawione wad...co widzi każdy użytkownik nieposiadający wielordzeniowego procesora i kilku giabajtów pamięci...Wynika to min. z faktu, iż każdy obiekt typu flash na stronie rezerwuje sobie pamięć tylko dla siebie...i z tego co wiadomo..tak na razie zostanie. Innym zagadnieniem jest problem indeksowania takich aplikacji przez wyszukiwarki internetowe.

Dodatkową zaletą technologii Adobe jest możliwość łatwego przeniesienie aplikacji ze strony www...do aplikacji typu desktop analogicznie jak to ma miejsce w projekcie Mozilla Prism, ale na dzień dzisiejszy chyba prowadzi Adobe.

Na koniec test bąbelkowy różnych technologii webowych.

<j./>

Oto lista najważniejszych elementów jakich możemy spodziewać się w nowej korporacyjnej wersji Javy:

• EJB 3.1
• JPA 2.0
• Servlet 3.0
• JSF 2.0
• JAX-RS 1.0
• Web Beans 1.0

Prawdopodobnie za opcjonalne w standardzie zostaną uznane Entity Beans (zastąpione przez JPA), JAX-RPC (zastąpione przez JAX-WS), JAXR (rzadko używane).
Za istotny element należy uznać tendencję do uczynienie specyfikacji jak najbardziej modułowej co pozwoli używać tylko tych elementów, które są nam potrzebne.
W świecie realnym powinno to przełożyć się na szybsze (przynajmniej przy starcie) działanie serwerów aplikacji.

Etapy wdrażania standardu to:

• Q1 2008 publiczne omówienie (ang. public review)
• Q3 2008 ostateczny szkic (ang. proposed final draft)
• Q4 2008 wersja beta implementacji referencyjnej (ang. RI beta release)
• Q2 2009 wersja finalna (ang. final release)

Główny nacisk został położony na dalsze uproszczenia w procesie tworzenia aplikacji oraz na większe użycie adnotacji. Jednym z celów jest pozbycie się konieczności edycji pliku web.xml właśnie przez wprowadzenie nowych adnotacji (np. @Servlet).
W specyfikacji servletów spodziewać się można wsparcia dla asynchronicznego przetwarzania żądań oraz standardowej obsługi dla wrzucania plików.
W EJB 3.1 za opcjonalny zostanie uznany interfejs lokalny, umożliwione zostanie włączenie EJB do pliku war, pojawi się nowy typ fasolek Singleton Beans z dwoma typami dostępu @ReadOnly i @ReadWrite w celu optymalizacji. Timer Services rozwinięte zostaną o możliwości zbliżone do CRONa, zwiększy się wsparcie dla asynchroniczności, oraz możliwość użycia stanowego EJB jako Web Service'u.
Reasumując będzie więcej i prościej, a czy lepiej zobaczymy...

<j./>

Ciągle mam mieszane odczucia co do tego pomysłu. Zwłaszcza jak zobaczyłem połączony kod Javy i JavaFX... współczucia dla tego, kto przejmie opiekę nad aplikacja pisaną w ten sposób.
Nie omieszkałem podzielić się swym sceptycyzmem z prowadzącym prezentację i nawet znalazłem zrozumienie. Jim Weaver pokazał jak on widzi połączenie tych technologii, według niego JavaFX powinien służyć jedynie do prezentacji i interakcji z użytkownikiem, a cała logika biznesowa powinna zostać oddelegowana do kodu Javy. Może i jest to jakieś wyjście...
Na koniec może warto zajrzeć na Scene Graph .

<j./>