Sign in to follow this  

Recommended Posts

.Net non l'ho mai usato, ma sono sicuro che non possa essere peggio di Java.

Praticamente e` la stessa cosa. Penso che l'unica cosa migliore e` Windows.Forms che sembra essere piu` veloce delle corrispondenti librerie GUI di java e piu` uniforme col resto di windows di quanto riuscirebbe mai a fare java (ma non ha il problema di essere multipiattaforma).

Ed essendo di Microsoft, almeno la documentazione sarà ottima.

La documentazione, almeno quella del framework, e` orribile rispetto ai javadoc delle API di java. Molto spesso si fa` prima con intellisense piuttosto che usare la guida.

Java, al contrario, non è solo lentissimo,

Il collo di bottiglia spesso e` la GUI, naturalmente anche senza GUI e` tra uno e due ordini di grandezza piu` lento di C++, ma l'unico modo per essere veloci quanto il C++ e` essere il C++.

Anche .net piu` o meno naviga nelle stesse acque.

orrendo tecnologicamente

Apparte il fatto che l'architettura tecnologica di .net differisce solo in dettagli da quella di java non condivido il tuo giudizio. La tecnologia di .net/java e` estremamente interessante.

e disgustoso esteticamente:

Non capisco se ti riferisci sempre alla GUI oppure a qualche altro aspetto estetico.

ha concretamente reso peggiore la mia vita, sia come utente che come sviluppatore. Posso dire con assoluta certezza che se Java non fosse mai esistito il mondo sarebbe un posto migliore.

Pero` ha reso (e continua a rendere) concretamente possibile sviluppare applicazioni realmente multipiattaforma cosa che, con ogni probabilita`, .net non fara` mai.

Share this post


Link to post
Share on other sites

Sembra che ci sia stata una fondamentale incomprensione: non avevo alcuna intenzione di intavolare una discussione con i fan di Java. Il giorno in cui vorrò partecipare a un dibattito di tale livello intellettuale mi metterò a parlare col mio mousepad.

Praticamente e` la stessa cosa. Penso che l'unica cosa migliore e`

In italiano, per favore.

(ma non ha il problema di essere multipiattaforma).

www.mono-project.com

La documentazione, almeno quella del framework, e` orribile rispetto ai javadoc delle API di java. Molto spesso si fa` prima con intellisense piuttosto che usare la guida.

Tanto meglio. L'ideale sarebbe che la gente non usasse né Java né .net.

Il collo di bottiglia spesso e` la GUI, naturalmente anche senza GUI e` tra uno e due ordini di grandezza piu` lento di C++, ma l'unico modo per essere veloci quanto il C++ e` essere il C++.

Ma lol. Solo un javista potrebbe vedere C++ come il vertice irraggiungibile dell'efficienza. Stendiamo una cotta di maglia pietosa.

Apparte il fatto che l'architettura tecnologica di .net differisce solo in dettagli da quella di java non condivido il tuo giudizio. La tecnologia di .net/java e` estremamente interessante.

Dipende da cosa stiamo considerando. Il bytecode, il JITC etc. sono cose decenti. Infatti, un programma scritto in Java che esegua dei semplici algoritmi di benchmark può tranquillamente eguagliare la performance di un programma C. La rete è piena di benchmark di questo tipo fatti da fan di Java.

Se parliamo del linguaggio Java, bleh. Se parliamo del sistema runtime, doppio bleh. Se parliamo delle librerie Java, triplo bleah carpiato con avvitamento.

Non capisco se ti riferisci sempre alla GUI oppure a qualche altro aspetto estetico.

Mi riferisco all'estetica di Java visto dal lato dello sviluppatore, non dell'utente. Quando vedo il sorgente di un programma Java provo sempre un moto di disgusto. Quando poi penso alla roba fatta da Jakarta... basta, basta, ho mangiato da poco.

