Dzięki pracy Agnieszki Lewandowskiej Poznański JUG ma również swój kanał w portalu beta.parleys.com w którym możecie znaleźć materiały video z różnych prezentacji.

Jeszcze z zupełnie innej beczki – wspomnieć należy o ogromnym sukcesie zapoczątkowanego przez Jacka Pospychałę kursu przygotowawczego do egzaminu Sun Certfied Java Programmer. Ludzie walili drzwiami i oknami, a o wynikach można poczytać tutaj.

W najbliższej przyszłości czeka nas naprawdę sporo atrakcji o jednej z nich zapewne wszyscy już słyszeli – GeeCON 2010 odbędzie się w Poznaniu! Przygotowania do konferencji idą pełną parą, na stronie pojawiły się już informacje o pierwszych zaproszonych gościach, konferencję objął swym honorowym patronatem prezydent miasta Poznania p. Ryszard Grobelny, firma Adobe zaoferowała swoją pomoc w organizacji konferencji – jeżeli chcecie być na bieżąco warto podsłuchiwać na Twitterze .

Co być może w tej chwili najważniejsze od 6 stycznia organizatorzy czekają na propozycje wystąpień, pełny tekst zaproszenia do udziału można znaleźć na stronie : http://2010.geecon.org/site/cfp. Termin upływa 28 lutego 2010 nie ma więc na co czekać .

