Zmiany w NetBeans 6.5 nie tylko w harmonogramie, netbeans.keep.expansion oraz ukryte skarby JDK - jps i jstack

Przez długi okres czasu, od 10 lipca, wersja rozwojowa NetBeans IDE 6.5 była niedostępna, aż dopiero 3 dni temu - 17.07 - pojawiła się długooczekiwana nowiuteńka paczka dystrybucyjna netbeans-trunk-nightly-200807170007.zip (można zauważyć, że ponownie mamy przerwę w dziennych paczkach, bo jest 20.07, a wciąż w repozytorium najnowsza wersja to właśnie z 17.07!). Można, więc przysiąć i posprawdzać jego (nie)doskonałości, jednocześnie "zarabiając" kilka punktów w NetCAT 6.5. Tym razem obiecałem sobie, że przyjrzę się Groovy i Grails, których wsparcie jest nadzwyczaj wychwalane przez użytkowników groovy-grailsowych. Jeśli będzie można połączyć to z pracami wokół Korporacyjnej 5-tki z GlassFish v3 (w którym zagościło OSGi) to dlaczego nie poświęcić temu trochę czasu. Nie ma go wiele, więc jeśli go trwonić, to na rzeczy ciekawe, nieprawdaż?! W tym tonie udało mi się zapoznać z Mastering Grails: Build your first Grails application. Bardzo krótki acz treściwy artykuł prezentujący cechy Grailsów, które sprawiają, że programiści javowi nie muszą spoglądać w stronę Ruby on Rails (RoR). Na chwilę obecną wystarczy poznawania Grailsów, ale pytanie o możliwość integracji z innymi rozwiązaniami, np. opartymi o znaczniki JSP, pozostaje. Może ktoś rzucić trochę światła na kwestię integracji rozwiązań typu JSF z Grails? Czy to w ogóle jest porównywalne? Czy integracja ma rację bytu?

Po uruchomieniu NetBeansa pierwsze zaskoczenie - pojawiła się nowa grafika początkowa (ang. splash screen).

Ładniutki, nieprawdaż? Poza tą niefunkcjonalną zmianą, mamy domyślnie otwarty widok Tasks (Ctrl+6).

Zadania określane są przez znane i lubiane TODO, ale również kilka innych adnotacji (patrz Tools > Options > Miscellaneous > ToDo Tasks).

Przy okazji konfiguracji adnotacji dla zadań pojawiło się jedno z moich ulubionych słówek angielskich - miscellaneous. Jest ono o tyle ulubione, że wielu zapytanych nie wie, jak się poprawnie wymawia to słowo (pomijając, że wielu nie wie o jego istnieniu).

W kontekście domyślnego uruchomienia widoku Tasks, sądzę, że w końcu potraktuję swoje TODO w kodzie poważniej, bo przy każdorazowym uruchomieniu ich liczba z pewnością będzie przypominała o ich istnieniu. Zauważyłem pewną zależność między naszymi przyzwyczajeniami a domyślnymi ustawieniami narzędzi używanych na codzień. Wielu z nas zamiast dostosowywać narzędzie do siebie, dostosowuje siebie do niego. A tu proszę, NetBeans postanowił obdarzyć nas narzędziem, które dba o nasze zadania. Teraz może w końcu baczniej przyjrzę się zadaniom do wykonania (TODO) z jego pomocą. Jeszcze nie zastosowałem się do tych "zaleceń", ale już mi się podobają.

Ciekawostka z grupy NetCAT 6.5, której znajomość z pewnością daje poczucie zaawansowanego użycia NetBeans IDE podczas pracy. Jeśli potrzebujemy zachować stan rozwiniętych węzłów w drzewie (dowolnym, np. w oknie Projects będą to projekty i ich zasoby) to wystarczy...więcej w poniższej wiadomości:

On build 5.5 the Project Window remember the state of the node. while now 6.5 it will collapse to the root if we are going to restart the IDE.

This change was made intentionally (I thought earlier than 5.5, but perhaps not) - the reexpansion of the nodes was slowing down startup.

http://www.netbeans.org/issues/show_bug.cgi?id=55701

You should be able to enable the expansion by adding

-J-Dnetbeans.keep.expansion=true

to your netbeans.conf, but note that this mode is not tested.