Pero` ha reso (e continua a rendere) concretamente possibile sviluppare applicazioni realmente multipiattaforma cosa che, con ogni probabilita`, .net non fara` mai.

Ma chi è che scrive applicazioni in Java? Di applicazioni multipiattaforma ne conosco tante, e sono scritte in gran parte in C o C++, il resto in Python, Basic e chi più ne ha più ne metta. Le applicazioni Java le usano solo i fanatici di Java, oppure quei poveretti che non hanno un'alternativa a disposizione (la gente che usa NeoOffice/J su OS X, per esempio).

Il problema della compatibilità binaria interessa giusto a Sun e a Microsoft, una ricompilazione non ha mai ucciso nessuno. Il vero problema nello sviluppo di applicazioni multipiattaforma è avere dei framework multipiattaforma, specialmente per la GUI, e Java offre la soluzione peggiore che io conosca.

Share this post


Link to post
Share on other sites

Sembra che ci sia stata una fondamentale incomprensione: non avevo alcuna intenzione di intavolare una discussione con i fan di Java.

Non sono un fan di java, non sono un fan di .net, non sono un fan della apple. Non sono fan di niente.

In italiano, per favore.

sed -e 's/e`/sia/'

www.mono-project.com

Ovviamente. Pero`, da sviluppatore .net ti dico che in .net e` tanto facile chiamare un bell'oggettino COM oppure usare una dei tanti oggetti nel framework .net che funzioneranno sempre solo su windows che lo faranno quasi tutti e vaffanzum alla portabilita`.

Ma lol. Solo un javista potrebbe vedere C++ come il vertice irraggiungibile dell'efficienza. Stendiamo una cotta di maglia pietosa.

Suppongo che tu sia informato che usando la metaprogrammazione template il C++ riesce, in alcuni casi, ad andare piu` veloce del C e anche del FORTRAN compilato.

Dipende da cosa stiamo considerando. Il bytecode, il JITC etc. sono cose decenti. Infatti, un programma scritto in Java che esegua dei semplici algoritmi di benchmark può tranquillamente eguagliare la performance di un programma C.

Non capisco cosa c'entrino le performance con l'architettura tecnologica.

Mi riferisco all'estetica di Java visto dal lato dello sviluppatore, non dell'utente. Quando vedo il sorgente di un programma Java provo sempre un moto di disgusto.

Suppongo che tu abbia anche delle argomentazioni.

Ma chi è che scrive applicazioni in Java?

Non saprei, IBM per esempio? Per il resto ho visto diverse applet scritte in java e ti puoi anche fare un giro su sourceforge.

Il problema della compatibilità binaria interessa giusto a Sun e a Microsoft, una ricompilazione non ha mai ucciso nessuno. Il vero problema nello sviluppo di applicazioni multipiattaforma è avere dei framework multipiattaforma, specialmente per la GUI, e Java offre la soluzione peggiore che io conosca.

La ricompilazione non la puoi fare con un applet. Inoltre l'uso del bytecode al posto del binario risolve molti problemi difficilmente risolvibili (o impossibili da risolvere) col solo binario (i.e. Fragile Base Class, runtime safety...)

Share this post


Link to post
Share on other sites

Suppongo che tu sia informato che usando la metaprogrammazione template il C++ riesce, in alcuni casi, ad andare piu` veloce del C e anche del FORTRAN compilato.

Se anche Java a volte riesce a battere il C, figuriamoci se non può farlo il C++. Il punto è che tu giustificavi la (presunta) lentezza del linguaggio Java col fatto che "non è il C++", e "a meno di non essere il C++" bisogna rassegnarsi a restare indietro di "uno o due ordini di grandezza". Che era una tale cazzata da farmi bollire il sangue nelle vene. Se non lo dirai più sarò contento.

Non capisco cosa c'entrino le performance con l'architettura tecnologica.

Hai deciso tu che si dovesse parlare di architettura. Io facevo semplicemente un esempio di come non tutta la tecnologia di Java fosse da buttare. E siccome la tecnologia è tale perché è finalizzata ad ottenere risultati pratici, le performance sono importanti.

Suppongo che tu abbia anche delle argomentazioni.

Non è una cosa che vada argomentata. O uno vede subito lo schifo, oppure è una creatura corrotta inferiore anche agli animali (programmatore Java) e non vale la pena di cercare di aprirgli gli occhi.

Non saprei, IBM per esempio?

Eclipse? Lo usano soprattutto gli sviluppatori Java, non è una coincidenza. ;-)

Per il resto ho visto diverse applet scritte in java e ti puoi anche fare un giro su sourceforge.

Le applet sono morte da anni.

La ricompilazione non la puoi fare con un applet.

Welcome to 2005, gli applet non si fanno più.

