🚀 go-pugleaf

MARCIN NEMECZEK wrote:
> 
> Jak dostac sie do niestandardowych funkcji jadra UNIXa z javy ( Solaris
> 2.5.1) ?

Chora idea... Specjalnie po to jest java, żeby się nie dostawać.

Michał

-- 
********     MEMBER OF THE INTERNATIONAL PROGRAMMERS GUILD    ********
WWW: http://www.lodz.pdi.net/~mimo  tel: Int. Acc. Code + 48 42 148340
add: Michal Mosiewicz  *  Bugaj 66 m.54 *  95-200 Pabianice  *  POLAND

MARCIN NEMECZEK (viking@ia.agh.edu.pl) wrote:
: Jak dostac sie do niestandardowych funkcji jadra UNIXa z javy ( Solaris
: 2.5.1) ?
: Funkcje te sa ladowane jako virtual driver ( pisane w C ).

: Trzeba pisac jakies includy , czy co innego ?
: Moza znalesc opis do tego na Internecie ?

Nie wiem o co ci chodzi z tym virtual driver, tak wiec to pomine, jezeli
chodzi o reszte to czytaj dalej.

Musisz zadeklarowac klase z metoda native, skompilowac ja, utworzyc stub i
header za pomoca jakiegos programiku (chyba javah ?), napisac funkcje w C
pasujaca do uzyskanego w ten sposob prototypu, skompilowac ja normalnym
kompilatorem C do biblioteki ladowanej dynamicznie i juz dziala.
Pamietaj tylko aby na poczatku programu w javie zaladowac ta biblioteke
(System.loadLibrary - nie jestem pewien sprawdz sobie).

Sprawa sie komplikuje o ile chcesz z poziomu C operowac na obiektach i
zmiennych javy - musisz wszystko wolac przez specjalny interfejs (popatrz
na include/jni.h)

