Sì, se uno guarda solo la pura funzionalità, la virtualizzazione tipo vmware è la soluzione più immediata e pulita perchè ci funziona sostanzialmente tutto senza perdere tempo con giri di dll e script tipo winetricks. Per me la scelta dipende da quanto sono importanti le prestazioni per l'utente: vmware emula una macchina completa mentre wine si limita a tradurre le chiamate windows in equivalenti linux. Ciò significa che il primo è per forza notevolmente più lento, mentre il secondo spesso va ad una velocità prossima, e spesso uguale, al programma che gira nativamente sotto windows.
asdf wrote in news:XFdKn.172304$ snipped-for-privacy@twister1.libero.it:
Infatti, quello era il dubbio.
Mah, bisogna vedere se il "notevolmente più lento" fa scendere l'applicativo sotto la soglia di utilizzabilità o meno. La mia esperienza in tal senso non è così negativa.
Per dire, molti server aziendali (internet e intranet) in realtà oggi sono server virtuali che girano su una stessa macchina fisica.
Non c'=E8 male. Certo non hai un controllo totale sulla memoria (ma sono pochi i casi in cui =E8 necessario) e c'=E8 qualcosa a cui fare attenzione. Detto questo, nelle ultime versioni delle macchine virtuali il codice gira praticamente a velocit=E0 nativa.
Meno male, perch=E9 c'=E8 un bel po' di lavoro dietro :-) Anche solo il problema di disegnare rapidamente la griglia =E8 molto meno banale di quello uno si aspetta a primo acchito. Non dico che le cose non siano migliorabili, ma l'esperienza montra che i colli di bottiglia non sono per forza l=E0 dove uno si aspetterebbe di trovarli...
Secondo me, il problema non =E8 tanto dovuto alla macchina virtuale, quanto pi=F9 al fatto che ci sono spesso diverse strategie per risolvere uno stesso problema e bisogna avere le idee molto chiare sul peso computazionale di ognuna, perlomeno nei punti critici del programma. Questo diventa molto pi=F9 legato all'uso della libreria standard che al linguaggio in s=E9 medesimo. In Java ci sono tanti modi, per esempio, per concatenare due stringhe e quello pi=F9 comune ha il difetto di essere molto lento. Questo pu=F2 andare benissimo in tante situazioni, salvo in alcuni casi in cui quest'operazione si rivela critica e pu=F2 rappresentare un collo di bottiglia. Non =E8 tanto legato a Java, ma molto di pi=F9 al fatto che il programmatore sta utilizzando il metodo sbagliato per risolvere un problema. La stessa identica problematica la si ritrova anche in C++, utilizzando la libreria standard senza conoscerla adeguatamente.
Io c'ero :-)
Secondo me attorno a Java c'=E8 una cattiva pubblicit=E0 che lo dipinge come un linguaggio "semplice". Nella mia esperienza, Java (e relativa libreria standard) offre delle soluzioni fatte meravigliosamente bene, ma non sono affatto semplici da utilizzare nel migliore dei modi. Nell'esempio di cui sopra relativo alle stringhe, un principiante potrebbe essere tentato da usare un metodo inefficiente per concatenarle in casi critici che meriterebbero maggiore attenzione alla velocit=E0. Tuttavia il fatto che questo metodo sia lento non =E8 un problema di Java, ma una conseguenza della strategia di rappresentazione in memoria degli oggetti (che ha il suo perch=E9 ed ha vantaggi in altre situazioni). Con la stessa strategia, un programma scritto in C++, oppure anche in C od assembly sarebbe altettanto lento. Il problema =E8 quindi di scrivere un programma efficiente in un linguaggio che ha delle caratteristiche che possono diventare delle trappole per qualcuno poco esperto. D'altro canto, personalmente ritengo che il codice che scrivo in Java =E8 molto pi=F9 robusto ed affidabile di quello che scrivo in C++, ma questo =E8 una cosa che =E8 dovuta al fatto che conosco il C++ da 15 anni ma l'ho praticato meno ultimamente, digerendo e studiando solo parzialmente la biblioteca standard definita dallo standard del 1998.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.