Inoltre l'uso del bytecode al posto del binario risolve molti problemi difficilmente risolvibili (o impossibili da risolvere) col solo binario (i.e. Fragile Base Class, runtime safety...)

Il problema della FBC è tutt'altro che irrisolvibile. Objective-C non ce l'ha. SOM (la tecnologia di IBM su cui, fra l'altro, si basava OpenDoc) non ce l'aveva.

La sicurezza è un punto forte di Java, ma non è vero che non si possa gestire con codice nativo. La situazione è peggio di quello che dovrebbe essere per via di tecnologie hardware obsolete come la IA32 (la sua MMU non distingue i permessi di lettura da quelli di esecuzione, quindi qualsiasi cosa stia in RAM è sempre eseguibile, anche se ci sono dei work-around) e di sistemi operativi antiquati (la granularità dei permessi di Unix è insufficiente).

Resta il fatto che per le applicazioni cross-platform Java è superfluo. In effetti, sono anni che Sun va in cerca di un mercato per Java. Sul desktop è morto quasi subito, principalmente per via dei suoi ridicoli toolkit per la GUI; gli applet sono morti; ora si sono buttati sul lato server e sul mobile, chissà che non sia la volta buona (spero di no).

Share this post


Link to post
Share on other sites

Se anche Java a volte riesce a battere il C, figuriamoci se non può farlo il C++. Il punto è che tu giustificavi la (presunta) lentezza del linguaggio Java col fatto che "non è il C++", e "a meno di non essere il C++" bisogna rassegnarsi a restare indietro di "uno o due ordini di grandezza". Che era una tale cazzata da farmi bollire il sangue nelle vene. Se non lo dirai più sarò contento.

1. Che java batta il C nella vita reale ha la stessa probabilita` che Pannella diventi papa, tanto per fare un esempio

2. Spero che tu non stia cercando di dirmi che c'e` un linguaggio piu` veloce del FORTRAN, perche' mi farei una grossa risata e la questione sarebbe finita qui.

Hai deciso tu che si dovesse parlare di architettura. Io facevo semplicemente un esempio di come non tutta la tecnologia di Java fosse da buttare. E siccome la tecnologia è tale perché è finalizzata ad ottenere risultati pratici, le performance sono importanti.

Ma magari il risultato pratico che si vuole ottenere non e` la preformance.

Non è una cosa che vada argomentata.

Ah, ecco. E` una specie di verita` rivelata. Be' forse stanotte mi apparira` l'arcangelo gabriele e capiro`.

Le applet sono morte da anni.

Welcome to 2005, gli applet non si fanno più.

Non le vedrai tu. E` solo perche' ora va` di moda fare tutto server-side.

Il problema della FBC è tutt'altro che irrisolvibile. Objective-C non ce l'ha.

Falso. Non ce l'ha per le chiamate ai metodi ma per la dimensione complessiva dell'oggetto, se non ricordo male.

La sicurezza è un punto forte di Java, ma non è vero che non si possa gestire con codice nativo.

Da questo non si scappa. Per avere la stessa sicurezza di Java con il codice nativo o si fanno fare i controlli sui tipi dal processore oppure si interpreta il codice.

Resta il fatto che per le applicazioni cross-platform Java è superfluo.

In realta` in questo mondo sono le applicazioni cross-platform ad essere superflue, si sviluppa per windows su architettura intel, buonanotte linux, buonanotte mac. Su windows microsoft ha adeguatamente affondato java per applicazioni desktop.

Share this post


Link to post
Share on other sites

1. Che java batta il C nella vita reale ha la stessa probabilita` che Pannella diventi papa, tanto per fare un esempio

0. Piantala di usare ` al posto di scrivere le lettere accentate, siamo nel 2005 e perfino le shell unix gestiscono utf-8 in qualche modo.

2. Spero che tu non stia cercando di dirmi che c'e` un linguaggio piu` veloce del FORTRAN, perche' mi farei una grossa risata e la questione sarebbe finita qui.

1. La questione non è mai neanche cominciata, Java fa schifo e basta.

2. Più che altro, è difficile trovare dei compilatori più veloci dei compilatori Fortran.

3. Comunque, di che diavolo stai parlando? Eri tu a sostenere che non c'è nulla di più veloce del C++, e io ne ridevo. Ora rispondi come se fossi stato io ad affermarlo? WTF!

Ma magari il risultato pratico che si vuole ottenere non e` la preformance.

La performance non è un risultato pratico, è un attributo del modo in cui l'eventuale risultato è ottenuto. Non puoi dire "questa tecnologia produce performance", o "l'output di questo programma è la performance": non ha senso. Non riesci a mettere in fila tre parole senza provocare un olocausto linguistico?

Ah, ecco. E` una specie di verita` rivelata. Be' forse stanotte mi apparira` l'arcangelo gabriele e capiro`.

Non è una verità rivelata, è un fatto che appare evidente alle menti normali. Ma c'è sempre qualche deviante... le persone a cui piace Java probabilmente si eccitano a vedere foto di cadaveri o cose simili.

Non le vedrai tu. E` solo perche' ora va` di moda fare tutto server-side.

No, è perché il progresso delle tecnologie client-side (ECMAScript, DOM... mettiamoci pure Flash) ha reso disponibili delle alternative migliori per fare praticamente tutto quello che nei tempi bui si faceva con le applet.

Falso. Non ce l'ha per le chiamate ai metodi ma per la dimensione complessiva dell'oggetto, se non ricordo male.

Ok, hai ragione: Objective-C non ha il problema FBC per i metodi, ma l'ha per le variabili d'istanza; SOM non ce l'ha per niente; Dylan nemmeno, che io sappia. Ad ogni modo, non è un problema del codice nativo, è semplicemente C++ che è scarso.

Da questo non si scappa. Per avere la stessa sicurezza di Java con il codice nativo o si fanno fare i controlli sui tipi dal processore oppure si interpreta il codice.

Mi sa che non stiamo parlando della stessa cosa.

In realta` in questo mondo sono le applicazioni cross-platform ad essere superflue, si sviluppa per windows su architettura intel, buonanotte linux, buonanotte mac. Su windows microsoft ha adeguatamente affondato java per applicazioni desktop.

Java sul desktop l'ha affondato Sun quando ha deciso di gestire la GUI con codice Java al 99%, mettendo l'interfaccia con il sistema grafico della piattaforma ospite all'ultimo 1%. E il loro codice GUI scritto in Java era lentissimo (e, almeno su Mac, continua ad esserlo). Se avessero messo l'interfaccia con la GUI nativa molto più in alto, presentando un'interfaccia Java uniforme ma demandando il più possibile del lavoro al codice nativo della piattaforma ospite, forse le applicazioni Java sarebbero state utilizzabili.

Share this post


Link to post
Share on other sites

0. Piantala di usare ` al posto di scrivere le lettere accentate, siamo nel 2005 e perfino le shell unix gestiscono utf-8 in qualche modo.

Sono abituato da anni ad usare il layout USA per la tastiera. Mi dispiace che tu non riesca a tollerare neanche queste piccole differenze negli altri.

1. La questione non è mai neanche cominciata, Java fa schifo e basta.

Se hai una mentalita` cosi` chiusa non vale la pena continuare questa discussione.Continua pure a vivere nel tuo piccolo mondo e a valutare tutti solo con le tue metriche personali. Stavo semplicemente cercando di mostrarti un altro punto di vista.

2. Più che altro, è difficile trovare dei compilatori più veloci dei compilatori Fortran.

La velocita` del compilatore non era argomento di discussione.

3. Comunque, di che diavolo stai parlando? Eri tu a sostenere che non c'è nulla di più veloce del C++, e io ne ridevo. Ora rispondi come se fossi stato io ad affermarlo? WTF!

Ti pregherei di rileggere le mie affermazioni, ho detto che per essere veloci come il C++ bisogna essere il C++. Il C, in media, e` piu` veloce del C++ (ma non di tanto) e il confronto l'ho fatto con il C++, piuttosto che con il C, perche' offre un insieme di feature piu` vicino a java (rispetto al C).

La performance non è un risultato pratico, è un attributo del modo in cui l'eventuale risultato è ottenuto.

Provo a scrivertelo un'altra volta in modo che, forse, anche con la tua scarsa elasticita` mentale riesca a capirlo: non sempre la velocita` di esecuzione e` la priorita`.

Non puoi dire "questa tecnologia produce performance", o "l'output di questo programma è la performance": non ha senso. Non riesci a mettere in fila tre parole senza provocare un olocausto linguistico?

Io non capisco perche' in questa discussione tu non riesca a mettere in fila tre parole senza offendere me o la sun o i programmatori java.

Non è una verità rivelata, è un fatto che appare evidente alle menti normali. Ma c'è sempre qualche deviante... le persone a cui piace Java probabilmente si eccitano a vedere foto di cadaveri o cose simili.

Vedi sopra.

Ok, hai ragione: Objective-C non ha il problema FBC per i metodi, ma l'ha per le variabili d'istanza; SOM non ce l'ha per niente; Dylan nemmeno, che io sappia. Ad ogni modo, non è un problema del codice nativo, è semplicemente C++ che è scarso.

Non metto in dubbio che sia possibile risolverlo, pero` al momento che si sceglie di risolverlo si sceglie di perdere performance (perche' vanno fatti controlli aggiuntivi, e perche' vengono salvate informazioni in piu`).