Możecie pobrać całość w zipie (gotowe do zaimportowania projekty NetBeansowe) lub gotowe do użycia pliki nbm (w update site wpiszcie : http://grejpfrut.org/examples/vvm-modules/updates.xml).

Tak jak poprzednio zaczniemy od implementacji fabryki tworzącej instancję naszej implementacji ApplicationType.

public class GrejpfrutApplicationTypeProvider extends MainClassApplicationTypeFactory {
@Override
  public ApplicationType createApplicationTypeFor(Application app, Jvm jvm, String mainClass) {
    if (app.isLocalApplication()) {
      return new GrejpfrutApplicationType(app.getPid(), mainClass);
    }
    return null;
  }
}

Warto pamiętać, że w zależności od dostępnych informacji zmienna mainClass nie zawsze musi zawierać nazwę głównej klasy.

W tym konkretnym przykładzie aplikacje grejpfrutowe to takie, które zostały uruchomione lokalnie.

Kolejny krok to nieco więcej pisania, ale dalej nic trudnego.

public class GrejpfrutApplicationType extends ApplicationType {

    protected final int appPID;
    protected final String name;

    public GrejpfrutApplicationType(int appPID, String name) {
        this.appPID = appPID;
        this.name = name;
    }
    @Override
    public String getName() {
        return "Grejpfrut "+name;
    }
    @Override
    public String getVersion() {
        return "blee.bleee";
    }
    @Override
    public String getDescription() {
        return "Application type for Grejpfrut";
    }
    @Override
    public Image getIcon() {
	//używamy tej saame ikonki co w poprzednim przykładzie (patrz poprzedni wpis)
        return Utilities.loadImage(FirstExamplePluginView.IMAGE_PATH, true);
    }
}

Teraz jeszcze zarejestrowanie nowego ApplicationType w klasie Installer (patrz poprzedni post).

public class Installer extends ModuleInstall {
    private static GrejpfrutApplicationTypeProvider INSTANCE = new GrejpfrutApplicationTypeProvider();

    @Override
    public void restored() {
        FirstExamplePluginViewProvider.initialize();
        ApplicationTypeFactory.getDefault().registerProvider(INSTANCE);
    }
    @Override
    public void uninstalled() {
        FirstExamplePluginViewProvider.unregister();
        ApplicationTypeFactory.getDefault().unregisterProvider(INSTANCE);
    }
}

Wprowadźmy jeszcze jedną małą zmianę w FirstExamplePluginViewProvider, dodając jedną nową metodę.

    @Override
    protected boolean supportsViewFor(Application app) {
        if (ApplicationTypeFactory.getApplicationTypeFor(app) instanceof GrejpfrutApplicationType) {
            return true;
        }
        return false;
    }

Stworzona w poprzednim odcinku zakładka będzie się wyświetlała tylko w przypadku gdy zostanie jej przypisany typ GrejpfrutApplicationType.

Czyścimy całość i odpalamy, co się teraz stanie? Jeżeli masz odpalone tylko NetBeans i VisualVM w którym została uruchomiona wtyczka to niczego nie zobaczysz. Dlaczego? Otóż na tyle na ile to rozumiem NetBeansApplicationType i VisualVMApplicationType zostały zarejestrowane przed GrejpfrutApplicationType. VVM przypisuje aplikacji pierwszy ApplicationType który uda mu się do niej dopasować więc nie dochodzi nawet do sprawdzania czy NetBeans i VVM są też grejpfrutami . Uruchom jakiegoś Eclipse’a ;P wtedy na drzewku Applications pojawi się nowy grejpfrut.

To by było na tyle jeżeli napotkacie jakieś ładne stactrace’y bawiąc się Shootoutem i moimi źródełkami dajcie znać.

Jeszcze jedna finalna uwaga – testowałem na platformie w wersji 6.01 więc już dość leciwej.

Potrzebny będzie również kod źródłowy gry Shootout autorstwa Dawida Weissa, orginalna wersja nie pozwalała na osadzenie gry w kontenerach Swingowych, musiałem więc wprowadzić kilka poprawek . Kod źródłowy dostępny jest tutaj. Aby zbudować jar’a wystarczy rozpakować archiwum i w katalogu shootout wydać polecenie: ant jar-netbeans w shootout/build znajdziecie finalnego jar’a.

Po zainstalowaniu Visual VM (można też użyć tego który znajduje się w Waszym JDK) i uruchomieniu NetBeans IDE możemy przystąpić do pracy. W niektórych miejscach korzystałem z wizardów NetBeansowych więc samo spojrzenie w kod tych próbek może nie dać wam pełnego obrazu jak najszybciej dojść do finalnego efektu

Visual VM to aplikacja stworzona w oparciu o NetBeans Paltform, przeglądając zawartość folderu aplikacji możecie natknąć się na charakterystyczne dla aplikacji NBP nazwy plików i katalogów. Zanim zaczniemy właściwą pracę musimy zarejestrować instację platformy NB, która znajduje się w Visual VM. Oprócz standardowych elementów NB są tam również moduły specyficzne dla Visual VM jak np. VisualVM-Application czy VisualVM-Core.

Aby zarejestrować instancje platformy należy wybrać z menu Tools>NetBeans Plaform i dodać nową platformę (przycisk Add Platform) – wskazujemy na katalog w którym został zainstalowany VisualVM

Rejestracja platformy umożliwi nam nie tylko zapewnienie pełnej zgodności z platformą na której uruchamiany będzie plugin, ale pozwoli również na debugowanie i szybkie uruchamianie tworzonego przez nas rozszerzenia w docelowym środowisku.

Tworzymy nowy projekt wybierając File>New Project>NetBeans Modules i z listy o prawej stronie wybrać Module Suite klikamy Next.

W następnym kroku kreatora wpisujemy nazwę projektu i wybieramy platformę w oparciu o którą będziemy rozwijali nasz zestaw modułów. W poprzednich krokach zarejestrowaliśmy instancję należącą do Visual VM i to właśnie ją wybieramy z listy rozwijanej.

Module Suite jest kontenerem dla modułów które są z jakichś względów są ze sobą powiązane, w wyniku naszych działań powstaną dwa moduły: właściwa wtyczka do VisualVM i drugi będący owijką na shootout.jar. Dlaczego tak? Scenariusz jest bardzo prosty wyobraźcie sobie, że została wydana nowa wersja Shooout i chcielibyśmy mieć ją w naszej wtyczce. Po dokonaniu niezbędnych zmian przez nas, użytkownicy wtyczki musieliby ściągać nie tylko nową wersję gry, ale i samą wtyczkę, którą już przecież mają. Aby więc w pełni wykorzystać zalety modułowości każda biblioteka wykorzystywana przez naszą wtyczkę powinna zostać opakowana w pewne dodatkowe informacje, które pozwolą instancji NetBeans Platform na aktualizację tylko tej konkretnej biblioteki.

Czas więc stworzyć Library Wrapper Module dla Shootout.jar. Klikamy File>New Project>NetBeans Module>Library Wrapper Module w pierwszym kroku kreatora trzeba podać ścieżkę do pliku jar, który opakowujemy i do pliku z licencją na której biblioteka jest/ma być udostępniania. W ostatnim kroku kreatora pojawia się pytanie o codebase, wpisujemy com.dawidweiss.shootout.

O czym jeszcze warto wspomnieć, pierwotnie Shootout.jar miał w manifeście ustawiony parameter Main-Class, który wskazywał na klasę posiadającą metodę main w której uruchamiana była gra. Powodowało to, że wtyczka po umieszczeniu w VisualVM nie działała. Wywalenie tego atrybutu z manifestu załatwiło sprawę. Niestety nie znam się na wnętrznościach NetBeans Platform więc nie jestem w stanie tego sobie wytłumaczyć bardziej racjonalnie.

Zależności w formie LWM mogą być deklarowane przez wszystkie moduły wchodzące w skład nadrzędnego Module Suite.

Mamy już jeden moduł, teraz czas przejść do najważniejszej części tego artykułu – tworzenia właściwej wtyczki do VisualVM.

Tworzymy nowy projekt File>New Project>NetBeans Module>Module, moduł powinien zostać dodany do stworzonego wcześniej Module Suite. W kolejnym kroku wpisujemy codebase : org.grejpfrut.vvm, w NetBeans 6.5 wpisanie poprawnego codebase uzupełnia również pozostałe pola formularza.

Kolejny krok to dodanie zależności, w oknie Projects klikamy prawym na węzeł reprezentujący moduł i wybieramy Properties. Następnie zakładka Libraries musimy mieć zadeklarowane następujące zależności: Module System API, shootout, Utilities API, VisualVM-Application i VisualVM-Core.

W oknie Projects klikamy prawym przyciskiem myszy na węzeł reprezentujący stworzony przed chwilą moduł i wybieramy New>Module Installer. Stworzona klasa Installer i jej dwie metody restored i uninstalled umożliwiają nam wpięcie się w cykl życia tworzonej właśnie wtyczki. Kod z metody restored jest wykonywany w chwili załadowania modułu, jest to najwłaściwsze miejsce aby zarejestrować klasy implementujące rozszerzenia. Natomiast metoda uninstalled jest wywoływana w momentcie gdy moduł jest usuwany ze środowiska lub gdy jest ono wyłączane.

public class Installer extends ModuleInstall {
    @Override
    public void restored() {
        FirstExamplePluginViewProvider.initialize();
    }
    @Override
    public void uninstalled() {
        FirstExamplePluginViewProvider.unregister();
    }
}

W mojej prezentacji z NetBeans Day możecie znaleźć krótkie omówienie tego co można rozszerzyć w VisualVM, więcej o tym piszę Geertjan w
dokumentacji VisualVM i na swoim blogu. FirstExamplePlugin będzie tworzył dodatkową zakładką, którą użytkownicy będą mogli zobaczyć po połączeniu się do jakiegoś JVMa. W zakładce tej będą się działy rzeczy różne .

Należy teraz stworzyć klasę FirstExamplePluginViewProvider, jak sugeruje nazwa, klasa ta będzie odpowiedzialna za “produkcję” instancji klasy FirstExamplePluginView.

class FirstExamplePluginViewProvider extends DataSourceViewProvider {
    //prosty singleton
    private static DataSourceViewProvider instance = new FirstExamplePluginViewProvider();

    static void initialize() {
        //rejestrujemy instancję FirstExamplePluginViewProvider w zarządcy widoków
        DataSourceViewsManager.sharedInstance().addViewProvider(instance, Application.class);
    }

    static void unregister() {
        //wyrejestrowujemy instancję FirstExamplePluginViewProvider w zarządcy widoków
	//metoda jest wywoływana podczas odinstalowywania modułu i wyłączania środowiska
        DataSourceViewsManager.sharedInstance().removeViewProvider(instance);
    }

    @Override
    protected DataSourceView createView(Application app) {
        //tworzy instancję widoku
        return new FirstExamplePluginView(app);
    }
}

Klasa ta to prosty singleton, który w czasie inicjalizacji modułu (initialize) dodaje do DataSourceViewManager’a swoją instancję. Najważniejszą metodą w tej klasie jest createView, która to tworzy naszą zakładkę.

Kopiując poniższy kod należy pamiętać o wskazaniu poprawnej ścieżki do ikonki wyświetlanej w etykiecie zakładki:
org/grejpfrut/vvmnbd/example/grejpfrut.png – szczegóły będą widoczne w źródłach.

public class FirstExamplePluginView extends DataSourceView {

    private DataViewComponent dvc;

    //sciezka do ikony, ktora bedzie wyswietlana w zakładce zakładki
    public final static String IMAGE_PATH = "org/grejpfrut/vvmnbd/example/grejpfrut.png";

    public FirstExamplePluginView(Application app) {
        //tytuł zakładki i ikona
        super(app, "Java IDE wars plugin", new ImageIcon(Utilities.loadImage(IMAGE_PATH)).getImage(), 3, true);
    }

    @Override
    protected DataViewComponent createComponent() {
    	//tworzenie elementów widoku
        JEditorPane generalDataArea = new JEditorPane();
        generalDataArea.setBorder(BorderFactory.createEmptyBorder(4, 8, 4, 8));

        JPanel details1Panel = new JPanel(new BorderLayout());
        ShootoutBoard board = new ShootoutBoard(new ShootoutUtilities().getEnemyFactory(), details1Panel);
        details1Panel.add(board, BorderLayout.CENTER);
        details1Panel.setBackground(Color.GRAY);
        details1Panel.setCursor(Cursor.getPredefinedCursor(Cursor.CROSSHAIR_CURSOR));

	//osadzanie stworzonych kontrolek w kontenerze VisualVM
        DataViewComponent.MasterView masterView = new DataViewComponent.MasterView("Java IDE wars plugin", null, generalDataArea);
	//konfiguracja widoku
        DataViewComponent.MasterViewConfiguration masterViewConfiguration = new DataViewComponent.MasterViewConfiguration(false);

	//tworzymy właściwy komponent, który bedzie wyswietlany w VVM
        dvc = new DataViewComponent(masterView, masterViewConfiguration);

	//tworzymy panel z planszą gry
        DataViewComponent.DetailsView details = new DataViewComponent.DetailsView("", "Detale tego okienka", 10, details1Panel, null);
	//umieszczamy go w odpowiednim miejscu
        dvc.addDetailsView(details, DataViewComponent.TOP_LEFT);
	//gra ma być domyślnie ukryta
        dvc.hideDetailsArea(DataViewComponent.TOP_LEFT);
        return dvc;
    }
}

Po uzupełnieniu importów, możemy uruchomić nasz plugin aby tego dokonać należy w oknie Projects kliknąć prawym na węzeł reprezentujący nasz Module Suite i wybrać “Run” lub “Debug”. NetBeans uruchomi teraz nasz plugin w platformie która wybraliśmy dla naszych modułów. Teraz klikamy w dowolny proces JVM, który jest wyświetlany na drzewku Applications i powinna się naszym oczom ukazać zakładka z grejpfrutem, po kliknięciu “Details” powinna już rozpocząć się strzelanina .

Kompletne źródła już wkrótce, po tym jak skończe drugą cześć “Własny ApplicationType”.

Wszystko oparte na serii artykułów Getting Started Extending VisualVM autorstwa Geertjana Wielengi.

Kilka słów podsumowania, z informacji które udało mi się zebrać wynika, że obie edycje odwiedziło w sumie około 140 osób (80 Gdańsk, około 60 w Poznaniu). Kurcze, wydaje się, że nie codzień jest okazja posłuchać tak świetnych specjalistów, ale wychodzi na to, że dobry poziom merytoryczny to nie wszystko…

Niestety nie byłem w stanie obejrzeć wszystkich poznańskich prezentacji, ominął mnie występ Geertjana Wielengi który omawiał podstawy NetBeans Platform. Nie mogę też za wiele powiedzieć o prezentacji Adam Kędziory bo ze względu na różne organizacyjne bzdury musiałem siedzieć przed salą. Bardzo podobała mi się prezentacja Toni’ego Epple, który pokazywał przykłady produkcyjnych wdrożeń NBPlatform. Jestem ciekaw czy ktoś próbował portować aplikację Eclipse RCP na NBPlatform, mechanizmy w środku działają na podobnej zasadzie, ale w przypadku zaawansowanych kontrolek może nie być różowo. Ogromne wrażenie zrobił na mnie Adam Bien (rzeczywiście trzech Adamów na jednej konferencji to całkiem sporo ) generalnie jestem umiarkowanym fanem live-coding, ale poczucie humoru i dynamizm z jakim AB przeprowadził słuchaczy przez arkana NetBeans 6.5 jest godne podziwu.

Tyle merytorycznie… chciałem podziękować chłopakom ze Szczecin JUG, którzy przejechali całkiem spory kawałek żeby się w Poznaniu pojawić, mam nadzieje, że piwo w Stajence wypaliło . Były też osoby z Rzeszowa, Aten no i oczywiście z Poznania (najwięcej z UAM). Oddzielne podziękowania muszą powędrować do koła naukowego studentów informatyki UAM, bez was chłopaki byłaby totalna klapa.

O NetBeans Day napisało już kilka osób:

• Geerthan Wielenga – “Poznan & Gdansk: NetBeans Day, Poland”
• Toni Epple – “NetBeans Days in Gdansk and Poznan” (Tony zrobił również kilka świetnych zdjęć, link dostępny w jego wpisie)
• Adam Bien – opisał swoje wrażenia tutaj i tutaj
• Jacek Laskowski – “Wrażenia po NetBeans Day 2008 w Gdańsku”
• Łukasz Stachowiak – “Po NetBeans day Poznań”
• Leszek Gruchała – “Wrażenia z NetBeans Day w Poznaniu” – (dzięki za słowa krytyki, postaram się coś zrobić z moją “żywością” )
• Miroslav Kopecky – “Poland – NetBeans Day Success”

Miłe jest też to, że nasza inicjatywa została zauważona w portalu java.net

.

Dzięki staraniom Macieja Biłasa, Toniego Epple i Bartka Łopatki Poznań NetBeans Day zostało całkiem nieźle udokumentowane, dzięki.

Geertjan Wielenga opowiada o podstawach NetBeans Platform

Adam Kędziora mówił o swoich doświadczeniach w tworzeniu aplikacji w NetBeans Platform, oraz o uczestnictwie w NetBeans Innovators Grant.

Krótka przerwa na poczęstunek, soczek z grejpfruta, paluszki i ciastka.

Autor tego skromnego bloga, w tle logo Poznań JUG.

Karol Harezlak przygotowuje się do swojej prezentacji.

A tu już Karol w akcji.

Geertjan z pamiątkowym kubkiem Poznań JUG.

Toni w mówił o przenoszeniu istniejących aplikacji na NetBeans Platform.

Pan Epple również otrzymał pamiątkowy kubek prelegenta .

Adam Bien według większości uczestników najbardziej interesująca prezentacja konferencji.

Od lewej: Karol Harezlak, Geertjan Wielenga, Łukasz Stachowiak, Toni Epple.

Poznań Eclipse Demo Camp odbędzie się 21 i 28 listopada, o godzinie 18:30, w sali nr 13. Centrum Wykładowego Politechniki Poznańskiej (skrzyżowanie ulic Piotrowo i Berdychowo).

Program spotkań jest następujący:

21. listopada

Eclipse Way – czyli w jaki sposób organizowac prace wokół projektu open source
- Krzysztof Daniel (IBM, PP), Bartosz Michalik (IBM, PUT)

g-Eclipse: Access the Power of the Grid – przykład projektu eclipse’owego
- Katarzyna Bylec (PCSS, GIK), Mateusz Pabiś (PCSS)

28. listopada

How big fun OSGI can be? – Jacek Pospychała (IBM)

UC Workbench – przyklad aplikacji RCP – Łukasz Olek (IBM, PP)

Po wykładach przewidziana jest dyskusja będzie się też czego się napić i co zjeść

O drugim spotkaniu możecie poczytać na stronach JUG’a, odbędzie się ono 23 kwietnia o godzinie 18:30 w sali nr 4 budynku PCSS przy ul. Zwierzynieckiej 20 (Poznań). Temat spotkania to : “Zróbmy to szybko” czyli Groovy i Grails w akcji a prowadzący… hmmm .

Przetestowałem MJ na małym programiku konsolowym, co trzeba zrobić, żeby to zadziałało? Po pierwsze musimy stworzyć nowy MaintainJ Instrumentation Project, przejście wizarda dla tego projektu nie wymaga czarnego pasa . Wybieramy projekt którego dotyczyć ma śledzenie, potem pakiet, a w przypadku J2SE wybieramy główną klasę projektu i… gotowe (no prawie:)). Mamy stworzony projekcik MJ’owy, łatwo też zauważyć, że do docelowego projektu została dodany “charakter/nature” AspectJ’owy. W przypadku aplikacji swingowych/J2EE przed rozpoczęciem działania programu jesteśmy pytani o to czy zacząć logowanie działania. W przypadku aplikacji konsolowej autorzy zalecają włączenie tego od raz (jest to opisane tutaj pod koniec strony). Gdy odpaliłem program (jako AspectJ/Java Application) pojawiło się małe okienko swingowe, w które po zakończeniu wykonania programu, mogłem (ale nie musiałem) wpisać nazwę pliku w którym log z wykonania był zapisywany. Jest to trochę dziwne, bo przez cały czas działania okno, jest nie klikalne, dopiero na końcu odzyskuje władzę w przyciskach. Efekt końcowy widzicie po boku .

