Nowe wydanie Technology Radar z ThoughtWorks!

Jeśli zastanawiasz się czy technologie i narzędzia, z którymi pracujesz są trendy, akceptowalne, a może są przeżytkiem, to koniecznie zajrzyj do najnowszego, lipcowego wydania Technology Radar wydawanego co jakiś czas przez ThoughtWorks.
Może czas zmienić technologie? A może pracę...

Many problems with betterbeansbinding - one solution :)

If your binding expressions contain errors or data sources are not available you can get several warnings from EL resolver. But no one of BBB developers thought about good debbuging feedback in such situations. All you get are some of these

[sourcecode type="java"]

2010-07-17 14:10:24 org.jdesktop.beansbinding.util.logging.Logger log
WARNING: isReadable(): expression is unresolvable

2010-07-17 14:10:24 org.jdesktop.beansbinding.util.logging.Logger log
WARNING: updateCache(): expression is unresolvable

2010-07-17 14:10:26 org.jdesktop.beansbinding.util.logging.Logger log
WARNING: isWriteable(): expression is unresolvable

[/sourcecode]

But where? In which class? What binding expression? Damn it! How could I work with this tool?!

I've made very simple changes in CLProperty class of BBB src code. One of them

[sourcecode type="java"]

logger.warning("updateCache(): expression is unresolvable: " +
expression + " for source " + source);

[/sourcecode]

Simple, huh? Now I get

[sourcecode type="java"]

2010-07-17 14:27:10 org.jdesktop.beansbinding.util.logging.Logger log
WARNING: updateCache(): expression is unresolvable: ValueExpression[${rootModel.currentRouteTemplate.inRoutePointTemplates}] for source pl.autoguard.ac21.ptir.mvc.view.TransportRouteView[,0,0,856x612,invalid...

[/sourcecode]

Now I can clearly see that ${rootModel.currentRouteTemplate.inRoutePointTemplates} expression failed for visual element in pl.autoguard.ac21.ptir.mvc.view.TransportRouteView class.

Downloads

Altered ELProperty class.

Altered betterbeansbinding-core-1.3.0b1.jar and betterbeansbinding-core-1.3.0b1.pom (note version 1.3.0b1). This jar should be used instead 1.3.0 version. Update your dependencies today! :)

I po Javarsovii...

Powiem Wam, że myślami ciągle krążę wokół sobotniej konferencji. Rozmach z jakim udało nam się zrobić Javarsovię 2010 przerósł moje oczekiwania. Miało być 500 osób - taką informację przedstawialiśmy sponsorom. A tymczasem przybyło ponad 650. Powstrzymam się od podsumowań szczegółowych. Uczynili to już moi kompani z Kapituły, m.in. Łukasz. Chciałbym jednak podziękować uczestnikom - za ilość przybyłych osób i wspaniałą atmosferę. W piątek wieczorem było cicho i monotonnie, kiedy szykowaliśmy stanowiska, stoły oraz 600 toreb z materiałami :) . Ale w  sobotę sale tętniły życiem i świetnym humorem odwiedzających.

Drugie podziękowania idą do sponsorów. Inaczej byśmy się nie spotkali. Przytoczę tu ich wszystkich

• Sponsorzy platynowi: Javart, IBM


• Sponsorzy złoci: Google, Microsoft, Azul Systems, Oracle


• Sponsorzy srebrni: Adobe, TouK, ITKontrakt, e-point, tieto


• Sponsorzy: Sages, Javatech


• Partnerzy: iStream, SoftwareMill, Helion, OVH.pl, Sun Learning Services Polska


• Patroni medialni: DobreProgramy.pl, Radio Kampus

Bardzo Wam dziękujemy i do zobaczenia na Warsjavie na jesieni oraz na Javarsovia 2011, za rok :-)

Javarsovia 2010 za kilka godzin