Java sul desktop l'ha affondato Sun quando ha deciso di gestire la GUI con codice Java al 99%, mettendo l'interfaccia con il sistema grafico della piattaforma ospite all'ultimo 1%. E il loro codice GUI scritto in Java era lentissimo (e, almeno su Mac, continua ad esserlo). Se avessero messo l'interfaccia con la GUI nativa molto più in alto, presentando un'interfaccia Java uniforme ma demandando il più possibile del lavoro al codice nativo della piattaforma ospite, forse le applicazioni Java sarebbero state utilizzabili.

Sono d'accordo. Questa scelta venne fatta per semplificare il porting e non ha pagato. Pero`, secondo me, parte della colpa continua ad essere di microsoft, a cui un linguaggio multipiattaforma non faceva per niente comodo.

Share this post


Link to post
Share on other sites

Avevo perso questo messaggio. Colgo l'occasione per segnalare a chi di dovere che la funzione "nuovi messaggi" va un po' a caso: mi capita abbastanza spesso che non mostri tutti i messaggi nuovi.

Sono abituato da anni ad usare il layout USA per la tastiera. Mi dispiace che tu non riesca a tollerare neanche queste piccole differenze negli altri.

Esatto, non tollero la gente che s'inventa una grammatica tutta sua perché è abituata a scrivere col telefonino o altre cose. Non ci vuole un ***** a modificare il layout US per avere gli accenti subito disponibili come dead keys; se non ce la fai, piuttosto scrivi in inglese.