Kolejną ciekawostką z programu NetCAT 6.5 jest narzędzie jstack, o którym nie miałem w ogóle świadomości istnienia (!) A narządko bardzo ciekawej funkcjonalności, bo prints Java stack traces of Java threads for a given Java process or core file or a remote debug server, czyli dokładnie to, czego w wielu momentach spowolnienia aplikacji javowej potrzebuję. Ni mniej, ni więcej - narzędzie umożliwia zerbanie danych do analizy prac JVM przez wypisanie sterty wywołań javy dla wybranego procesu, z pliku ze zrzutem pamięci (core) czy zdalnego serwera. Więcej o tym i podobnych narzędziach w NetBeans - How to Generate a Thread Dump. Okazuje się, że poza jstack jest również niejaki StackTrace. Teraz jakikolwiek problem wydajnościowy w Javie nie będzie mi straszny. Przy okazji, z dokumentacji jstack dowiedziałem się o kolejnym, nieznanym mi wcześniej, narzędziu jps, który wypisuje identyfikatory procesów javowych, np.:

 C:\Documents and Settings\jlaskowski 2008-07-18 12:19:33,98
 > C:\apps\java6\bin\jps.exe
 32132 org.eclipse.equinox.launcher_1.0.100.v20080509-1800.jar
 35188 NetworkServerControl
 35684 Main
 37884 Jps
 30228 PELaunch

Teraz wystarczy podłączyć się do wybranego procesu javowego narzędziem jstack, aby rozeznać się w aktualnej sytuacji o stanie JVM (żeby tak prosto było zdiagnozować problemy w polskiej słuzbie zdrowia, o której tyle ostatnio. Gdybym wiedział numer procesu może mógłbym jakoś pomóc. ;-)):

 C:\Documents and Settings\jlaskowski 2008-07-18 12:21:39,67
 > C:\apps\java6\bin\jstack.exe -l 35684
 2008-07-18 12:23:57
 Full thread dump Java HotSpot(TM) Client VM (10.0-b23 mixed mode):

 "Inactive RequestProcessor thread [Was:Default RequestProcessor/org.netbeans.modules.xml.xam.AbstractModelFactory$1]" da
 emon prio=2 tid=0x374a1400 nid=0x8100 in Object.wait() [0x3bb4f000..0x3bb4fc14]
 java.lang.Thread.State: TIMED_WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:950)
    - locked <0x09baa8a0> (a java.lang.Object)

 Locked ownable synchronizers:
    - None
 ...
 "Finalizer" daemon prio=8 tid=0x31377400 nid=0x8a24 in Object.wait() [0x3184f000..0x3184fa94]
 java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
    - locked <0x0549b4e0> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
    at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

 Locked ownable synchronizers:
    - None

 "Reference Handler" daemon prio=10 tid=0x31376400 nid=0x88b8 in Object.wait() [0x3164f000..0x3164fb14]
 java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    at java.lang.Object.wait(Object.java:485)
    at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
    - locked <0x0549aef0> (a java.lang.ref.Reference$Lock)

 Locked ownable synchronizers:
    - None

 "VM Thread" prio=10 tid=0x31373000 nid=0x7654 runnable

 "VM Periodic Task Thread" prio=10 tid=0x3139b400 nid=0x8504 waiting on condition

 JNI global references: 2935

Warto zapoznać się z pełną dokumentacją narzędzi dostarczanych w ramach wybranej JVM, np. dla Sun JDK będzie to JDK Tools and Utilities. Nie wszystkie jednak narzędzia dostępne są na wszystkich platformach systemowych, gdyż narzędzia są dostarczane przez dostawcę JVM dla danej platformy, więc dla IBM JDK będzie to inny zestaw narzędzi, często wykraczający poza możliwości Sun JDK.

I wiadomość z ostatniej chwili w temacie zmian w harmonogramie NetCAT 6.5. Przesunęła się data wydania finalnej wersji NetBeans 6.5. Pojawił się niewielki the two weeks slip in the schedule, o którym pisze Jirka Kovalsky (głównodowodzący programu NetCAT 6.5):

Due to postponed Feature Freeze of PHP and GlassFish v3 support and high number of bugs we are forced to update some important milestones. Accordingly I had to adjust some NetCAT 6.5 dates and the new schedule is already published on the NetCAT 6.5 homepage (http://qa.netbeans.org/processes/cat/65)

Nowa wersja NetBeans IDE 6.5 dopiero 15 października. Jest szansa na wyłapanie większości błędów w nim i nauczeniu się kilku nowych szkieletów programistycznych, których wsparcie dostarcza, np. Grails. Gdybym tak mógł poczytać o integracji Grails z usługami dostarczanymi przez serwer Korporacyjnej 5-tki byłoby wspaniale. W połączeniu z OSGi byłbym w ogóle uszczęśliwiony.