Come si determinano quali vasi sono necessari per tali e tali funzionalità di un framework? Ad esempio, quali vasetti sarebbero necessari tra tutti quelli disponibili per Spring per supportare solo l'iniezione di dipendenza?Determinazione di quali vasetti minimi sono necessari per una funzione
Esistono strumenti che creano JAR minimi calcolando quali classi sono effettivamente utilizzate in un'applicazione analizzando staticamente il codice, quindi creando un nuovo JAR contenente solo quelle classi. (. Ricordo usando Zelix Classmaster per fare questo, ma ci sono molte alternative)
Il problema con l'utilizzo di questi strumenti per un quadro DI come Primavera includono:
l'unica traccia dipendenze statiche esistenti. Se si caricano dinamicamente le classi, è necessario comunicare specificatamente all'analizzatore ciascuna di esse. I framework DI in generale e Spring in particolare sono pieni di caricamento dinamico, incluso il caricamento dinamico opaco al codice dell'applicazione.
Gli strumenti esistenti funzionano creando un nuovo JAR di output, non specificando quale dei JAR di input non viene utilizzato. Mentre il reimballaggio dei JAR è OK se si sta creando un'applicazione con involucro termoretraibile da una base di codice closed-source, non è auspicabile in generale e potenzialmente problematica con alcune licenze open-source. Certamente non vuoi farlo con Spring.
In teoria, qualcuno potrebbe scrivere uno strumento per aiutare. In pratica, lo strumento dovrebbe (per esempio) sapere come estrarre le dipendenze dinamiche delle classi dalle configurazioni di Spring espresse in annotazioni, XML e dai descrittori di bean creati in fase di esecuzione da una configurazione di ordine superiore (ad esempio SpringSecurity). Questo è un grande chiedere. E anche in questo caso si ha il problema che una "piccola" modifica ai cablaggi effettuata sulla piattaforma di installazione potrebbe fallire a causa di un JAR richiesto che è stato escluso dal processo di potatura JAR.
A mio avviso, le alternative sono più pratici:
[Proguard] (http://proguard.sourceforge.net) è un altro esempio che può farlo (e altro). – BalusC
@BalusC - e ci sono indubbiamente altri esempi degni. Ma sfortunatamente, non affrontano veramente * questo * problema. –
Mi riferivo al 1 ° paragrafo :) Prima di modificare le alternative pratiche in, che comunque sono pienamente d'accordo (+1). – BalusC
Ecco perché alcuni progetti Java precedenti hanno 600 Jars e un file di guerra da 200 MB, per un'applicazione di 10.000 linee. Una specie di dolore se non lo gestisci con attenzione ...
Si dovrebbe davvero chiedere al fornitore di framework o leggere la documentazione. Analizzare in modo statico quali vasi sono necessari potrebbe non essere sufficiente in alcuni casi (caricamento dinamico) e talvolta potresti finire con troppi barattoli.
Una volta ho fatto qualche cosa di ftp helper in una sorta di libreria "di utilità". Dipende da un barattolo di App ftp. Se non hai mai usato le funzionalità ftp nella libreria non avresti bisogno del contenitore ftp, ma l'analisi statica del codice potrebbe dire che ne hai bisogno. Questo è qualcosa che dovresti documenti.
Test, test, test. Ma di solito se il framework dice che ha bisogno di tutti i barattoli, è meglio fornire tutti i barattoli, altrimenti si è da soli. –
Un esempio è Spring. Quasi tutte le dipendenze di terze parti sono contrassegnate come opzionali nel MAVen POM. Sono d'accordo sul fatto che il test sia il "catch-all" per questo, ma è una buona domanda - ho spesso desiderato un modo per sapere a runtime quali librerie sono effettivamente utilizzate. Ho usato un compilatore nativo Ahead-of-Time Java - questo ha registrato tutte le classi utilizzate e i vasi da cui provenivano. È possibile emulare qualcosa di simile con un programma di caricamento classi personalizzato che tiene traccia delle classi caricate e utilizza Class.getResource() per determinare la posizione. – mdma