Se hai una mentalita` cosi` chiusa non vale la pena continuare questa discussione.

Proprio come avevo detto fin dall'inizio. Con il tempo sei arrivato alle mie stesse conclusioni, ma ti saresti risparmiato della fatica se ti fossi fidato subito di me. Lo stesso vale per Java.

Continua pure a vivere nel tuo piccolo mondo e a valutare tutti solo con le tue metriche personali. Stavo semplicemente cercando di mostrarti un altro punto di vista.

Già visto.

La velocita` del compilatore non era argomento di discussione.

Scusa, cortocircuito mentale. Volevo dire: è difficile trovare dei compilatori che generino codice più veloce dei compilatori Fortran. Non è il linguaggio ad essere "più veloce" (qualsiasi cosa tu volessi dire), è che per via dei suoi campi di applicazione i compilatori Fortran sono sempre stati ottimizzati per produrre il codice più veloce possibile. Non ricordo più cosa ciò avesse a che fare con le mie affermazioni su Java, ma l'inevitabile conclusione è che io ho ragione e tu torto.

Ti pregherei di rileggere le mie affermazioni, ho detto che per essere veloci come il C++ bisogna essere il C++. Il C, in media, e` piu` veloce del C++ (ma non di tanto) e il confronto l'ho fatto con il C++, piuttosto che con il C, perche' offre un insieme di feature piu` vicino a java (rispetto al C).

Ok, ho capito, volevi dire che per essere esattamente veloci come il C++, né un filo di più né di meno, bisogna essere il C++. Molto significativo, devo dire che mi hai aperto gli occhi. Potrei comunque definire un linguaggio a oggetti D-- con una sintassi diversa dal C++ ma con caratteristiche compatibili, e implementarlo tramite un front-end che trasforma il codice D-- in codice C++ (nulla di nuovo, già fatto per molti altri linguaggi), e lo butta nel tuo compilatore C++. In questo modo potrei facilmente scrivere una versione D-- del tuo programma C++ che produce lo stesso identico codice, e quindi ha velocità identica.