Aby stworzyć wiązanie będziemy musieli przejść przez kilka etapów pośrednich.

• Będziemy musieli zdefiniować interfejs programistyczny w Javie,
• następnie przygotować na odpowiednie pliki nagłówkowe dla implementacji w C/C++ .
• w końcu przyjdzie czas na trochę prawdziwej implementacji. Będzie okazja, żeby sprawdzić ile pamiętasz z C/C++ .

Stworzenie API Javowego to rzecz najprostsza, znajdziecie to w każdym tutorialu np. tutaj. Wydaje mi się, że nawet nie trzeba tego arta dokładnie czytać , jeżeli chodzi o Javo’ową stronę najważniejsze są dwie rzeczy:

• Słówko native które informuję kompilator, że implementację tej metody dostarczy zewnętrzna biblioteka natywna. Przykładowa sygnatura metody: private native void sayHello();.
• Druga sprawa to załadowanie natywnej biblioteki do naszego projektu (już po uruchomieniu), zrealizować to można poprzez następujący statyczny blok kodu:

  static {
    System.load("ścieżka\HelloWorldNative\dist\HelloWorldNative.dll");
   }
  

  Możemy użyć metody load lub loadLibrary różnica między nimi może okazać się istotna. W wywołaniu metody load podajemy dokładną nazwę biblioteki wraz z rozszerzeniem. Wystarczy wyobrazić sobie sytuację gdy chcemy nasz program uruchomić pod linuxem, biblioteka zamiast rozszerzenia .dll ma .so. Z pomocą przychodzi nam druga wspomniana metoda, loadLibrary przyjmuję na wejściu tylko nazwę biblioteki (bez rozszerzenia), odpowiednia biblioteka jest wyszukiwana przez jvm w lokalizacjach na które wskazuje zawartość property systemowego java.library.path. Standardowo do java.library.path dodawane są (dla Windows) katalogi ../Windows oraz ../Windows/System32 powinien również zostać uwzględniony biezący katalog w którym jest uruchamiana aplikacja Javowa korzystająca z biblioteki.Więcej o wspomnianych metodach w dokumentacji klasy System.

