Perché non ci sono alternative del compilatore Java per consentire nuove funzionalità? [chiuso]

0

Ad esempio, un nuovo compilatore java potrebbe consentire una certa retrocompatibilità per consentire cose come l'overloading di tipi generici come:

void foo(List<String> arr);
void foo(List<Integer> arr);

O per consentire cose come i generici su tipi primitivi

void foo(List<int> arr);

Ora non sto suggerendo che si tratti di cambiamenti banali, o che tutti utilizzerebbero un simile compilatore, ma ero curioso di sapere perché non potevo trovare NESSUNA alternativa a javac. Anche se non hai mai modificato le specifiche bytecode, alcune di queste modifiche (e altre) potrebbero essere implementate esclusivamente in fase di compilazione. Se non altro, potrebbe consentire a un banco di prova di unire le modifiche alla linea principale in qualche modo (ho capito che cambiare la semantica del linguaggio significa che non è più "Java", ma chiamiamolo J ++ o qualcosa del genere).

Mi piace la prima mentalità di compatibilità con le versioni precedenti di Java, ma sono rimasto sorpreso dal fatto che questo non sia un approccio che le persone hanno adottato completamente nuovi linguaggi come Kotlin / Ceylon / etc.

C'è ancora qualcosa che impedisce che ciò accada?

    
posta Anthony Kraft 25.02.2015 - 05:36
fonte

3 risposte

2

Penso che questo sia il tipo di cosa che stai postando non esiste:

è una prova dell'esistenza di ciò che stai cercando (ma da 12 anni fa - molte delle funzionalità di quel "compilatore Java esteso" alla fine sono migrate nel vero compilatore Java). Infatti, Java continua a evolversi a un ritmo ragionevole (ok, è discutibile), quindi le "estensioni" al linguaggio vengono considerate e implementate in Java (vedi link )

Ma più in generale, penso che potresti sostenere che Scala ( link ) soddisfa la tua definizione. La sua retrocompatibilità inversa a livello sorgente (la lingua è totalmente diversa), ma genera un output che gira su una JVM vanilla e, in modo più impressionante, è interoperabile con le librerie Java standard.

Anche tutti gli altri linguaggi basati su JVM (come groovy, jruby, jpython, ecc.) rientrano in questa categoria. Vedi link per un elenco più completo. (Si noti che ci sono un paio di voci su quella pagina di Wikipedia che pretendono di essere anche superset di Java.)

Penso che chiunque impiegherebbe del tempo per implementare un Java ++ vorrebbe probabilmente sistemare molte cose. E finirebbe per creare qualcosa di completamente diverso. Molto è stato appreso sulla progettazione della lingua negli ultimi 20 anni e la JVM fornisce un meccanismo di compatibilità che non richiede la compatibilità del codice sorgente.

    
risposta data 25.02.2015 - 08:10
fonte
1

Indietro nel 2004 Microsoft aveva un prodotto chiamato J ++. Ha coinvolto Microsoft in un campo amaro combattere con Sun Microsystems che Microsoft ha perso. Un sacco di cose nell'ecosistema Java sono pesantemente protette dalla proprietà intellettuale e dalla legge sui marchi, e Oracle ha un esercito di avvocati per farla rispettare. Uno dei principali punti di vendita di Java è stata la compatibilità cross-vendor / cross-vendor. Come qualcuno che sta attualmente cercando di ottenere una grossa pila di librerie per costruire tutto bene su Linux usando GCC e su OS X usando Clang I, vedremo il valore in questo.

    
risposta data 25.02.2015 - 05:57
fonte
0

Vorrei aggiungere a P.T. rispondi sopra. Scala come linguaggio di programmazione funzionale che compila in Java bytcode (quindi utilizza JVM) consente un po 'di faticoso gioco FP, ma in entrambi i casi la risposta si risolve in un hack. Ecco un link a una domanda simile precedente per Scala:

link

Sarei titubante nel suggerire che Java 8 potrebbe essere in grado di fornire un simile hack dato che le funzioni sono ora trattate come cittadini di prima classe e possono essere passate come argomenti molto simili a Scala.

    
risposta data 25.02.2015 - 11:51
fonte

Leggi altre domande sui tag