Niedawno wróciłem z Centrum Konferencyjnego, gdzie przygotowywaliśmy materiały i sale na konferencję. Mamy 12 dzielnych wolontariuszy, którzy prawie wszyscy do końca ciężko pracowali, aby przytować imprezę.

Przygotowania trwały pół roku, więc jest to owoc ciężkiej pracy wszystkich członków Kapituły. Już się nie mogę doczekać :) więc jeszcze tylko wydrukuję ostateczne listy potwierdzonych i idę spać :)

InetAddress.isReachable() jest do bani

Napisałem mały program testujący czy klient "widzi" prawidłowo adres i porty naszego serwera aplikacyjnego. Zdarza się, że Firewalle klientów skutecznie blokują łączność.

Zależało mi, aby w pierwszym kroku "spingować" hosta. Niestety wczoraj odkryliśmy buga, bo polegałem na metodzie InetAddress.isReachable(). Tymczasem sposób jest do chrzanu, bo implementacja nie pinguje a odpytuje usługę echo, która stoi na porcie 7. Wielu adminów blokuje tego typu usługi, starając się maksymalnie uszczelnić serwery. U nas w firmie też i dlatego nasi klienci dostawali informację, że istnieje brak łączności z jednym z serwerów.

Nie dostarczę dzisiaj rozwiązania, z braku czasu, ale wrócę do tematu kiedyś.
Poniżej wadliwy kod:

[sourcecode type="java"]

final String host = "zdanek.ostrejezyki.pl";
final int timeOut = 3000;

final boolean status = InetAddress.getByName(host).isReachable(timeOut);

if (status == false) {
throw new IOException("Brak lacznosci z " + host);
}

[/sourcecode]

Zero Cobertura coverage

Recently I had zero code coverage during tests. I had a maven2 project (under maven 1.0.9), with default cobertura version, which was 1.9.

All reports were generated normally except all code coverage was zero (0).



The reason was somehow buggy cobertura version 1.9.
After I put cobertura-maven-plugin configuration into my pom.xml specifying cobertura version 2.4

[sourcecode language="xml"]

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<version>2.4</version>
</plugin>

[/sourcecode]

all went well and finally I had my non-zero coverage :D



(Edit: I've added some pretty screenshots :])

W końcu logować z IF (isDebugEnabled()) czy nie?!

Ostatnio staram się pisać małe metody, w imię czytelności kodu. W związku z tym każda dodatkowa linijka zwiększa objętość metody. W malutkich metodach jedna linia to nawet kilkadziesiąt procent objętości :) A co z logowaniem informacji debugujących? Zgodnie z zaleceniami autora Log4j (bo tego loggera zazwyczaj używam), przed zalogowaniem debug() powinno się sprawdzić czy ten poziom jest włączony, aby niepotrzebnie nie tracić czasu procesora na inicjalizowanie stringa do zalogowania. Ceki Gülcü, autor Log4j, w 2002 przekonywał, że sprawdzanie IFem poziomu na PII 233MHz zajmuje nanosekundy, co stanowi mały narzut. Rzeczywiście. A co, gdyby w imię czytelności kodu zrezygnować z tego sprawdzania? Co się wówczas stanie? Ile czasu stracimy? I czy mimo wyłączonego logowania niepotrzebnie wiadomość będzie przetwarzana wewnątrz loggera?

Otóż, oba popularne loggery Log4j i java.utils.Logging sprawdzają czy dany poziom jest włączony i oczywiście nie logują komunikatu, jeśli nie pasuje do poziomu. W takim razie jedynym istotnym problemem jest czas konstruowania wiadomości do zalogowania. Zazwyczaj jest to operacja sklejania kilku stringów, bo chcemy zalogować jakąś operacje np. z jej parametrami. Warto przy tym zauważyć, że czasy kiedy "jakiś string" + "inny" powodowało kilka wywołań konstruktora String(). Od javy 1.5 (lub wcześniej, bo nie wiem) , sklejanie stringów zawsze jest zastępowane StringBuilderem, a więc jest bardzo efektywne. W związku z tym, każdorazowo należy rozważyć czy dany string, który chcemy zalogować jest złożony czy nie. Jeśli nie, to moim zdaniem nie warto stosować IFów, tylko bezwzględnie pchać go loggera.