Gdy mamy gotowy kod javowy, możemy wygenerować sobie plik(i) nagłówkowy które posłużą nam do implementacji kodu w C/C++.

      javah.exe -o wyjsciowy.h -jni -classpath ścieżka-do-klasybuildclasses NaszaKlasa

Należy przy tym pamiętać, że javah działa na skompilowanej klasie, więc jeżeli zmienisz coś w kodzie, pamiętaj aby najpierw zmienioną klasę skompilować a dopiero potem wywołać powyższe polecenie po raz drugi.

Finalnym i najbardziej pracochłonnym krokiem jest stworzenie natywnej biblioteki pośredniczącej. Biblioteka taka musi oferować funkcje określone w wygenerowanym w poprzednim kroku pliku nagłówkowym. Omówię skrótowo jak to zrobiłem w Visual Studio 2005, polecam też:Beginning JNI with NetBeans C/C++ Pack 5.5, jeżeli zdecydujecie się użyć opisanego w tutorialu zestawu Netbeans+Cygwin może wam się przydać informacja o tym, że GCC nie obsługuje (win32+cygwin) typu “__int64″. Został użyty w deklaracji typu w plikach nagłówkowych jni, na The Graphic Muse znajdziecie dokładniejsze wytłumaczenie, wraz z eleganckim rozwiązaniem problemu . Przejdźmy jednak do rzeczy:

