mercoledì 29 giugno 2011
Rivendicazione di brevetto di Oracle nei confronti di Google prende un colpo
Red Hat Arquillian app testing technology disponibile dal mese prossimo
di Paul Krill
Servire come coordinatore di prova, Arquillian consente agli sviluppatori di scrivere test di integrazione cui il codice in fase di test viene eseguito in ambiente in cui verrà eseguito in produzione, ha dichiarato Dan Allen, Red Hat, principale ingegnere del software.Già offerto in una fase di release candidate, Arquillian, pronunciato "ar keelian," dovrebbe essere disponibile in una versione finale il prossimo mese, probabilmente come parte delle attrezzature in JBoss Enterprise Application Platform 6.
"Arquillian consente test di integrazione portatile per applicazioni aziendali", ha detto Allen, che ha parlato alla conferenza Jax a San Jose, California, per il Giovedi. Con Arqullian, la comunità JBoss di Red Hat cerca di ridurre l'onere per gli sviluppatori, fornendo un cablaggio semplice test del ciclo di vita di astrarre il recipiente e la distribuzione dalla logica del test. Gli sviluppatori possono produrre una gamma di integrazione per le applicazioni enterprise Java.Arquillian gestisce gli aspetti dell'esecuzione del test, tra cui la gestione del ciclo di vita del contenitore, bundling la classe di test con le classi dipendenti e risorse in un archivio schierabili e l'acquisizione dei risultati e fallimenti.
Mentre inizialmente destinati per Java, i due anni di progetto Arquillian è "ramificazione molto rapidamente", ha detto Allen. E 'già è stato usato per Ruby on Rails test tramite la versione JRuby di Ruby. Inoltre è stato utilizzato con il linguaggio Scala che, come JRuby, gira su Java Virtual Machine. Arquillian è parte dell'iniziativa Testing JBoss. Il nome Arquillian è stato derivato dalle creature che ha combattuto bug nel film "Men in Black", ha detto Allen. "Si può tipo di pensare ad esso come un battler bug."
Il tuo prossimo lavoro: sviluppatore di applicazioni Mobile?
martedì 28 giugno 2011
JavaScript Minifier che non si rompa il codice (in Perl)
Ho cercato un programma di minimizzazione JavaScript che non si rompe codice funzionante ma nessuno apparve. Ho scritto uno in Perl (spero!). Se il codice inserito JavaScript manca un punto e virgola o ha un codice similea + + + b che è ok. I commenti condizionali di Internet Explorer vengono mantenuti nell'output. Il mio codice è stato ispirato da Douglas Crockford JSMin ma è una riscrittura completa per aggiungere queste funzionalità.
Ho caricato il modulo Perl di CPAN JavaScript:: Minifier
Se si desidera scaricare il modulo in questo momento dal mio repository subversion ...
svn co http://dev.michaux.ca/svn/random/JavaScript-Minifier/ cd JavaScript Minifier perl Makefile.PL make test
Sto anche lavorando ad un programma di minimizzazione CSS in Perl che non è ancora ben collaudato: svn co http://dev.michaux.ca/svn/random/CSS-Minifier/
Perché Perl vi chiederete? Perché questo è il linguaggio server-side utilizzato dove lavoro.
Corso Java - Corsi Java - Corsi programmazione Java
Il modello di comando in JavaScript: Encapsulating chiamate Proprietà Funzione
L'operatore punto fa parte di JavaScript incorporato nel paradigma object-oriented. Come tutti i paradigmi integrato in qualsiasi lingua, ci saranno momenti in cui il paradigma non supporta le caratteristiche richieste per una particolare applicazione. Abbiamo bisogno di fuggire il paradigma e costruire le caratteristiche di cui abbiamo bisogno. In JavaScript, costruendo la nostra funzione di operatore punto è un modo indiretto per rendere oggetto chiamate proprietà di funzione e sfuggire il built-in paradigma. Questo apre le porte ad avere Ruby built-in missing_method e mixin. Ciò consente anche di programmazione orientata agli aspetti. Ecco alcuni esempi di rapida costruzione di una proprietà funzione chiamatainviare
per sostituire l'operatore punto di regolare proprietà look-up catena. Questo incapsulamento di una chiamata di funzione dalla proprietàmandare
proprietà funzione è anche conosciuto come "il modello di comando".
Ruby method_missing
var myObj = {inviare: la funzione (metodo) {var val; args var = []; for (var i = 1, len arguments.length =; i
Ruby mixin
var alfa = {pippo: function () {return "alfa pippo";}}; beta var = {bar: function () {return "beta del bar";}}; myObj var = {include: function (mixin) {questo . mixin = this.mixins | | []; this.mixins.push (mixin);}, inviare: la funzione (metodo) {if (questo [metodo]) {return questo [metodo] ();} for (var i = 0, len this.mixins.length =; i
Programmazione orientata agli aspetti
var myObj = {addBeforeFilter: funzione (metodo, filtro) {this.beforeFilters = this.beforeFilters | | {}; this.beforeFilters [metodo] = this.beforeFilters [metodo] | | []; this.beforeFilters [metodo]. push (filtro);}, addAfterFilter: funzione (metodo, filtro) {this.afterFilters = this.afterFilters | | {}; this.afterFilters [metodo] = this.afterFilters [metodo] | | []; this.afterFilters [ . metodo] push (filtro);}, inviare: la funzione (metodo) {var val if (this.beforeFilters [metodo]) {for (var i = 0, len = this.beforeFilters [metodo] lunghezza; i.
Un nuovo paradigma OOP per JavaScript
Quello che segue è la prova di principio che JavaScript incorporato nel paradigma OOP prototipo basato non è il paradigma OOP solo tu puoi utilizzare in JavaScript. Il seguente blocco di codice definisce un nuovo paradigma OOP. Questo paradigma non è una replica di ma è ispirato dalle caratteristiche OOP il Ruby. Questi includono eredità, mixin, super e propertyMissing. Questo nuovo sistema potrebbe essere esteso per includere programmazione orientata agli aspetti e altre opzioni in quanto il nuovo sistema controlla il look-up catena di proprietà.
classi var = {}; defClass funzione (klass, costruttore) {classi [klass] = {costruttore: costruttore, mixin: [], instanceProperties: {}};} function defInstanceProperty (klass, proprietà, valore) {classi [klass] . instanceProperties [proprietà] = valore;} function mixin (klass, mixinKlass) {classi [klass] mixins.push (mixinKlass);.} function estendere (klass, parentKlass) {classi [klass] parentKlass = parentKlass;.} function istanziare (klass) {var tipo di oggetto = {: klass}; args var = [oggetto] for (var i = 1, arguments.length len =; i
Ora usiamo questo nuovo paradigma OOP. Si noti che sotto non usiamo nessuna delle usuali parole chiave OOP JavaScript o zucchero: '.' "Questo",,'[]', 'nuovo'. Perché siamo liberi dal costruito nel paradigma possiamo usare le caratteristiche del nuovo paradigma OOP: eredità, mixin, super, e propertyMissing.
defClass ('Persona', function (self, primo, ultimo) {setInstanceProperty (self, 'prima', prima); setInstanceProperty (self, 'ultimo', ultimo);}); defInstanceProperty ('persona', 'toString', funzione di (auto) {return inviare (self, 'primo') + '' + invio (self, 'ultimo');}); defInstanceProperty ('persona', 'propertyMissing', funzione di (auto) {return 'immobile manca qui ';}); defInstanceProperty (' persona ',' età ', 29); / / per secoli la gente di default sono 29 defClass (' dipendenti ', function (self, primo, ultimo, id) {superConstructorSend (' dipendenti ', auto , primo, ultimo); setInstanceProperty (self, 'id', id);}); estendere ('dipendenti', 'Persona'); defInstanceProperty ('dipendenti', 'toString', funzione di (auto) {return superSend (' dipendente ', l'auto,' toString ') +' '+ invio sé (,' id ');}); defClass (' Manager ', funzione di (auto, primo, ultimo, id, dipartimento) {superConstructorSend (' Manager ', auto, primo, ultimo, id); setInstanceProperty (self, 'reparto', dipartimento);}); estendere ('Manager', 'dipendenti'); defInstanceProperty ('Manager', 'toString', funzione di (auto) {return superSend ('Manager', l'auto, 'toString') + '' + invio (self, 'ufficio');}); var = ted istanziare ('persona', 'Ted', 'Enrico'); inviare (Ted, 'toString'); / / Ted Henry inviare (Ted, 'primo'); / / Ted var = franca istanziare ('Manager', 'Frank', 'Miller', 21, 'Conti'); inviare (Frank, ' toString '); / / Frank Miller 21 defClass Conti (' TheMixin '); mixin (' dipendenti ',' TheMixin '); defInstanceProperty (' TheMixin ',' toString ', funzione di (auto) {return' il disgregatore mixin '; }); defInstanceProperty ('TheMixin', 'foo', funzione di (auto) {return 'foo';}); defInstanceProperty ('TheMixin', 'bar', 'Greep'); inviare (Frank, 'toString') / / il distruttore mixin 21 Conti inviare (Frank, 'foo'); / / l'invio foo (Frank, 'foosdf'); / / proprietà manca qui inviare (Frank, 'età'); / / 29 setInstanceProperty (frank , 'età', 33); inviare (Frank, 'età'); / / 33 inviare (Ted, 'età'); / / 29 inviare (Frank, 'bar'); / / Greep
Sintassi di questo paradigma OOP è tutte le chiamate di funzione. Qualcuno potrebbe dire che non è bella come il built-in basati su prototipi paradigma, ma non è possibile aggiungere zucchero sintattico per la lingua. Se un sistema OOP con le altre funzioni è necessario poi ricadere sulla flessibilità delle chiamate di funzione, come fa questo esempio, è certamente una potente tecnica.
Corso Java - Corsi Java - Corsi programmazione Java
Classi SICP per JavaScript
In Struttura e interpretazione dei linguaggi di programmazione Seconda edizione (SICP) a pagina 182, gli autori introducono il concetto dimessaggio che passa con il seguente esempio in Schema di una funzione complessa costruttore numero.
(Define (make-da-real-imag xy) (define (invio op) (cond ((eq? Op 'real-parte) x) ((eq? Op' imag-parte) y) ((eq? Op ' magnitudo) (sqrt (+ (piazza x) (piazza y)))) (angolo (eq op ') (atan yx)) (altro (errore "Uknown op - MAKE-DA-REAL-IMAG"? op)) )) spedizione)
La cosa importante da notare qui è che il valore restituito dal make-da-real-imag
funzione di costruzione è in realtà una procedura di spedizione che è possibile chiamare con un argomento del messaggio. È possibile inviare messaggi per ottenere la parte reale e la portata dei numeri complessi.
(Definire c (make-da-real-imag 3 4)) (c 'real-parte), 3 (c' imag-parte), 4 (c 'grandezza), 5 (c' angolo); 0,927295218001612 (c ' asdf); ERRORE: Uknown op - MAKE-DA-REAL-IMAG: asdf
Vediamo quello che il codice sopra appare così in JavaScript, la nostralingua franca .
makeFromRealImag funzione (x, y) {funzione spedizione (op) {switch (op) 'realPart' {caso: x ritorno; caso 'imagPart': y ritorno; 'grandezza' caso: return Math.sqrt (x * x + y * y); caso 'angolo': return Math.atan2 (y, x); default: 'op Sconosciuto - makeFromRealImag:' gettare op +;}} spedizione di ritorno;} var c = makeFromRealImag (3, 4); c ('realPart'); / / 3 c ('imagPart'); / / 4 c ('magnitudo'); / / 5 c ('angolo'); / / 0,9272952180016122 c ('asdf'); / / "Sconosciuto op - makeFromRealImag: asdf "
Ora, questo probabilmente non assomiglia a nessun orientato agli oggetti JavaScript che avete visto prima ma illustra un punto importante. In JavaScript, possiamo rappresentare l'idea di un oggetto in funzione dei suoi messaggi. La funzione di costruzione restituisce una funzione di spedizione che hai scritto che può inviare qualsiasi messaggio alcun modo che si desidera. Questo dà immediatamente Spidermonkey di __nosuchmethod__
, Smalltalk è doesNotUnderstand
, e Ruby method_missing
. Roba potente ma purtroppo il codice JavaScript corre sopra molto lentamente.Siamo in grado di muoversi verso uno stile JavaScript più veloce e più familiare.
SICP pagina 223, introduce l'idea di oggetti mutabili, ma il punto più interessante è la variazione della procedura di spedizione.
(Define (make-saldo) (define (prelevare quantità) (if (> = importo equilibrio) (begin (equilibrio set! (- ammontare del bilancio) l'equilibrio)) "fondi insufficienti")) (define (importo del versamento) (set ! saldo (saldo + somma)) equilibrio) (define (invio m) (cond ((eq m? 'recedere) ritirare) ((eq m?' deposito) di deposito) (il resto (errore "Richiesta sconosciuta - MAKE-CONTO "m)))) spedizione) (definire conto (make-conto 10)) ((conto 'deposito) 5), 15 ((conto' recedere) 3), 12
Conversione questo a JavaScript abbiamo le seguenti.
funzione makeAccount (saldo) {funzione ritirare (importo) {if (saldo> = importo) {Bilancia = - importo; equilibrio di ritorno;} return "fondi insufficienti";} deposito funzione (importo) {= saldo + importo; ritorno bilancio;} function spedizione (m) {switch (m) {case 'ritirare': ritorno recesso; 'deposito' caso: cauzione di ritorno; default: buttare "richiesta Sconosciuto - makeAccount:" + m;}} spedizione di ritorno;} var = conto makeAccount (10); conto ('deposito') (5); / / 15 account ('ritirare') (3); / / 12
Il modo in cui la spedizione
funzione funziona per gli account è molto diversa che nel caso dei numeri complessi. Nel caso dei numeri complessi, quando un messaggio è stato inviato alla spedizione
funzione, eseguita l'operazione associata (cioè il metodo) immediatamente. Al contrario, l'account spedizione
funzione restituisce il metodo associato al messaggio e che il metodo può essere chiamato.
Questo è molto simile a come JavaScript reciever.message (arg)
opere sintassi e possiamo passare ad un più familiare stile orientato agli oggetti JavaScript.
funzione makeAccount (saldo) {funzione ritirare (importo) {if (saldo> = importo) {Bilancia = - importo; equilibrio di ritorno;} return "fondi insufficienti";} deposito funzione (importo) {= saldo + importo; ritorno bilancio;} {ritirare ritorno: ritiro, deposito: deposito};} conto var = makeAccount (10); account.deposit (5); / / 15 account.withdraw (3); / / 12
In quest'ultima versione, abbiamo smesso di scrivere la nostra logica spedizione e l'uso di JavaScript proprietà incorporata ricerca. Questo aumenta la velocità in modo significativo. Abbiamo perso la capacità di fare il __noSuchMethod__
tipo di invio quando si utilizzano standard ECMAScript, ma che non sembra essere comunemente utile comunque.
Per il bene leggere i programmatori JavaScript là fuori, si può riconoscere questa ultima versione di oggetti durevoli dal libro di Douglas CrockfordJavaScript: le parti buone .
Trovo interessante che il "eredità" la parola non appare nell'indice SICP è anche se il libro va avanti per attuare programmi complessi come interpreti e compilatori in uno stile di scambio di messaggi. Ciò dimostra questo stile semplice di programmazione orientata agli oggetti si può prendere lontano.
Corso Java - Corsi Java - Corsi programmazione Java
lunedì 27 giugno 2011
Standard Java processo per ottenere un aggiornamento
Eclipse: l'annuale software release è in arrivo
Enterprise l'aggiornamento Java orientata alle nubi PaaS
venerdì 24 giugno 2011
Scalare il JavaScript, scala la tua squadra
Quali sono le specifiche sfide a JavaScript?
Nicholas Zakas : Il "condiviso tutto" la natura del linguaggio è la più grande sfida JavaScript. È possibile impostare un sistema che è ben progettato, e un ingegnere inesperto potrebbe entrare e - casualmente o no -. Cambiare alcuni pezzi chiave della funzionalità ECMAScript 5 aiuta con alcuni che, consentendo di bloccare la modifica di oggetti, ma il natura del linguaggio rimane in gran parte lo stesso e problematico.
Fare lezioni applicabili a grandi gruppi si applicano anche alle squadre più piccole?
Nicholas Zakas: piccole squadre ancora bisogno di costruire soluzioni scalabili, perché si spera, un giorno, la squadra crescerà più grandi. Il vostro sistema dovrebbe funzionare per qualsiasi numero di ingegneri. La prova di un buon progetto è quello di poter passare senza interruzioni da cinque ingegneri a 10 e poi più senza dover cambiare radicalmente il progetto.
Osservazioni in Migrazione da JavaFX Script per JavaFX 2,0
da blogoracle
Introduzione
Essendo stato per alcuni anni, c'è un corpo di lavoro dignitose per JavaFX scritto utilizzando il linguaggio JavaFX Script. Con l'annuncio disponibilità di JavaFX 2.0 Beta, la domanda sorge naturale sulla conversione del codice legacy verso il nuovo JavaFX 2,0 piattaforma. Questo articolo riflette su alcune delle osservazioni incontrati durante il porting del codice sorgente da più di JavaFX Script per il nuovo paradigma JavaFX API.
L'applicazione
Il programma scelto per la migrazione è un'implementazione del gioco Sudoku e serve come applicazione di riferimento per il libro JavaFX - Sviluppare Rich Internet Applications . Il design del programma può essere suddiviso in due componenti principali: (1) L'interfaccia utente (l'ideale JavaFX per la progettazione) e (2) il generatore di puzzle. Per il contesto di questo articolo, il nostro interesse primario risiede nell'interfaccia utente. Il codice generatore di puzzle è stato sollevato da un progetto sourceforge.net ed è scritto interamente in Java.Indipendentemente da quale versione dell'interfaccia utente che scegliamo (JavaFX Script vs JavaFX 2.0), senza modifiche al codice sono state necessarie per il codice generatore di puzzle.
L'interfaccia utente originale per l'applicazione JavaFX Sudoku è stato scritto esclusivamente in JavaFX Script, e come tale è un candidato adatto per la conversione verso il nuovo 2.0 JavaFX modello. Tuttavia, alcuni punti degni di nota sono da segnalare su questo programma. Prima di tutto, è stato scritto nell'arco di tempo che 1,1 JavaFX, dove alcune funzionalità del framework JavaFX sono stati come ancora non disponibile. Citando due esempi, questo programma crea molti dei suoi controlli di interfaccia utente da zero perché il built-in controlli sono stati ancora essere introdotto. Inoltre, il layout grafico dei nodi viene fatta in modo molto manuale, ancora una volta perché gran parte delle funzionalità di layout automatiche erano in movimento al momento. Vale la pena di considerando che questo programma è stato scritto in un momento in cui la maggior parte di noi era appena venuta fino a velocità su questa tecnologia. Si potrebbe pensare che avere la possibilità di ricreare questa applicazione di nuovo, sarebbe stata molto diversa dalla versione attuale.
Confrontando la dimensione del codice sorgente
Si è tentato di convertire ogni file originali JavaFX Script fonte UI (suffisso. Fx) oltre ad una controparte Java. A causa delle differenze caratteristica del linguaggio, ci sono un piccolo numero di file sorgente che esistono solo in una versione o l'altra . La tabella seguente riassume le dimensioni di ogni file sorgente.
JavaFX Script file sorgente | Numero di linee | Numero di caratteri | JavaFX 2.0 Java file sorgente | Numero di linee | Numero di caratteri |
ArrowKey.java | 6 | 72 | |||
Board.fx | 221 | 6831 | Board.java | 205 | 6508 |
BoardNode.fx | 446 | 16054 | BoardNode.java | 723 | 29356 |
ChooseNumberNode.fx | 168 | 5267 | ChooseNumberNode.java | 302 | 10235 |
CloseButtonNode.fx | 115 | 3408 | CloseButton.java | 99 | 2883 |
ParentWithKeyTraversal.java | 111 | 3276 | |||
FunctionPtr.java | 6 | 80 | |||
Globals.java | 20 | 554 | |||
Grouping.fx | 8 | 140 | |||
HowToPlayNode.fx | 121 | 3632 | HowToPlayNode.java | 136 | 4849 |
IconButtonNode.fx | 196 | 5748 | IconButtonNode.java | 183 | 5865 |
Main.fx | 98 | 3466 | Main.java | 64 | 2118 |
SliderNode.fx | 288 | 10349 | SliderNode.java | 350 | 13048 |
Space.fx | 78 | 1696 | Space.java | 106 | 2095 |
SpaceNode.fx | 227 | 6703 | SpaceNode.java | 220 | 6861 |
TraversalHelper.fx | 111 | 3095 | |||
Totale | 2077 | 79.127 | 2531 | 87.800 |
Alcune note su questa tabella sono in ordine:
- Il numero di linee in ogni file è stato determinato eseguendo il comando Unix 'wc-l' oltre ogni file.
- Il numero di caratteri in ogni file è stato determinato eseguendo il comando Unix 'ls-l' oltre ogni file.
- L'esame del codice potrebbe certamente essere molto più rigorosi. Senza formattazione standard è stata effettuata su questi file. Tutti i commenti però sono stati cancellati.
C'era una certa aspettativa che la nuova versione di Java richiede più righe di codice rispetto alla versione originale dello script JavaFX. Come evidenziato da un conteggio del numero totale di linee, la versione Java ha linee di circa il 22% in più rispetto al suo omologo Script FX.
Inoltre, c'è stato un ulteriore aspettativa che la versione Java sarebbe più prolisso in termini di numero totale di caratteri. Di fatto i dati precedenti mostrano che in media i file sorgente Java contiene meno caratteri per riga rispetto ai file FX. Ma non è tutta la storia. Su un ulteriore esame, i file di script fonte FX ha un numero sproporzionato di caratteri vuoti. Perché? A causa della natura di come si sviluppa il codice JavaFX Script. L'oggetto letterale domina FX codice script. La sua non è raro vedere letterali oggetto rientrato a metà della pagina, consumando un sacco di spazi senza senso.
Consumo di RAM
Non è l'analisi più scientifica, l'utilizzo di memoria per l'applicazione è stata esaminata su un sistema Windows Vista eseguendo il Task Manager di Windows e la visualizzazione di quanta memoria è stata consumata dalla versione Sudoku in questione. In parole povere, la versione dello script FX, dopo l'avvio, ha un ingombro di circa 90MB di RAM ed è rimasta praticamente la stessa dimensione. La versione Java iniziato a circa 55MB e ha sostenuto che taglia tutta la sua esecuzione.
What About vincolante?
Probabilmente, l'osservazione più sorprendente la conversione da JavaFX Script per JavaFX 2,0 riguardava la necessità di sincronizzazione dei dati, o la loro mancanza. In JavaFX Script, il mezzo principale per la sincronizzazione dei dati avviene attraverso l'espressione bind (utilizzando la parola chiave "legare"), e forse in misura minore che si dirà "sostituire" cugino. La parola chiave legano non esiste in Java, quindi per JavaFX 2.0 un API Associazione di dati è stato introdotto in sostituzione.
Per dare un'idea della differenza tra le due versioni del programma Sudoku, la tabella che segue indica il numero di lega erano necessari per ogni file sorgente. Per JavaFX Script file, questo è stato accertato, semplicemente contando il numero di occorrenze della legano parola chiave . Come si può vedere, il legame era stato usato di frequente nella versione JavaFX Script (e non prende in considerazione un ulteriore mezzo dozzina o giù di lì " a sostituire " trigger). Il programma di JavaFX 2,0 raggiunge le stesse funzionalità della versione originale JavaFX Script, ma l'equivalente di legame era necessario solo due volte in tutta la versione Java del codice sorgente.
JavaFX Script file sorgente | Numero di Lega | JavaFX successiva file sorgente Java | Numero di "Lega" |
ArrowKey.java | 0 | ||
Board.fx | 1 | Board.java | 0 |
BoardNode.fx | 7 | BoardNode.java | 0 |
ChooseNumberNode.fx | 11 | ChooseNumberNode.java | 0 |
CloseButtonNode.fx | 6 | CloseButton.java | 0 |
CustomNodeWithKeyTraversal.java | 0 | ||
FunctionPtr.java | 0 | ||
Globals.java | 0 | ||
Grouping.fx | 0 | ||
HowToPlayNode.fx | 7 | HowToPlayNode.java | 0 |
IconButtonNode.fx | 9 | IconButtonNode.java | 0 |
Main.fx | 1 | Main.java | 0 |
Main_Mobile.fx | 1 | ||
SliderNode.fx | 6 | SliderNode.java | 1 |
Space.fx | 0 | Space.java | 0 |
SpaceNode.fx | 9 | SpaceNode.java | 1 |
TraversalHelper.fx | 0 | ||
Totale | 58 | 2 |
Conclusioni
Poiché la tecnologia JavaFX 2.0 è così nuovo, e l'esperienza con la piattaforma è la stessa, è possibile e anzi probabile che alcune delle osservazioni notato nel precedente articolo può non applicarsi in altri tentativi di migrazione delle applicazioni. Detto questo, questa prima esperienza indica che il codice migrazione Java sarà probabilmente maggiore, anche se non così ampiamente, rispetto alla fonte originale Script Java FX. Inoltre, anche se molto importante, sembra che i requisiti per la sincronizzazione dei dati via vincolante, può essere significativamente meno con la nuova piattaforma .
Corso Java - Corsi Java - Corsi programmazione Java