Motivi per il fork tecnologico di build tra Java e UNIX / C / Fortran

Question

Motivi per il fork tecnologico di build tra Java e UNIX / C / Fortran

#1 da (3 voti)
#2 da (3 voti)

2

Quando Java è stato sviluppato, i progettisti hanno scelto di scartare una quantità inusuale della saggezza convenzionale stabilita nelle toolchain UNIX e C oriented. Per uno (e secondo me) l'esempio più importante, hanno scelto di scartare la pratica dei file di intestazione e Makefile e hanno cercato invece di compilare un compilatore monolitico, basato sull'importanza delle dipendenze. Successivamente, ant è stato sviluppato per rimediare parzialmente alle carenze (ovvie?) Di questo processo e ha efficacemente reimplementato la logica del makefile.

Non è che mi offendo il make vecchio stile e #include andando fuori bordo. Tuttavia, il loro utilizzo è stato reinventato nel mondo Java con ant e suddivisione di ogni classe in un'interfaccia e una classe di implementazione, che è molto simile al file di intestazione / modello di file di origine. Sono abbastanza sicuro che le persone dietro Java sapessero degli strumenti e dei pattern esistenti e del loro scopo, quindi la decisione di eliminarli prima e poi di reimplementare tutto da zero senza nemmeno un accenno nel design del linguaggio è ciò che mi stupisce. Sarebbero stati disponibili metodi meno costosi (come l'analisi del file sorgente e la generazione automatica di un file di intestazione, che sarebbe stato abbastanza semplice dopo aver eliminato un po 'la sintassi di C), ma non sono stati presi, e mi piacerebbe sapere ragione.

Forchette simili sono state eseguite nella maggior parte degli altri luoghi, a costi di sviluppo considerevoli e al costo considerevole di una comunità divisa. Oggigiorno, Java-world e C ++, gli sviluppatori mondiali hanno spesso difficoltà a comunicare e collaborare a causa di una divisione che sembra sproporzionata rispetto alle effettive differenze tra il linguaggio C / C ++ e il linguaggio Java. Mentre riesco a vedere le motivazioni alla base del processo (tutti detestano la sintassi Makefile e cambiano i file di intestazione manualmente), non riesco ancora a sfruttare l'entità della modifica.

Ci sono riferimenti storici sulla motivazione e le ragioni di questo processo? Ci sono documenti di progettazione o interviste con le persone che hanno guidato questa forcella?

java history motivation

posta thiton 26.10.2011 - 11:30

fonte

2 risposte

Leggi altre domande sui tag java history motivation

Schema mentale per query SQL [chiuso] Best practice per l'elaborazione di un elenco di elementi

score 3 · Answer 1

Dovresti davvero guardarlo da una prospettiva diversa: in Java puoi avere i file header in forma di interfacce. Mentre in realtà hai bisogno di file header in C / C ++.

Later on, ant was developed to partially remedy the (obvious?) deficiencies of this process, and effectively re-implemented the makefile logic.

Vedi la formica come uno strumento per fare le cose, ad es. crea la tua applicazione, distribuiscila o pubblica Javadoc, invece di uno strumento necessario per creare applicazioni Java. Inoltre, Java non è legato alla formica. In modo simile, C / C ++ non è legato ai makefile (sebbene sia di fatto uno standard di settore). Nel mondo Java c'è un notevole movimento verso altri strumenti di costruzione, vale a dire Maven e Gradle , che fornisce funzionalità aggiuntive come la gestione delle dipendenze e la configurazione per eccezione.

Credo che il passaggio dai makefile alle formiche sia stato guidato da un supporto superiore per l'esecuzione delle attività. Inoltre, perché dovresti richiedere i file di intestazione quando non sono richiesti dal compilatore o dallo sviluppatore?

Probabilmente questo non risponde alla tua richiesta di documenti di design e interviste, ma spero che ti dia qualche idea sul perché questo è stato uno sviluppo naturale.

score 3 · Answer 2

Nessun altro linguaggio oltre a quelli che includono C (C ++ e Objective C) usa intestazioni. Né linguaggi che precedono C né nessuno di quelli più recenti.

È perché le intestazioni violano l'importantissimo principio "Non ripetere te stesso": tutte le informazioni sono effettivamente lì nel file sorgente, quindi il compilatore dovrebbe solo generare l'informazione stessa.

In effetti, le intestazioni sono probabilmente un ripensamento anche per C. Nelle prime versioni di C dovresti semplicemente chiamare funzioni senza prototipi e C ancora regole di carie su come gli argomenti sono schierati in questo caso (e sono ancora importanti per le funzioni variadiche). I prototipi sono stati aggiunti e il preprocessore è stato abusato per inserirli e questo si è bloccato. In parte perché si è scoperto che consente di eseguire trucchi sporchi sul compilatore che risultano utili quando si eseguono lavori di basso livello nel sistema operativo e nella libreria standard. Questi trucchi non sono generalmente utili per la programmazione di livello superiore.

Ora, se non hai intestazioni, hai tre opzioni:

genera prima tutte le interfacce e poi compila gli organismi di implementazione
compilare in ordine di dipendenze, ma questo preclude riferimenti circolari
compila tutti i moduli in un'unica esecuzione del compilatore

Java ha scelto l'ultimo. C # ha fatto altrettanto bene come molti altri linguaggi.