Come funziona l’importazione Java?

Mi piacerebbe sapere come funziona la dichiarazione di import .

Lo sto chiedendo perché ho le seguenti imports nel mio progetto:

 import static com.googlecode.javacv.jna.highgui.cvCreateCameraCapture; import static com.googlecode.javacv.jna.highgui.cvGrabFrame; import static com.googlecode.javacv.jna.highgui.cvReleaseCapture; import com.googlecode.javacv.CanvasFrame; import com.googlecode.javacv.FrameGrabber; import com.colorfulwolf.webcamapplet.gui.ImagePanel; import com.googlecode.javacv.OpenCVFrameGrabber; import com.googlecode.javacv.jna.cxcore.IplImage; 

Non ho questi pacchetti nel mio progetto, quindi, come verrà importato?

Se creo un file JAR con tutte le mie classi, il mio server dove ospiterà questo file JAR, deve essere libero accesso a Internet per ottenere questo package ?

Ho avuto qualche problema nella mia Applet che ha queste importazioni, e sto facendo questa domanda, per capire se può essere una regola di Internet.

   

Nei linguaggi dinamici, quando l’interprete import s, legge semplicemente un file e lo valuta.

In C, le librerie esterne sono localizzate dal linker in fase di compilazione per build l’object finale se la libreria è compilata staticamente , mentre per le librerie dinamiche viene richiamata una versione più piccola del linker in runtime che rimappa gli indirizzi e rende il codice disponibile nella libreria all’eseguibile.

In Java, l’ import viene semplicemente utilizzata dal compilatore per consentire di denominare le classi in base al loro nome non qualificato, ad esempio String invece di java.lang.String . Non hai davvero bisogno di importare java.lang.* Perché il compilatore lo fa per impostazione predefinita. Tuttavia questo meccanismo è solo per farti risparmiare un po ‘di battitura. I tipi in Java sono nomi di classi completamente qualificati, quindi una String è in realtà un object java.lang.String quando viene eseguito il codice. I pacchetti hanno lo scopo di prevenire conflitti di nomi e consentono a due classi di avere lo stesso nome semplice , invece di basarsi sulla vecchia convenzione C dei tipi di prefisso come questo. java_lang_String . Questo è chiamato namespacing .

A proposito, in Java c’è il costrutto di importazione statica , che consente di salvare ulteriormente la digitazione se si usano molte costanti da una certa class. In una unità di compilazione (un file .java) che dichiara

 import static java.lang.Math.*; 

è ansible utilizzare la PI costante nel codice, anziché fare riferimento a Math.PI e il metodo cos() anziché Math.cos() . Quindi per esempio puoi scrivere

 double r = cos(PI * theta); 

Una volta compreso che le classi sono sempre referenziate dal loro nome completo nel bytecode finale, è necessario capire come viene effettivamente caricato il codice class. Ciò accade la prima volta che viene creato un object di quella class o la prima volta che si accede a un membro statico della class. A questo punto, ClassLoader tenta di individuare la class e creare un’istanza. Se non riesce a trovare la class, viene generata ClassNotFoundException . Per individuare la class, ClassLoader genere controlla i percorsi elencati nella $CLASSPATH ambiente $CLASSPATH .

Per risolvere il tuo problema, sembra che tu abbia bisogno di un elemento applet come questo

  

A proposito, non è necessario importare gli archivi nel JRE standard.

La dichiarazione di importazione di Java è puro zucchero sintattico. l’importazione viene valutata solo al momento della compilazione per indicare al compilatore dove trovare i nomi nel codice.

È ansible vivere senza alcuna istruzione di importazione quando si specifica sempre il nome completo delle classi. Come questa linea non ha bisogno di alcuna dichiarazione di importazione:

 javax.swing.JButton but = new javax.swing.JButton(); 

La dichiarazione di importazione renderà il tuo codice più leggibile come questo:

 import javax.swing.*; JButton but = new JButton(); 

L’importazione in Java non funziona affatto, poiché viene valutata solo in fase di compilazione. (Tratta come scorciatoie in modo da non dover scrivere nomi di classi completi). In fase di esecuzione non vi è alcuna importazione, solo FQCN.

In fase di esecuzione è necessario che tutte le classi a cui si fa riferimento possano essere trovate dai classloader. (L’infrastruttura del classloader a volte è una magia oscura e molto dipendente dall’ambiente.) Nel caso di un’applet, dovrai configurare correttamente il tuo tag HTML e anche fornire gli archivi JAR necessari sul tuo server.

PS: La corrispondenza al runtime avviene tramite nomi di class qualificati – la class trovata con questo nome non è necessariamente la stessa o compatibile con la class che hai compilato.

javac (o java durante il runtime) cerca le classs importate nel classpath . Se non sono presenti nel classpath vengono lanciate eccezioni classnotfound .

classpath è proprio come la variabile path in una shell, che viene utilizzata dalla shell per trovare un comando o un eseguibile.

Intere directory o singoli file jar possono essere messi nel classpath . Inoltre, sì, un classpath può forse includere un percorso che non è locale ma è da qualche parte su Internet. Si prega di leggere di più su classpath per risolvere i vostri dubbi.

Le classi che si stanno importando devono trovarsi sul classpath. Pertanto, gli utenti dell’applet devono avere le librerie nel posto giusto o semplicemente fornire tali librerie includendole nel file jar. Ad esempio in questo modo: il modo più semplice per unire una versione in un file JAR