1. Stwórz projekt:File/NewProject/Win32Project/ po wprowadzeniu nazwy przejdziesz do dalszych stron wizarda, wybierz: DLL jako typ aplikacji i zaznacz checkbox “Export symbols”. Zatwierdź wszystko.
2. Teraz będzie trochę mieszania w właściwościach projektu, kliknij prawym na głównym węzeł projektu w “Solution Explorer”. Musimy dodać do naszego projektu katalogi z których Visual Studio ma brać pliki nagłówkowe związane z JNI. W Configuration Properties/C/C++/General/Additional Includes Directories dodajemy dwa katalogi: JAVAHOME/include oraz JAVAHOME/include/windows. Dodajemy również katalog w którym znajduję się wygenerowany przez nas plik nagłówkowy.
3. Czas w końcu uwzględnić bibliotekę do której wiążemy nasz kod javowy. Ja otrzymałem wraz z plikiem .dll, plik .lib oraz odpowiedni plik nagłówkowy .h. Plik nagłówkowy dodajemy analogicznie jak w poprzednim kroku, natomiast .lib należy uwzględnić w własnościach linkera (Linker/Input/Additional Dependencies).
4. W projekcie istnieje plik nazwa-projektu.cpp, właśnie w nim będzie się działo całe zło .

       #include "jni.h"
       #include "windows.h"
       #include "plik-naglowkowy-natywnej-biblioteki.h"
       #include "wygenerowany-przez-nas-plik-naglowkowy.h"
   

   Pozostaje “tylko” zaimplementować odpowiednie funkcje w C++.

