2009-02-20 5 views
8

Come sviluppatore, sono spesso interessato a nuove funzionalità linguistiche che possono semplificarti la vita. Ad esempio, java 5 ha portato generici e annotazioni nel linguaggio, caratteristiche che possono sicuramente aumentare la tua produttività.Il meccanismo di versioning forzato dalla piattaforma è la funzionalità più necessaria di java?

Tuttavia, quando guardo a circa un decennio lavorando sulla piattaforma java, trovo che i problemi relativi al controllo delle versioni sono il più grande colpevole di sforzi improduttivi e inutilmente spesi. Ore e ore di ricerca della versione corretta del jar, cercando di conciliare qualche conflitto di versioning, aggiornando le librerie dipendenti ecc. Quando ho iniziato a lavorare in java, le cose non erano poi così difficili, avresti alcune librerie di terze parti e il gioco è fatto . Oggi, la tua tipica applicazione web potrebbe facilmente usare: Spring Framework, Hibernate, Struts, lo chiami. Tutti questi contengono un numero di librerie di terze parti dipendenti. Oggi, i miei archivi per le orecchie includeranno in genere 40 o più librerie di terze parti. Un vero baratro inferno!

Con le annotazioni, non è necessario gestire i file di configurazione per Hibernate, ad esempio. Una bella funzionalità, ma non ho visto molti problemi derivanti dal fatto che tengo i miei descrittori in un file separato. Con i generici, sono risparmiato dal scrivere dichiarazioni cast, ma nel mio intero carrier di programmazione non riesco a ricordare un singolo bug che si sarebbe potuto prevenire usando un contenitore sicuro per i caratteri. La soluzione ai problemi di versionamento non sarebbe stata molto più preziosa?

Tutti questi problemi hanno portato ad alcuni strumenti come Maven, ivy, One Jar, Jar Jar Links (non scherzo!), Anche giustamente chiamato Jar Hell ecc Anche se si utilizzano alcuni di questi strumenti, si è ben lungi dall'essere immuni al problema. Io uso Maven 2 ed è stato di grande aiuto. Eppure, è un mondo a sé. Il programmatore novizio può impiegare un po 'di tempo per impararlo. Anche spostare i tuoi progetti precedenti nella struttura di Maven è un problema.

Sembra che in. Net abbiano imparato la lezione con dll hell e la gestione degli assembly .Net è molto più semplice.

Sembra che ci siano piani per risolvere questo problema per la piattaforma java e le alternative come OSGI. Penso che sia necessario un certo meccanismo di base delle versioni e delle piattaforme imposto

+0

Questo legge più come un commento che come una domanda. – cletus

+0

Immagino che sia un po 'di entrambi (un commento e un rant). Fondamentalmente volevo vedere se gli altri condividono gli stessi problemi di me. Per anni questo è stato il bisogno più urgente per il mio team e mi sento frustrato dalla mancanza di una soluzione efficiente a questo problema. – Dan

+0

Rant o no, è ancora una domanda legittima. Almeno il titolo è anche se la domanda non viene ripetuta nel corpo del post. – tvanfosson

risposta

4

Dai un'occhiata a OSGi: si occupa molto del controllo delle versioni e della gestione dei pacchetti (jar).

ANCHE: Eclipse (che è costruito su OSGi) ha alcuni strumenti API relativamente nuovi che possono aiutare a confrontare l'API con una linea di base precedente e determinare come esprimere in modo appropriato il numero di versione successivo dei bundle.

Il generale schema eclisse delle versioni:

v.m.n.q 

dove

v: version-alto livello - modifiche qui rappresentano generalmente la rottura cambiamenti nelle API

m: grandi cambiamenti - nuove funzionalità, nuova API

n: modifiche minori - stessa API, modifiche dietro le quinte

q: qualificatore - utile per contrassegnare build, alpha/beta, ecc.

OSGi specifica le dipendenze della versione mediante intervalli.Per esempio

Require-Bundle: com.javadude.foo;bundle-version="[1.2.0,2.0.0)" 

nel vostro MANIFEST.MF specifica che il pacchetto richiede la versione 1.2.0 o successiva di com.javadude.foo fascio, attraverso (esclusi) la versione 2.0.0.

È inoltre possibile specificare dipendenze a livello di pacchetto.

+0

So di OSGI ma non l'ho guardato con maggior dettaglio. Ho avuto l'impressione che potrebbe essere eccessivo per un particolare problema che ho di fronte. Immagino sia ora che gli dessi una seconda occhiata. – Dan

+0