A teraz konkretne miary, jako, że jestem inżynierem. Test wykonany na procku dual core 2.66GHz, czyli rząd wielkości szybszy od twórcy Log4j. Dzisiaj uważany za przeciętnie dobry sprzęt.
Napisałem program, który 100 000 razy loguje wiadomość, przy wyłączonym debugowaniu. Przy czym w pierwszym teście odbija się od sprawdzenia IFem czy włączone jest debugowanie, a w drugim wchodzi do środka metody logującej. Logowany string to

"Wiadomosc testowa, index " + i + " i jeszcze string"

Mamy tu 3 operacjie StringBuilder.add(), przy czym dla int i jest najbardziej kosztowna, bo i jest od razu zamieniane na string. Wynik:

Test logow bez wlaczonego debuga, ze sprawdzaniem IF
Czas 0ms
Test logow bez wlaczonego debuga, bez sprawdzania IF
Czas 93ms

0 ms oznacza rzeczywiście submilisekundowe czasy sprawdzania czy poziom to DEBUG. 93 ms w rozłożeniu na 100 tyś. wywołań daje nam 93 ns (nano sekund!) na sklejanie. Dodam na koniec, że zaskoczony wynikiem podejrzewałem mocną optymalizację ze strony JVM, czego nie da się wykluczyć, ale drugi test z wielokrotnym powtórzeniem logowanej wiadomości (czyli rezygnacja z pętli) dało również submilisekundowe wyniki. Wkleiłem setkę razy

logger.debug("Wiadomosc testowa, index " + (i++) + " i jeszcze string");

Konkluzja: moim zdaniem przy prostej treści logowanej wiadomości, można zrezygnować ze sprawdzania poziomu logowania na rzecz uproszczenia (wizualnego) kodu.

Źródełko:

[sourcecode language="java"]
package pl.ostrejezyki.zdanek;

import org.apache.log4j.ConsoleAppender;
import org.apache.log4j.Level;
import org.apache.log4j.Logger;

public class LoggingEffectivenessTests {

private static Logger logger = Logger.getLogger(LoggingEffectivenessTests.class);

public static void main(String[] args) {

initLog4j();

testCheckingIfDebugIsEnabled();
testWithoutCheckingIfDebugIsEnabled();

}

private static void testWithoutCheckingIfDebugIsEnabled() {
long start;
long stop;
System.out.println("Test logow bez wlaczonego debuga, bez sprawdzania IF");

start = System.currentTimeMillis();
for (int i = 0; i &lt; 100000; i++) {
logger.debug("Wiadomosc testowa, index " + i + " i jeszcze string");
}
stop = System.currentTimeMillis();

System.out.println("Czas " + (stop - start) + "ms");
}

private static void testCheckingIfDebugIsEnabled() {
System.out.println("Test logow bez wlaczonego debuga, ze sprawdzaniem IF");

long start = System.currentTimeMillis();
for (int i = 0; i &lt; 100000; i++) {
if (logger.isDebugEnabled()) {
throw new IllegalStateException("Debug wlaczony, a powinien byc wylaczony");
}
}
long stop = System.currentTimeMillis();

System.out.println("Czas " + (stop - start) + "ms");
}

private static void initLog4j() {
Logger l = Logger.getRootLogger();
ConsoleAppender ca = new ConsoleAppender();
l.addAppender(ca);
l.setLevel(Level.ERROR);
}
}
[/sourcecode]

"Cannot allocate memory" while compiling project with maven

While compiling my project with Maven I got sometimes on my Linux (Gentoo actually) box the following error

