Java Native Interface: vytváříme virtuální stroj (diskuse)

[Tomáš]

Zajímalo by mě proč je kontrukce

public class Trida {
     private long nativniData; // v nativniData je nějaký Cčkový ukazatel
}

špatně. V rámci metody disposeNative() se pak nativniData korektně uvolní z paměti.

Stejně tak nerozumím tomu, proč by metoda finalize neměla být nativní? S předpokladem, že nativní finalize volá finalize předka ve svém závěru.

Předem díky za vysvětlení.

[Luboš Doležel (Doli)]

V rámci metody disposeNative() se pak nativniData korektně uvolní z paměti.

Jde o principiání nekorektnost. Ukazatale jsou a vždy budou jen 64bitové, že tam dáváte long?

To kolem finalize bych považoval za best practice. Jde spíš o praktičnost. Pokud by bylo finalize nativní a vy byste potřeboval najednou uzavírat nějaký soubor, tak byste to musel udělat přidáním volání close() do nativního kódu (což je zbytečně složité). Tak je lepší si to rovnou oddělit.

[Tomáš]

Už rozumím. Jde o to, že není nikde definováno, že sizeof(void*) < sizeof(long). Já bych se asi místo vytváření mapy (= výkonostní zabiják) spíše přikláněl,k využití nativní třídy CPointer, která má pointer peer deklarovaný jako

public abstract class CPointer {
protected long peer;
     ...
}

A kruci, zase long.

[Luboš Doležel (Doli)]

Mapa není až takový zabiják Hledání ve vhodně udělané mapě je v čase log_2(n). Při 10 tisísích takto spravovaných objektů je pro dohledání ukazatele nutné projít jen cca 13 prvků z mapy, než je nalezen ten správný. To není vůbec zlé.

Jinak ty odkazované stuby jsou taková znouzecnost, neboli jak emulovat C v Javě. (Normálně by se na tohle použilo JNA a člověk by si tyhle věci psát nemusel.) Je možné, že ukazatel nebude nikdy delší než javovský long. Ale takových předpokladů se už ve světě počítačů udělalo tolik a kolik škody to taky napáchalo... Mapa mě hřeje na srdci víc