Cartella lib creata assieme al file .jar

[Gas75]

Salve,
nel generare un file .jar, mi ritrovo anche una cartella lib contenente a sua volta due file .jar, AbsoluteLayout e beansbinding-1.2.1, contenenti a loro volta vari file .class.
Il file .jar funziona anche cancellando la cartella lib o spostandolo sul desktop per esempio...
Mi chiedo l'utilità di tali cartelle e file .jar.

[andbin]

Salve,
nel generare un file .jar, mi ritrovo anche una cartella lib contenente a sua volta due file .jar, AbsoluteLayout e beansbinding-1.2.1, contenenti a loro volta vari file .class.
Il file .jar funziona anche cancellando la cartella lib o spostandolo sul desktop per esempio...
Mi chiedo l'utilità di tali cartelle e file .jar.

Non lo posso sapere io ... non so cosa hai usato per generare il tuo jar, non so se/come servano davvero alla tua applicazione.

Un jar può avere dipendenze esterne (altri jar), basta elencarle nell'attributo Class-Path all'interno del "manifest" del jar. Se nel tuo jar il manifest non ha il Class-Path, allora quella lib e quei jar presumibilmente non servono.

[Gas75]

Sì, nel Manifest c'è il class-path che richiama quei due jar.

[andbin]

Sì, nel Manifest c'è il class-path che richiama quei due jar.

Allora magari il Class-Path è rimasto così per via di qualche configurazione ma poi materialmente non usi le classi in quei jar .... non saprei che altro dirti.

[Gas75]

Nelle Properties del progetto ho trovato i riferimenti a quei due file jar, presi non so come né quando dalla cartella delle librerie di NetBeans. Ho azzardato a rimuoverle e rigenerare il jar: ora funziona senza portarsi appresso quella cartella lib.

Sarei curioso di capire come certe "zavorre" finiscano in un progetto... Posso capire che ho fatto vari tentativi, ma se una libreria è oramai inutile in quel progetto, perché lasciarla "ai posteri"?

[LeleFT]

NetBeans non può sapere se il tuo progetto ha bisogno o meno delle librerie che tu (tu, NetBeans non le aggiunge autonomamente, quindi se erano presenti significa che le hai aggiunte tu manualmente) gli hai indicato... lo puoi sapere solo tu. Se tu aggiungi librerie che non servono lui non può fare altro che alzare le mani e aggiungerle in class-path e, di conseguenza, anche nella apposita cartella "lib" che serve, appunto, a contenere le dipendenze esterne. Quello che può fare NetBeans (e che fa, ovviamente) è capire se da qualche parte stai cercando di usare riferimenti a classi che non sono in class-path... in quel caso te lo segnala e la compilazione, ovviamente, non va a buon fine... ma se tu aggiungi librerie che non servono, lui non può farci nulla.

AbsoluteLayout e beansbinding mi ricordano delle librerie che vengono usate dal plugin del window builder di NetBeans... se hai usato il windowbuilder (per la costruzione delle interfacce grafiche in modo "visuale"), è normale che siano finite dentro quelle librerie... servono al codice auto-generato dall'IDE... il mio consiglio è di non usare il windowbuilder per la creazione di interfacce grafiche, ma di scriverle a mano.

Ciao.

[Gas75]

Ho capito l'automatismo, però mi aspetterei che in fase di "Clean and Build", NetBeans ripulisse il progetto da oggetti divenuti non più necessari, sennò togliamo il "Clean" che a casa mia è sinonimo di "pulizia".
Io più che sperimentare delle "skin" per la mia GUI non ho fatto, senza poi applicarne nessuna, ho pensato a farla funzionare e a darle un aspetto ordinato.

[andbin]

mi aspetterei che in fase di "Clean and Build", NetBeans ripulisse il progetto da oggetti divenuti non più necessari, sennò togliamo il "Clean" che a casa mia è sinonimo di "pulizia".

No, non in quel senso. Con gli strumenti di "build" (che siano quelli intrinseci/interni di un IDE o più in generale es. Maven) il "clean" è solamente quella fase in cui semplicemente vengono eliminati i file generati dal processo di build. Quindi: .class, .jar, report di test, ecc...
Con es. Maven, dare mvn clean vuol semplicemente dire: elimina completamente la directory "target" (che è quella dove vanno i file generati). Tutto qui.

Il clean NON vuol dire: vai a verificare se il progetto è valido, se usa le librerie appropriate, se una libreria X è usata o meno.

[Gas75]

Diciamo che mi ero abituato a usare programmi capaci di riconoscere oggetti inutilizzati, tipo layer vuoti, ed eliminarli alleggerendo il file...