[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error reading assembly descriptors: Error reading descriptor at: /var/www/app_src/src/main/assembly/package.xml: Cannot run program "env": java.io.IOException: error=12, Cannot allocate memory

This was caused by not enough amount of swap memory on linux. After increasing to double size of physical memory all problems are gone.

I was inspired by this entry of Hudson Wiki.

Netbeans 6.7 released!

Finally Netbeans 6.7 has been released a few days after Eclipse Galileo. You can see a quick review of new cool features at release information page.
Changes I'm interested most are better Maven integration, Hudson services integration, Platform enhancements (unpublished Platform 6.7 features page) and better performance.

Wciąganie dumpów PostgreSQL z COPY zamiast INSERT

Dzisiaj czas jakiś walczyłem z dumpami Postgresowymi (wytworzonymi przez pg_dump), w których dane były umieszczone w postaci COPY.
Niestety cholerny pg_restore nie umie wciągnąć takich plików. Wykonywanie ich z linii komend (psql -f nazwa_pliku) lub z PgAdmina też nic nie dało.

Dla uściślenia fragment takiego dumpa wygląda tak:

COPY "acAclUserModules" ("AclId", "TargetId", "UserId", "AclUserModuleVersionTs",   "TransactionId", "LastChangeOwner", "AclUserModuleDeleted") FROM stdin;
809    23    1    2009-04-28 13:03:22.661+00    \N    2    2008-12-05 02:15:38.214436+00
810    56    1    2009-04-28 13:03:22.661+00    \N    2    2008-12-05 02:15:38.214436+00
811    29    1    2009-04-28 13:03:22.661+00    \N    2    2008-12-05 02:15:38.214436+00
\.

Oprócz komendy COPY zamiast INSERT, charakterystyczne jest źródło danych - stdin. Czyli wejście standardowe klawiatura lub plik, jeśli go przekierować. I właśnie takie jest rozwiązanie problemu

psql -d baza_danych -U user < plik_z_dumpem.sql

Do interpretera PostgreSQL jest przekierowywana zawartość pliku, tj. na jego wejście standardowe. I w ten sposób wciągamy dumpy z COPY zamiast INSERT.

Nadmienię tylko, że oczywiście tworząc dumpa mamy możliwość wyboru formatu wstawiania danych, czy COPY czy INSERT. Odsyłam do dokumentacji pg_dump. Musicie tylko zdawać sobie sprawę, że wersja z COPY jest dużo szybsza, ale za to nie można jej załadować z wygodnego w użyciu PgAdmina.

Polecam artykuł źródłowy.

Przyśpiedzanie ładowania testowego Netbeans Platform

Dużym problemem podczas tworzenia pluginów Netbeans jest bardzo długi czas ładowania testowej platformy. Przyczyną są wszystkie dodatkowe moduły, które są zainstalowane. Można zmniejszyć liczbę ładowanych modułów o te, które nie są nam potrzebne do testowania naszego pluginu. W zależności od tego czy tworzone moduły uruchamiamy oddzielnie, czy może razem spięte w Module Suite, proponuję dwa rozwiązania.

Dla pojedynczych modułów, po uruchomieniu Netbeans z naszym pluginem, otwieramy listę pluginów i wyłączamy jak leci wszystko po kolei, co tylko nie jest nam potrzebne. Po następnym uruchomieniu Nb będzie ładował się błyskawicznie. Ale, uwaga, zrobienie clean na projekcie kasuje nam wszystkie ustawienia...

Druga metoda jest trwalsza, ale tylko dla Module Suite. Klikamy prawym na naszym Suite i z properties wybieramy libraries. Tam odznaczamy wszystko prócz wymaganych zależności, w tym na pewno zostawiamy klastry platform9 i nb6.5 (obie wersje zależą od wersji Nb).

Ponieważ pozostawione moduły mają zależności do wyłączonych, podczas odpalania Nb zapłacze, że czegoś mu brakuje, ale wystarczy wcisnąć magiczny przycisk i popsute moduły zostaną wyłączone. Czas ładowania takiego Netbeansa to ok 3-4sek. Można jeszcze powyłączać poszczególne pluginy wewnątrz klastrów.

Zwróćcie uwagę, że wszystko co zaznaczycie/odznaczycie zostanie zapisane w pliku platform.properies sekcji Important files.

Sonar nareszcie pod PostgreSQL

Sonar to bardzo złożone oprogramowanie do śledzenia jakości kodu w projekcie. Do tej pory nie można go było postawić używając Postgresa jako bazy przechowującej dane.
Dopiero programista niezwiązany z teamem Sonara postanowił dopisać brakujące wsparcie oraz rozwiązać kilka problemów kompatybilności typów bazodanowych. Z niecierpliwością śledziłem kolejne uaktualnienia bug reporta zgłoszonego przez tego programistę, aż ostanio pojawiło się fixed. I o to jest! Nowa wersja Sonara 1.9 zawiera poprawki, które pozwalają na zainstalowanie oprogramowania z bazą w Postgresie. W końcu.

How to attach an external jar without wrapping it

Netbeans Platform creators recommend wrapping all external JARs into dedicated module. I don't want to. I just want to include it in my module. The way to do it (described here) is to put all needed jars in release/modules/ext folder and adding some extra XML to project.xml

<class-path-extension>
    <runtime-relative-path>ext/hexedit.jar</runtime-relative-path>          
    <binary-origin>release/modules/ext/hexedit.jar</binary-origin>
</class-path-extension>

Repeat this section for every jar put in ...ext folder.
Immediately you should see them in Libraries folder of you Project's view.

New Netbeans Plugin on the way

I'm during exploring Netbeans Platform architecture. I like it very much. As I already have a Netbeans Platform Certified Associate certificate, I plan to gain higher level Netbeans Certified Engineer.

To achieve that I have to write a Netbeans Platform plugin. It will be a IM client with various awesome features ;) My plans were commented by Geertjan Wielenga (Netbeans Documentation and Tutorials master writer) whom I met personally. Geertjan said that my plugin would qualified me as a Certified Engineer. Awesome! :D

