Jak obiecałem już jakiś czas temu, pokażę w jaki sposób można pobrać numer wersji, który umieściłem w pliku MANIFEST.MF pod atrybutem Implementation-Version. Wcześniej jednak, chciałbym zwrócić Waszą uwagę na listę wszystkich dostępnych atrybutów oraz specyfikację klasy Package, z której będę korzystać.

Jeśli nie wiesz, czym dokładnie jest Event Dispatch Thread polecam artykuł Threads and Swing. Daje on niejakie pojęcie o tym co, gdzie, jak i dlaczego działa w Swing‘u tak, a nie inaczej.

Jeśli wiesz już o co chodzi z EDT i rozumiesz, jakie problemy może powodować zmienianie GUI z poziomu wątku innego niż EDT, możesz chcieć zapoznać się z opisem projektu swinghelper opublikowanego na łamach serwisu java.net, a w szczególności z działem Debugging and testing.

Nadawanie numerów wersji kolejnym wydaniom bibliotek, czy też aplikacji z oczywistych względów wydaje się być co najmniej wskazanym. Pozostaje jednak pytanie, jak to robić?

Odpalając niedawno jedną z napisanych przeze mnie niegdyś aplikacji na nowej wersji Javy (JRE 1.6.0_20) zauważyłem, iż nie działa ona prawidłowo. Otóż, niektóre operacje trwały dłużej niż powinny. Po krótkim śledztwie z wykorzystaniem jvisualvm i inspekcją kodu na czele, okazało się, że to używane przeze mnie SwingWorker’y z nieznanych mi przyczyn prawdopodobnie wchodzą sobie w drogę.

Idąc za ciosem, postanowiłem zmajstrować kilka bajerów do projektu Portecle, gdyż jak się okazało, podobnie do KeyTool GUI, z którego do tej pory korzystałem, brakuje pewnych drobiazgów. Zatem, do plików projektu dodałem pliki wykonywalny .exe oraz zapakowałem całość w instalator od NSIS i tak oto powstał nowy projekt: Portecle Installer.

Okazuje się, co jest dla mnie miłym zaskoczeniem, że KeyTool GUI wcale nie umarł. Ukrył się tylko pod innym imieniem 🙂

Portecle, bo tak się nazywa kontynuacja projektu (?), podobnie jak onegdaj KeyTool GUI, jest narzędziem do tworzenia i edycji plikowych magazynów certyfikatów i kluczy. Uogólniając, jest to jakoby nakładka na Javowe keytool.exe.