in realtà è piuttosto leggero. al suo livello più semplice, è possibile utilizzarlo per gestire le dipendenze del pacchetto. puoi anche utilizzarlo per fornire servizi per altri pacchetti. –

0

Il vantaggio che .NET ha su Java è che le librerie sono legate più strettamente al sistema operativo. Il fatto che le librerie di framework, se installate, si trovino facilmente nel GAC semplifica le cose, ma sei anche praticamente limitato a Windows. Un confronto migliore sarebbe Mono, ma non ho alcuna esperienza lì.

La gestione della configurazione, almeno per me, è sempre stata la grande sofferenza dello sviluppo del software. Più cerchi di sfruttare il codice esistente, il peggio sembra che diventi. Il problema in sé non è esclusivo di Java, ma la proliferazione delle versioni, la quantità di tempo in cui la piattaforma è stata utilizzata e il numero di piattaforme supportate sembrano peggiorare le cose. Ho appena controllato e ho 3 versioni di JRE sulla mia scatola in questo momento - e non sono nemmeno uno sviluppatore Java attivo.

Per quanto riguarda la tua domanda, non sono sicuro se sia la necessità di funzionalità più urgente. Personalmente, mi piacerebbe vedere un supporto migliore per i servizi web, in particolare quelli che richiedono intestazioni di autenticazione. L'ultima volta che ho provato a far interagire Java con uno dei miei servizi Web .NET, ho quasi strappato i capelli. Avendo usato LINQ con C# /. Net, posso anche dire che sarebbe un'aggiunta molto interessante a Java con probabilmente maggiori guadagni di produttività.

+0

Sembra che l'idea alla base di JSR 277 (http://www.jcp.org/en/jsr/detail?id=277) includesse alcune soluzioni simili, ma sembra essere inattiva. – Dan

+0

Credo che OSGi (http://www.osgi.org/Main/HomePage) offra già molti dei vantaggi di JSR 277 con l'ulteriore vantaggio che esiste realmente. Non è nemmeno complicato. –

0

.NET supporta gli assembly side-by-side, quindi è possibile avere più versioni della stessa applicazione. Il GAC è come DLL condivise, ma è comunque possibile registrare più versioni dello stesso assembly nel GAC e un altro assembly può richiedere una versione certa o maggiore se ricordo bene.In JavaEE avete parecchi livelli classe-loader btw e si può fare alcuni trucchi simulando delle versioni simili

+0

Ma supporta diverse versioni degli stessi assembly nello stesso vm? –

5

Ho anche utilizzando Java per oltre un decennio, ma devo dire che non ho trovato molti JAR inferno problemi (anche utilizzando tutti gli strumenti di terze parti citati)! Ho trovato Maven uno strumento orribile, quindi crea tutto con ant.

Nella nostra azienda abbiamo un compito su misura dipendenza risoluzione ant sulla base di un semplice (piccolo) file di dipendenza per ciascun progetto, nonché di definire ogni progetto sia come app o un lib (si dovrebbe sempre e solo dipendere da un lib mai uno app). Funziona bene.

Abbiamo anche compiti ant per modificare i nostri file eclissi .classpath e IDEA .iml per generare grafici di dipendenze per i nostri IDE.

+0

Potresti trovare Ivy che vale la pena incorporare nel tuo sistema di compilazione. Prende fondamentalmente i meccanismi di risoluzione delle dipendenze di Maven mentre si scollega il resto - http://ant.apache.org/ivy/ – Evan

+0

Dovrebbe anche menzionare, ha anche un plugin per Eclipse - http://ant.apache.org/edera/ivyde/ – Evan

+0

Sono contento di vedere che non sono l'unico maven-hater in circolazione ... –

0

Mi sono imbattuto in questo problema in un sito in cui ho lavorato: creato uno strumento per scorrere i file jar che vivono su un server web e trovare tutte le copie annidate dei file jar e diversi file con lo stesso nome (ad es .: versioni di log4j.jar). Era un pasticcio orribile, inclusa una GUERRA che aveva il contenitore WebLogic all'interno di.

Non so quale sia la soluzione.

Il fatto è: java ha roba da gestire - file jar con timbri con le versioni del pacchetto. E in particolare: webstart. Forse quello che serve è una sorta di classloader che faccia una cosa tipo webstart.

Che ne dite di: nel manifest JAR, si specificano le dipendenze della libreria, utilizzando nomi e versioni noti. Il classloader, fornito dal contenitore o dal runtime, sarebbe responsabile per ottenere le versioni che desideri.

Ci sono molti sistemi (ad esempio: lo stesso Maven) per la gestione di luoghi noti per il download di librerie, nonché fink e quant'altro.