So I'm developing it right now, at 1:20am as this is the only time when I don't have to look after my children :)

I plan to put some early screenshots as soon as there will be something good to show.

Crystal Reports java viewer JNDI problem

I hate Crystal Reports. We use CR XI and it really sucks. Crystal Reports java library has some awful bugs.

When report viewer is loading there's some output to stdout:

Crystal Report Viewer 11.8.4.1197
java.vendor = Sun Microsystems Inc.
java.version = 1.6.0_10
os.name = Windows XP
os.version = 5.1
os.arch = x86

Why? Because inside CR classes there's a direct output to std out and it sucks. But it's a minor problem.

The worst bug is inside database connection layer, somewhere very deep inside CR java lib. Under an unknown condition sometimes it throws some exceptions with "error finding JNDI name" message. It happens while "switching database". If you don't know what's this, try to dig the net.

The problem is that the reason cannot be defined. The same report sometimes causes this error to appear while another invocation causes nothing bad to happen and the report displays properly.

Workaround

Did I mentioned that Crystal Reports sucks? Oh, yes. As I wrote repeating invocation of a report causes it to display properly. So after two days of debugging and digging throught the Internet with no solution I came to stupid but successful idea.  Repeat tables switching until no error appears. The process doesn't take too long. It always took only two loops to successful switch. SWITCH_TABLE_RETRIES is limit of tries (mine is set to 3 and it works well).

boolean successSwitch = false;
//Update old table in the report with the new table.
for (int j = 0; j < SWITCH_TABLE_RETRIES; j++) {
    if (successSwitch) {
        if (j > 1 && Logger.getLogger(AbstractReport.class).isDebugEnabled()) {
            Logger.getLogger(AbstractReport.class).debug("Switch tables after tries: " + j);
        }
        break ;
    }

    try {
        databaseController.setTableLocation(t, tables.getTable(i));
        successSwitch = true;
    } catch (final Throwable th) {
        //if it's the last try as we failed
        if (j + 1 == SWITCH_TABLE_RETRIES) {
            Logger.getLogger(AbstractReport.class).error("Switch tables error " + th.getMessage());
        }
    }
}