Jeżeli chodzi o implementację należy zwrócić uwagę na kilka istotnych kwestii:

• W C/C++ łańcuchy tekstowe (String) nie są kodowane w utf-8 jak w Javie, o tym jak to robić poprawnie można poczytać tu.
• Pamiętaj o tym, że każdy kawałek pamięci który zaalokujesz musisz zwolnić. Kod który piszesz będzie uruchomiony przez proces JVM, ale łapska GC tu nie sięgają.
• Odwoływanie się do tablic też nie jest takie proste… tu nic nie jest “taki proste”

VS2005 domyślnie buduje wersję debug naszego projektu, nalezy pamiętać, ze tak stworzony dll jest zależny od specyficznych bibliotek dostarczanych tylko z Visual Studio.

Moja wiedza jak widzicie jest dość powierzchowna, ale jak zwykle mam nadzieje, że komuś to pomoże. W moim przypadku implementacja wiązania ograniczyła się do wywołania odpowiednich funkcji z oryginalnej dll’ki, mimo, że nie było tam wielkiej filozofii to i tak to co napisałem nie zawsze działa :/. Po wiedzę konkretną odsyłam do źródeł:

• “The Java Native Interface – Programmer’s Guide and Specification” Sheng Liang
• JNI Technology – Sun’owski tutorial, całkiem sporo przykładów.
• Beginning JNI with Netbeans – wspomniany w tekście tutorial: JNI w Netbeans.
• The Graphic Muse – krok po kroku, coś jak tutaj
• JNI Basics – 1
• Integrating Visual C++,Java and Assembly – java i asm (grrr…. )
• JNI tutorial