Opis krok po kroku jak to zrobic dla prostych przypadkow znajdziesz w
tutorialu (lezy na http://java.sun.com katalog chyba
/products/jdk/1.1/tutorial , albo na
ftp://ftp.javasoft.com/docs/jdk1.1/tutorial.html.*)
Jezeli interesuje cie to na powaznie to musisz przebrnac przez
ftp://ftp.javasoft.com/docs/jdk1.1/jni.pdf (lub ps) )

A jezeli chodzi o glos ze po to jest java zeby takimi rzeczami sie nie
przejmowac to nie prawda. Sa rzeczy ktorych w javie sie nie da zrobic, a z
ich powodu nie ma co rezygnowac z jezyka (wyobrazmy sobie sytuacje w
ktorej trzeba sterowac robotem przez jakis interfejs szeregowy/rownolegly; 
caly program decyzyjny i komunikacja z uzytkownikiem moze by w javie, a
samo przesylanie bajtow na RS przez malutka funkcje typu native)

Artur

Artur Biesiadowski wrote:
(...)
Wielkie Dzieki

> A jezeli chodzi o glos ze po to jest java zeby takimi rzeczami sie nie
> przejmowac to nie prawda. Sa rzeczy ktorych w javie sie nie da zrobic, a z
> ich powodu nie ma co rezygnowac z jezyka (wyobrazmy sobie sytuacje w
> ktorej trzeba sterowac robotem przez jakis interfejs szeregowy/rownolegly;
> caly program decyzyjny i komunikacja z uzytkownikiem moze by w javie, a
> samo przesylanie bajtow na RS przez malutka funkcje typu native)
> 
> Artur

Zgadza sie. 
Mnie po prostu chodzi o sterowanie specjalnym urzadzeniem podpietym do
Suna 
przez SBUSa

__
Marcin Nemeczek

Artur Biesiadowski wrote:

> A jezeli chodzi o glos ze po to jest java zeby takimi rzeczami sie nie
> przejmowac to nie prawda. Sa rzeczy ktorych w javie sie nie da zrobic, a z
> ich powodu nie ma co rezygnowac z jezyka (wyobrazmy sobie sytuacje w
> ktorej trzeba sterowac robotem przez jakis interfejs szeregowy/rownolegly;
> caly program decyzyjny i komunikacja z uzytkownikiem moze by w javie, a
> samo przesylanie bajtow na RS przez malutka funkcje typu native)

Rozszerzanie API javy o własne funkcje powoduje po prostu, że to już
przestaje być rozwiązanie przenośne. Wtedy nie działa już na wirtualnej
maszynie ze standardowym API, tylko działa na maszynie z nietypowymi
API, ewentualnie przestaje już być programem w javie, a staje się
nieportowalną hybrydą. To po co wtedy java? Tylko dlatego, że ma w sobie
dość proste środki do budowania interfaceu? Jest wiele prostszych metod
na osiągnięcie tego celu. Czy program decyzyjny buduje się latwiej w
javie?

Michał



-- 
********     MEMBER OF THE INTERNATIONAL PROGRAMMERS GUILD    ********
WWW: http://www.lodz.pdi.net/~mimo  tel: Int. Acc. Code + 48 42 148340
add: Michal Mosiewicz  *  Bugaj 66 m.54 *  95-200 Pabianice  *  POLAND

=?iso-8859-2?Q?Micha=B3?= Mosiewicz (mimo@lodz.pdi.net) wrote:
: Rozszerzanie API javy o własne funkcje powoduje po prostu, że to już
: przestaje być rozwiązanie przenośne. Wtedy nie działa już na wirtualnej
: maszynie ze standardowym API, tylko działa na maszynie z nietypowymi
: API, ewentualnie przestaje już być programem w javie, a staje się
: nieportowalną hybrydą. To po co wtedy java? Tylko dlatego, że ma w sobie
: dość proste środki do budowania interfaceu? Jest wiele prostszych metod
: na osiągnięcie tego celu. Czy program decyzyjny buduje się latwiej w
: javie?

Jest roznica w ilosci rzeczy ktore trzeba zmieniac. Jezeli bede mial 1MB
zrodla w javie i 5kb zrodla w C, to szybciej bede wykonywal porty na
wszelkie komputery niz dla 1,005MB w C.
Jezeli chodzi o prostrze sposoby na budowanie iterface to nie wiem
dokladnie co masz na mysli - przychodzi mi na mysl tylko TCL(czy jak to
tam sie nazywa). Ale to tylko zabezpiecza grafike, a co z siecia ?
I ogolnie java jest szybsza niz TCL (JIT na pewno, interpreter chyba tez).

A zupelnie oddzielnie moglbym bronic javy jako jezyka do pisania
czegokolwiek bez wzgledy na przenosnosc. Wedlug mnie programuje sie w niej
latwiej i lepiej niz w C++, tracac co prawda szybkosc (przy JIT jest to do
przezycia), ale zyskujac piekny debugging i run-time checking.
A sprobuj na przyklad w C++ oblugiwac wyjatki - co platforma to inaczej
sie kaszani.

Artur

Michal Mosiewicz wrote:
> 
> Artur Biesiadowski wrote:
> 
> > A jezeli chodzi o glos ze po to jest java zeby takimi rzeczami sie nie
> > przejmowac to nie prawda. Sa rzeczy ktorych w javie sie nie da zrobic, a z
> > ich powodu nie ma co rezygnowac z jezyka (wyobrazmy sobie sytuacje w
> > ktorej trzeba sterowac robotem przez jakis interfejs szeregowy/rownolegly;
> > caly program decyzyjny i komunikacja z uzytkownikiem moze by w javie, a
> > samo przesylanie bajtow na RS przez malutka funkcje typu native)
> 
> Rozszerzanie API javy o wlasne funkcje powoduje po prostu, ¿ze to juz¿
> przestaje byc rozwiazanie przenosne. Wtedy nie dziala juz na wirtualnej
> maszynie ze standardowym API, tylko dziala na maszynie z nietypowymi
> API, ewentualnie przestaje juz byc programem w javie, a staje sie
> nieportowalna hybryda. To po co wtedy java? Tylko dlatego, ze ma w sobie
> dosc proste srodki do budowania interfaceu? Jest wiele prostszych metod
> na osiagniecie tego celu. Czy program decyzyjny buduje sie latwiej w
> javie?
> 
> Michal


Jest wiele sytuacji, w ktorych niezbedne jest wykorzystanie bibliotek
native.
Wiekszosc implementacji sterownikow JDBC wykorzystuje np. rodzime dla
baz
danych biblioteki do komunikacji z SQL Serwerem. Przenaszalnosc jest
tutaj
zapewniona dzieki wykorzystaniu JDBC API, dzieki ktorej napisana
aplikacja 
jest niezalezna od konkretnej bazy danych. Nadal jednak musze ladowac 
biblioteke native.

Poza tym mozna skonstruowac aplikacje w postaci klient-serwer.
W przypadku wspomnianego tu sterowania robotem serwer bedzie
posredniczyl 
pomiedzy klientami a robotem. Wystarczy wiec jesli tylko sewer bedzie 
wykorzystywal biblioteki native, klienci sa natomiast nadal w czystej
Javie.

Robert