There's another bug discovered by some guy and another weird solution.

CR sux :) The end.

And some polish phrases to be indexed by google and help my colleagues to solve the problem.

Błąd podczas znajdowania nazwy JNDI
Problem z Crystal Reports XI
Przeglądarka
Błąd wyświetlania raportu, raportów

Java performance: Strings

Here's a short report about different Strings concatenation methods I performed.

Strings joining is very often repeated operation.

String str1 = "Mary had ";
String str2 = "a little ";

String finalStr = str1 + str2 + " lamb";

Did you know that creating finalStr will cost you 3 String object creations? Maybe it's somehow optimized inside JVM but still takes very long time and resources. The solution is to use StringBuffer (synchronized) or StringBuilder (not synchronized). Difference between StringBuffer and StringBuilder is that StringBuffer is thread-safe which means that finalString could be assembled by few concurrent threads. But if you don't need multithreaded string concatenating (which is the most often case!) use StringBuilder.

Below is the time comparison of three concatenation methods. First I joined 10 strings (often case) and then I checked work time for 1000 strings which will point out sharply performace differences. (Time is given in microseconds)

10 strings

+ concatenation: 126us
StringBuffer: 23us
StringBuilder: 11us

1000 strings

+ concatenation: 11810us (11.81ms)
StringBuffer: 253us
StringBuilder: 123us

Conclusion:
Use StringBuilder!

Paralell port programming under Java (Windows XP)

There's been a lot of neat articles. So I won't repeat this topic again. There's very handy Communications API by sun. But while serial ports worked as a charm I had troubles with paralell port. I couldn't write any byte into LPT port. I've searched the net and I've found an important notice from Paul J. Perrone, a java programmer, which I will cite here because it can disappear in the future from cited forum.

"The OS and
driver software must cleary require that the status input lines be
broadcasting signals that indicate the external device is OK (...)


After some more tinkering, the trick was to tie the parallel port
status lines 10 & 11 (Ack and Busy) to low/ground and lines 12, 13, &
15 (paper out, select, & error) to high/5V. This should be done
through the output of a buffer chip though. I also tied lines 18-25 to
low/ground."

The point is that driver must be shure that there's a plenty of paper, "printer" is ready to go, there's no error... All these informations are provided by special status lines, mentioned above. So I did all the soldering. And provided external +5V for proper high states. And well... it didn't work... :) Maybe it will for you.

So I dug and finally I've found a solution for Windows XP. Sorry, this time not for Linux. The problem is that port connection is hardware and OS dependent, so every library must have some kind of JNI library with proper DLL or other native lib.

Library that worked for me can be obtained at http://www.hytherion.com/beattidp/comput/pport.htm I must confess that all the soldering from citation above left in my LPT connector. I'm sure that's not necessary to put some "config" bits on all these state inputs.

Best regards, and enjoy parallel port programming!

Installing Debian on Neo1973

I'm just installing Debian on Neo1973 phone and I found some hard points to solve. So I decided to do some notes how to do it. It could be useful for others.

Installing HowTo is under http://wiki.debian.org/DebianOnNeo1973 . According to it, we should run

./installDebianOnNeo.sh all

but suddenly, due to a bug in debian security package, it fails with an error

Can't find keyring debian-archive-keyring.gpg