Na sam koniec zostawiłem deser, jeżeli szukaliście kiedyś narzędzia do rozwiązywania nierozwiązywalnych problemów to SWIG jest właśnie dla was. W skrócie:

SWIG is a software development tool that connects programs written in C and C++ with a variety of high-level programming languages. SWIG is used with different types of languages including common scripting languages such as Perl, PHP, Python, Tcl, Ruby and PHP.

Poniżej update który zawdzięczamy w całości Przemkowi Lewickiemu (lemekk):

Ponieważ maneo “trzasnął” kawałek dobrego posta, który w moim przypadku okazał się bardzo pomocny, postanowiłem dorzucić od siebie kilka drobnych uwag, które mogą się komuś przydać przy walce z JNI .

Wykorzystanie bibliotek typów.
W moim przypadku, musiałem wywołać funkcję znajdującą się w windowsowej bibliotece typów (konkretnie activeds.dll). I tu zaczęły się schody, ponieważ nie było już tak prosto jak w opisie maneo . Do biblioteki dołączony jest tylko plik .tlb. I to właśnie nim należy się posłużyć, żeby wykorzystać bibliotekę. jest to jednak trochę bardziej skomplikowane niż proste zaincludowanie pliku nagłówkowego. Oto krótka proceudurka:

• w miejscu, gdzie dołączamy pliki nagłówkowe, zamiast zwykłego #import wklepujemy coś takiego: #include “biblioteka.tlb”
• kompilujemy projekt. Kompilator powinien wygenerować kilka nowych plików w tym plik “biblioteka.tlh”.
• w miejscu #include’a wpisujemy juz zwykły: #import “biblioteka.tlh” (prawdopodobnie plik “biblioteka.tlh” będzie trzeba przenieść wcześniej z folderu ‘debug’ do folderu projektu). W trakcie kompilacji mogą wystąpić błędy związane z powtórzeniem definicji typów. Trzeba wtedy po prostu usunąć te definicje z pliku “biblioteka.tlh”.

Po takich akrobacjach powinniśmy już mieć dostęp do typów i ich funkcji w bibliotece.

Błąd: “Exception in thread “main” java.lang.UnsatisfiedLinkError: ścieżka\NaszaBiblioteka.dll:
Nie można uruchomić aplikacji, ponieważ jej konfiguracja jest niewłaściwa. Problem ten może rozwiązać ponowne zainstalowanie aplikacji”. Błąd ten występował podczas ładowania biblioteki przez Javę, na komputerach, na których nie zainstalowany został Visual. Z rozwiązaniem tego problemu pomógł mi… maneo , a piszę o tym dlatego, że nie umieścił tego w swoim poście bo pewnie było to dość oczywiste ale dla amatorów Visuala takich jak ja pewnie już nie . W każdym razie chodzi o konfigurację uruchomieniową (czy jak to tam zwał), z którą kompilator Visuala tworzy bibliotekę. Jak napisał maneo, domyślnie jest to konfiguracja “debug”. Czego nie napisał, to to, że należy wybrać konfigurację “release” . Po takim zabiegu biblioteka powinna już “śmigać” wszędzie