Non so neanche più di che stiamo parlando.

Provo a scrivertelo un'altra volta in modo che, forse, anche con la tua scarsa elasticita` mentale riesca a capirlo: non sempre la velocita` di esecuzione e` la priorita`.

D'accordo, ma la mia affermazione di partenza, che poi stavo cercando di dimostrare, era "non tutta la tecnologia Java è da buttare". Non capisco perché mi contesti.

Io non capisco perche' in questa discussione tu non riesca a mettere in fila tre parole senza offendere me o la sun o i programmatori java.

1. Credo che il problema principale sia il fatto che siete un branco di necrosodomiti, e quindi gli insulti ve li tirate un po' addosso.

0. Non esiste alcuna discussione.

Non metto in dubbio che sia possibile risolverlo, pero` al momento che si sceglie di risolverlo si sceglie di perdere performance (perche' vanno fatti controlli aggiuntivi, e perche' vengono salvate informazioni in piu`).

Ho capito dove vuoi arrivare. Sacrificare un 2% di performance con il codice nativo sarebbe un'onta inaccettabile, quindi passiamo a Java che va più lento "di due ordini di grandezza" (parole tue). E' come mettere le mani avanti: "guardate, noi non stavamo neanche provando ad avere prestazioni decenti, anzi sinceramente ci fa un po' schifo, quindi non lamentatevi se siamo lenti". E nessuno vi può più dire niente. Geniale.

Sono d'accordo. Questa scelta venne fatta per semplificare il porting e non ha pagato. Pero`, secondo me, parte della colpa continua ad essere di microsoft, a cui un linguaggio multipiattaforma non faceva per niente comodo.

Però su Mac Java è sempre andato peggio che su Windows. Qual è il movente di Apple?

Share this post


Link to post
Share on other sites

Esatto, non tollero la gente che s'inventa una grammatica tutta sua perché è abituata a scrivere col telefonino o altre cose. Non ci vuole un ***** a modificare il layout US per avere gli accenti subito disponibili come dead keys; se non ce la fai, piuttosto scrivi in inglese.

Faccio piu` veloce cosi`, grazie per l'interessamento.

Proprio come avevo detto fin dall'inizio. Con il tempo sei arrivato alle mie stesse conclusioni, ma ti saresti risparmiato della fatica se ti fossi fidato subito di me. Lo stesso vale per Java.

In generale noto una certa ristrettezza di vedute in buona parte degli utenti mac. E` una vera delusione.

Non è il linguaggio ad essere "più veloce" (qualsiasi cosa tu volessi dire)

Lo e`. Un programma scritto in FORTRAN e` mediamente piu` veloce dell'equivalente C.

Ok, ho capito, volevi dire che per essere esattamente veloci come il C++, né un filo di più né di meno,

Vuoi fraintendere: chi sono io per impedirti di seguire la tua volonta` e renderti ridicolo?

D'accordo, ma la mia affermazione di partenza, che poi stavo cercando di dimostrare, era "non tutta la tecnologia Java è da buttare". Non capisco perché mi contesti.

Ma non c'e` una discussione, l'hai detto tu stesso. Quindi perche' stavi cercando di dimostrare qualcosa?

1. Credo che il problema principale sia il fatto che siete

Te lo ripeto: non sono un fan di java. Sono conscio di correre il rischio di passare per fan di java, ma era inevitabile rispondendo a "Java = tutta *****".

Ho capito dove vuoi arrivare. Sacrificare un 2% di performance con il codice nativo sarebbe un'onta inaccettabile, quindi passiamo a Java che va più lento "di due ordini di grandezza" (parole tue). E' come mettere le mani avanti: "guardate, noi non stavamo neanche provando ad avere prestazioni decenti, anzi sinceramente ci fa un po' schifo, quindi non lamentatevi se siamo lenti". E nessuno vi può più dire niente. Geniale.

runtime type safety.

Però su Mac Java è sempre andato peggio che su Windows. Qual è il movente di Apple?

apple ha attraversato un lungo momento difficile.

Share this post


Link to post
Share on other sites

Comunque i giochijava per cellulari vanno forte, eh.

Non lo so, il mio cellulare non ce li ha i giochijava. Pero` ho visto un sony-ericsson che va` in NullPointerException se premi un tasto mentre carichi un giocojava.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this