After minutes of digging I found solution. A debian stage calls cdebootstrap-static and it can take missing pgp file as an argument, so you need to download it from the net (or suck from own PC's debian installation), I found it on

http://www.inf.ufpr.br/vioga05/var/usr/share/keyrings/debian-archive-keyring.gpg

Put this file to /tmp dir and modify line of cdebootstrap-static call

cdebootstrap-static --allow-unauthenticated --flavour minimal --keyring=/tmp/debian-archive-keyring.gpg --include=$CDEBOOTS...

I assume that you did ./installDebianOnNeo.sh all before. Now run

./installDebianOnNeo.sh debian

The installation will go further but fails again with unmet dependecies of libcaca0 and libcucul0. Due to fact that apt is set to unstable distribution there are some dependecies probles. Solution is to switch to testing, then install libcaca0 and libcucul0 and then switch back to unstable. To do this, switch to prepared debian root on SD card with

chroot /mnt/debian /bin/sh

then edit /etc/apt/sources.list and change first entry from ustable to testing. Then refresh packages list with

apt-get update

install missing libraries

apt-get install libcaca0 libcucul0

Exit chroot (with exit command :) ) and go with the remaining stages

./installDebianOnNeo.sh apt fso configuration kernel unmount

After that, follow the rest of main debian on Neo1973 manual.

Voila! Enjoy Debian on Neo1973 :D

A problem with HibernateTools of JBossTools on Eclipse Ganymede

Latest version of Hibernate Tools 3.2.3ga is broken. It's using nonexistent class SWTResourceUtil which existed in Eclipse Europa. Opening Hibernate views ends with

Java.lang.NoClassDefFoundError: org/eclipse/ui/internal/util/SWTResourceUtil at prg.hibernate.eclipse.console.workbench.xpl.AnyAdaptableLabelProvider.getImage(AnyAdaptableLabelProvider.java:166) at org.eclipse.jface.viewers.WrappedViewerLabelProvider.getImage(WrappedViewerLabelProvider.java:117) at org.eclipse.jface.viewers.WrappedViewerLabelProvider.update(WrappedViewerLabelProvider.java:165) at org.eclipse.jface.viewers.ViewerColumn.refresh(ViewerColumn.java:145) at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:932) at org.eclipse.jface.viewers.AbstractTreeViewer$UpdateItemSafeRunnable.run(AbstractTreeViewer.java:102) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
and more...

Some developers are now working for a fix but for now you can patch it by yourself. Find plugin org.eclipse.ui.workbench_xxxx.jar of previous version of Eclipse (3.3 for example) and open it with some ZIP extractor. Copy class org/eclipse/ui/internal/util/SWTResourceUtil.class to current plugin jar of your Ganymede installation and restart Eclipse.

Some say that Hibernate configuration plugin works slower than in Europa version but who cares as it works at least!(!)
The solution was taken from Hibernate bug report http://opensource.atlassian.com/projects/hibernate/browse/HBX-1068 

Eclipse Europa (3.3) OutOfMemoryError: PermGen space

I like new Eclipse Europa (v.3.3). It has many advatages. It's faster and better and more... My colleague posted good review (Polish only) some time ago so I won't repeat. But there is one stinky thing about Eclipse when one try to work with bigger project... Eclipse Europa suddenly crashes without any error message. The cause: OutOfMemoryError. This damn thing kills all invention as you have to restart Eclipse to continue work. But even with that trick in a pocket one won't go far because it will happen soon again.

How to check whether it is memory error? Find workspace\.metadata directory and open .log file. Then jump to the end and look for stack trace with OutOfMemoryError: PermGen space. That's the cause.

I found many gurus who had very good ideas and theories about memory options that should be passed to greedy Eclipse but not many of them made any impression on Eclipse's memory hunger. So forget about eclipse.ini and it's content. Just modify your shortcut and set something about that

"C:\Program Files\eclipse3.3\eclipse.exe" -vmargs -Xms256m -Xmx952m -XX:MaxPermSize=256m

I run 2GB box at my work. As for weird 952 Megs for maximum memory size. It was chosen throught set of experiments. I found that there's a connection between each argument. If you change Xms param suddenly Xmx becomes invalid (and crashes Eclipse during startup). So do some experiments too with your start params.

My experience is that Eclipse 3.3 never goes beyond 500 Megs of physical memory and 500 Megs of virtual so maybe almost 1 Gig is too much but I never saw OutOfMemoryError again.