[NETBEANS] Import di classi java

[ibpikiuz]

Ciao a tutti,
sono nuovo di questo forum, e relativamente una new entry del mondo java.
Sto realizzando un progetto su netbeans, nello specifico una libreria (.jar) da utilizzare all'interno di altro progetto (un contesto web).
Sono in possesso dell'interno progetto su cui sto lavorando ma non di tutti i suoi sorgenti, che comunque non credo essermi utili (ma forse sarete voi a dirmelo).
Il mio problema è il seguente, ho realizzato, o meglio sto provando a realizzare un package e queste sono le prime righe della mia classe java:

package it.ib.scheduler;


import CPContext;
import CPLib;
import SPLib;
import java.io.*;
import java.util.*;
import java.text.*;
import java.lang.reflect.*;
import com.zucchetti.SPBridge.*;
import com.zucchetti.SPBridge.SPJSPBridge.CPContext;
import com.zucchetti.SPBridge.SPJSPBridge.Caller;
....

Le prime 3 righe del mio package risultano errate:
import CPContext;
import CPLib;
import SPLib;
Mentre per tutte gli altri import ho risolto includendo nel mio progetto i jar necessari (Add JAR/Folders).
CPContext, CPLib e SPLib sono 3 java presenti all'interno del contesto...ho anche provato ad aggiungere al mio progetto il percorso dove risiedono questi files, ma nulla da fare, risultano sempre evidenziati in rosso è per tutti l'errore è sempre '.' expected.
Dove sbaglio? Cosa devo fare per far vedere al mio progetto questi files nell'import?

Grazie a tutti

[valia]

non dici ad un compilatore java "dentro questo file importa il jar vattelapesca", dici "importa le classi x, y, z" dove x, y, z sono dei classname validi (cioè nella forma

nomepackage.nomeclass oppure nomepackage.*).

Se non metti . significa che non c'è un packaging (cosa di fatto sbagliata) e non sa come comportarsi.

Fondamentalmente fai 2 errori: tentare di importare il jar e non specificare i package correttamente.
Sei ancora all'inizio, rivedi bene l'organizzazione dei file in java.

[LeleFT]

CPContext, CPLib e SPLib sono 3 java presenti all'interno del contesto

Che significa?

Tieni presente anche un'altra cosa, oltre a quanto detto da valia: se quelle 3 classi sono all'interno dello stesso package della classe che stai sviluppando (ossia, il package "it.ib.scheduler"), allora non serve alcun import, poichè tutte le classi di uno steso package sono automaticamente visibili l'una all'altra.

Ciao.

[ibpikiuz]

non dici ad un compilatore java "dentro questo file importa il jar vattelapesca", dici "importa le classi x, y, z" dove x, y, z sono dei classname validi (cioè nella forma

nomepackage.nomeclass oppure nomepackage.*).

Se non metti . significa che non c'è un packaging (cosa di fatto sbagliata) e non sa come comportarsi.

Fondamentalmente fai 2 errori: tentare di importare il jar e non specificare i package correttamente.
Sei ancora all'inizio, rivedi bene l'organizzazione dei file in java.

Grazie, il tuo intervento mi è chiarissimo e sono sicuro che hai anche ragione nell'indicarmi di rivedere bene l'organizzazione, ogni commento istruttivo è ben accetto data la mia immatura esperienza in java.
Il fatto è che la strada che ho intrapreso è quella che ho trovato "curiosando" all'interno di altri jar del progetto che ho scompattato e decompilato. Di fatto in molte classi di questi jar sono presenti proprio questi import x,y,z così come riportati sul mio codice.
A parte la mia inesperienza, mi risulta comunque difficile rivedere l'organizzazione di alcune cose, in quanto necessarie al mio progetto, ma non di mia competenza (perché sviluppare da terze parti).
Mi chiedevo come mai io non riesco, per quanto sbagliato, a replicare quanto già presente in altre parti del progetto?
Ho capito che x,y,z non sono dei packaging, ma anche se sbagliato coma mai non riesco a importarli come classi dato che ho intravisto essere possibile da altri codici di progetto decompilati?

Grazie ancora per l'assistenza

[ibpikiuz]

Che significa?

Tieni presente anche un'altra cosa, oltre a quanto detto da valia: se quelle 3 classi sono all'interno dello stesso package della classe che stai sviluppando (ossia, il package "it.ib.scheduler"), allora non serve alcun import, poichè tutte le classi di uno steso package sono automaticamente visibili l'una all'altra.

Ciao.

Ho un contesto web, pubblicato su un tomcat, e questi files class (CPContext, CPLib e SPLib) sono presenti all'interno della cartella WEB-INF\classes.
Non sono parte del mio package, ma li devo utilizzare in quanto necessarie per effettuare operazioni oltre che a verificare sessioni e utente.

Grazie anche a te per l'aiuto

[valia]

allora, ti ho detto di rivedere l'organizzazione dei file (il packaging) in java perché hai provato a importare l'intero jar, quindi visto che sei all'inizio, probabilmente non ti è chiarissimo e un ripasso non può che fare bene.
Quando tu crei un progetto (una lib), dentro questo progetto sicuramente hai una organizzazione di questo tipo:

com (it).nomeAzienda(nomesviluppatore).nomeModulo

i nomi ovviamente sono variabili, ma questo che ti ho scritto sopra (che è il nome del package) viene messo dentro ogni file java (dopo la parola chiave package) e serve ad identificare univocamente una classe.
In generale una classe java è definita come

package it.valia.packageEsempio; 

import java.util.List; 

public class Example{...}

sul file system, partendo dalla root di definizione del sorgente, avrai nella cartella it/valia/packageEsempio il .class della classe Example.

queste sono due righe sulla definizoine di package.

Se io fornisco a te una libreria, devo darti un minimo di howto, dirti cosa contiene e come andarlo a beccare. QUesto significa scrivere la javadoc (o un minimo di guida appunto).
Se non sai cosa mettere dentro import, se non hai la javadoc hai un problema, perché il jar per noi è una scatola nera e non avendo info dal produttore del jar, non sai come trattarlo.
Tu hai anche scompattato il jar, avrai visto l'alberatura (del tutto uguale a quella dei sorgenti), ovviamente non sapendo altro sulla lib, non sai cosa c'è, cosa ti serve ecc.

altra precisazione: tu non importi il codice decompilato, ti limiti a dire "guarda che la definizione di quell'oggetto lì si trova dove ti indico". Significa che il compilatore andrà a cercare il tuo riferimento, se lo trova prosegue. A livello molto basso hai l'integrazione degli oggetti, ad alto livello ricorda solo che stai indicando un altra locazione dell'oggetto, non stai affatto copiando l'oggetto nella tua classe

[ibpikiuz]

allora, ti ho detto di rivedere l'organizzazione dei file (il packaging) in java perché hai provato a importare l'intero jar, quindi visto che sei all'inizio, probabilmente non ti è chiarissimo e un ripasso non può che fare bene.

Purtroppo è questo punto che non capisco. Ma forse non mi sono spiegato bene io.
Nel creare il mio package, ho voluto, per non inventarmi l'acqua calda, vedere cosa era stato fatto in altri packages. Proprio in alcuni file di questi package ho trovato le istruzioni che ho riportato nelle mie import. Ma di fatto questi CPContext, CPLib, SPLib non sono .class che appartengono ai package che ho decompilato o ad altri package, ma .class presenti all'interno della cartella WEB-INF\classes del contesto web. Cerco di rappresentare meglio la struttura qui sotto:

miosito
-- WEB-INF
-- -- lib
-- -- -- miopackage.jar
-- -- -- packagenonmio1.jar
-- -- -- packagenonmio2.jar
-- -- classes
-- -- -- CPContext$1.class
-- -- -- CPContext$a.class
-- -- -- CPContext$b.class
-- -- -- CPContext.class
-- -- -- CPLib$1.class
-- -- -- CPLib.class
-- -- -- SPLib.class


Dentro la struttura di packagenonmio1 e packagenonmio2 non esiste traccia di quei file, se non nelle istruzioni di import, così come ho cercato di replicare io.
Per altri import, seguendo anche quanto mi indicato nelle tue risposte, non ho avuto problemi in quanto effettivamente dei package.

Grazie ancora per le tue indicazioni

[valia]

ok, ma CPContext avrà un suo package o no? devi mettere quello.
poi non mi è chiaro perché parti da classes, in genere hai classes riferendoti ai sorgenti che stia compilando e legando alla web app...i conti non tornano

[ibpikiuz]

ok, ma CPContext avrà un suo package o no? devi mettere quello.
poi non mi è chiaro perché parti da classes, in genere hai classes riferendoti ai sorgenti che stia compilando e legando alla web app...i conti non tornano

...no il problema è proprio quello, ne CPContext, ne CPLib, ne SPLib hanno un loro package.

Se provo a decompilare per esempio SPLib.class, il suo sorgente inizia così:

import java.util.Collections;
import java.util.Enumeration;
import java.util.HashSet;
import java.util.Hashtable;
import java.util.Properties;
import java.util.Set;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.File;
import java.io.OutputStreamWriter;
import java.io.PrintWriter;
import java.io.Serializable;
import java.io.Writer;
import java.net.URLEncoder;
import java.net.URLDecoder;
import java.sql.Timestamp;
import java.util.HashMap;
import java.util.HashSet;
import java.util.Locale;
import java.util.Map;
import java.util.Set;
import java.util.regex.Pattern;

public class SPLib {
...

Parto dai classes per cercare di far capire che questi files una volta sul contesto ed in esecuzione sono files e non package, e che non risiedono nello stesso percorso del mio package.

Ho copia di questi files anche nella mia cartella di lavoro locale e ho anche provato ad includerli in netbeans dentro al mio progetto, ma nulla.
Le ho provate tutte, ma nulla....

[valia]

chi ha fatto queste classi ha fondamentalmente sbagliato: ha usato il package di default (nessun package), in tal caso a livello di .class non puoi fare molto (devi stare nella stessa dir dei file che esegui).

Fatti dare i sorgenti e definisci un package per questa roba e/o fatti tu i sorgenti dal decompilato (cosa che sconsiglio perché puo non avere delle dipendenze).