In che modo le chiusure in Java avranno un impatto sulla Java Community?


11

È una delle funzionalità più discusse pianificate per Java: Closures. Molti di noi hanno desiderato ardentemente loro. Alcuni di noi (incluso I) sono diventati un po 'impazienti e si sono rivolti a linguaggi di scripting per colmare il vuoto.

Ma una volta che sono finalmente arrivate le chiusure a Java: come avranno effetto sulla Java Community? L'avanzamento dei linguaggi di scripting con targeting per VM rallenterà la scansione, rimarrà lo stesso o accelera? Le persone affolleranno la nuova sintassi di chiusura, trasformando così le basi di codice Java a 360 ° in implementazioni più strutturate dal punto di vista funzionale? Vedremo solo chiusure sparse in Java per tutto? Quale sarà l'effetto sul supporto strumento / IDE? Che ne dici di prestazioni? E infine, cosa significherà per la continua adozione di Java, come lingua, rispetto ad altre lingue che stanno crescendo in popolarità?

Per fornire un esempio di una delle specifiche della sintassi Java Closure più recenti proposte:

public interface StringOperation {
   String invoke(String s);
}

// ...

(new StringOperation() {
   public invoke(String s) {
       new StringBuilder(s).reverse().toString();    
   }
}).invoke("abcd");    

potrebbe diventare ...

String reversed = { 
    String s => 
    new StringBuilder(s).reverse().toString()
  }.invoke("abcd");

[fonte: http://tronicek.blogspot.com/2007/12/closures-closure-is-form-of-anonymous_28.html]


L'esempio che pubblichi è di molti anni fa - sei sicuro che sia rappresentativo delle proposte attuali?
Daniel Earwicker,

Potrebbe non essere: sentiti libero di rivedere il mio esempio

3
Ultimamente ho smesso di usare Java più o meno. Non vedo ancora l'ora di chiudere.
Anto,

@Daniel - questa non è la proposta attuale, sembra che ce ne sia una più attuale (e molto diversa) qui: baptiste-wicht.com/2010/05/…
Nicole

è come espressione C # lambda?
Louis Rhys,

Risposte:


4

Penso che ci vorrà del tempo prima che molti sviluppatori Java "ordinari" si concentrino su questo concetto se non ne hanno già familiarità, ma a poco a poco faciliterà il normale utilizzo di Java, a tutto vantaggio. Sarebbe bello se fosse abbracciato con la stessa rapidità con cui erano generici quando arrivò Java 5.

Immagino che non influenzerà i linguaggi di scripting mirati della VM tanto quanto è solo uno dei vantaggi dell'utilizzo di quelli che ce l'hanno.


3

C'è un solito ciclo che si accompagna a qualsiasi nuovo strumento brillante:

  • Eccitazione di massa, con una raffica di nuovi utenti che la abusano. Questo è normale e salutare, in quanto ci aiuta a comprendere i limiti del nuovo strumento e come può essere utilizzato.
  • Le persone più riservate si limiteranno a dire e metteranno in imbarazzo i primi utilizzatori
  • Alla fine, l'eccitazione svanisce e i primi utenti si affidano a modi salutari per utilizzare il nuovo strumento
  • Le persone più riservate inizieranno a invidiare la produttività delle persone utilizzando il nuovo strumento e inizieranno ad adottarlo, utilizzando i modelli ora salutari.

Tutto ciò richiede un paio d'anni per scorrere. Era vero per le annotazioni e i generici, e lo sarà anche per le chiusure.

Impatto sulla gente del linguaggio di scripting:

  • Per le lingue che supportano le chiusure, questo aiuterà gli scrittori del linguaggio di script a svolgere il proprio lavoro in modo più efficiente. Dal momento che sanno già come utilizzare le chiusure, non necessariamente faranno cose folli.
  • Per le lingue che non supportano le chiusure, questo sarà in gran parte ignorato.

1

Coloro che apprezzano la programmazione multi-thread saranno in grado di incorporare strutture di dati immutabili in Java e gestirli in modo più fluido, senza la necessità di ricorrere a non-sequencer a causa della discrepanza di impedenza del linguaggio tra Java e Lisp.

Coloro che non usano (o comprendono) nessuno dei precedenti saranno in grado di fare le cose proprio come hanno fatto prima.


1
Questo non ha senso. Le chiusure non hanno nulla a che fare con il threading o la mutabilità.
davidk01,

Loro fanno. Chiusure adeguate richiedono l'immutabilità con cui lavorare senza esplosioni cerebrali.
permeakra,

No, non lo fanno. Una chiusura è un pezzo di codice che conosce l'ambiente in cui è stata creata. Ecco fatto.
davidk01,

1
@ davidk01 la definizione è OK, ma quando la chiusura ha un collegamento a una variabile mutabile, il suo risultato cambia con la variabile modificata. Di solito, questo non è ciò che si desidera, ma se il compilatore non si oppone, l'errore è quasi impercettibile.
permeakra,

1
@ davidk01 No, non lo so. Il mio punto è che le chiusure / lambda funzionano bene se legate all'immutabilità delle variabili catturate. Altrimenti sei in balia di Tzeentch, e solo i devoti adoratori hanno possibilità qui.
permeakra,

1

Sospetto che le persone che hanno familiarità con le chiusure inizieranno a usarle nel codice dell'applicazione. Li eviteranno per un po 'nelle librerie per mantenere la retrocompatibilità con le versioni precedenti di Java.

I programmatori che non hanno familiarità con le chiusure da altre lingue saranno lenti ad adottarli in Java.

I generici sono stati adottati rapidamente quando sono stati introdotti in Java parzialmente a causa di tutti gli avvisi che sono stati mostrati durante l'aggiornamento e per la loro incorporazione nell'SDK. Questo non sarà vero con le chiusure. Sarà più difficile trovare prove della loro esistenza, quindi solo coloro che vogliono usarli li useranno.

Non penso che lo sviluppo di altri linguaggi di scripting JVM si fermerà. Quelle lingue hanno slancio e molte caratteristiche oltre alle chiusure. Potremmo tuttavia vedere meno nuove lingue JVM poiché le chiusure sono state la spinta principale per la creazione di nuove lingue JVM.


Dovresti dare un'occhiata a mseifed.blogspot.se/2012/09/… Penso che sia davvero fantastico!
mmm
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.