Newsgroup: it.comp.java
Titolo: Gap tra Java e C#

Salve,
 
mi sembra che Java non stia più al passo con C# per quanto riguarda 
varie features, addirittura leggevo che probabilmente Java sarà 
sostituito da Scala. Sapete se Oracle ha intenzione di aggiornare Java 
in modo da colmare le differenze?
 
Grazie
 


uscendo dalla disputa personale fra i due linguaggi, che secondo me ha 
zero significato, sia java che c# soffrono degli stessi problemi di 
inadeguatezza rispetto alla complessità richiesta dai programmi attuali.
se da una parte c'è scala dall'altra la microsoft mette sul piatto f#. il 
problema è che per quanto si possano aggiungere "features" e scimmiottare 
altri paradigmi (closure, delegates) restano due linguaggi imperativi, 
strutturati e object-oriented, con semantica / sintassi relativamente 
semplice, i quali tendono (chi più, chi meno) a spostare la complessità 
della soluzione sull'ingegnerizzazione trasformandola spesso in 
sovraingegnerizzazione con tutte le complicanze del caso (tanto codice da 
scrivere e debuggare, side effects, etc...).
 
 

 ha scritto:

Pensi che i linguaggi funzionali siano più adatti?
 
Comunque a parte questo discorso ero solo curioso di conoscere la 
situazione di Java rispetto a C#.
 

 situazione di Java rispetto a C#.
 
i due linguaggi non sono antagonisti per cui il confronto è pura 
accademia. voglio dire, se il tuo ambiente è la jvm puoi usare (dei due) 
solo java, se invece è .net/mono puoi usare solo c#. 

 situazione di Java rispetto a C#.
 
 
Se si parla di piattaforma, pur non conoscendo C#, mi azzardo a dire che 
dubito possa attualmente esistere un ambiente più rigoglioso della JVM. 
Se ci pensi ci sono decine di linguaggi, alcuni dei quali moderni, che 
compilano in bytecode Java. Qualche esempio che mi viene in mente:
 
-Scala
-Groovy
-Jython
-Clojure (se ti interessano i linguaggi funzionali, questo è un dialetto 
lisp usato da Google)
-Ceylon
-Rhino (implementazione di Javascript)

 ha scritto:

Anche su .NET ci sono un sacco di linguaggi, comunque era un confronto più 
legato ai linguaggi che alle piattaforme.
 

il 28.12.2012 10:45, Scrive Midnightmare 174753372:

Hai mai usato JConsole? Provaci e fai un confronto con la miseria della 
gestione attività di windows (includendo la possibilità di osservare ed 
interagire con le jvm attive remotamente). Per me è un motivo più che 
sufficiente per mettere Java ben al di sopra dell'ambiente .net.
 
 


 
Tanto per curiosità, sapresti fare una lista?
 
-- 
Longion: "A parte che non sai di cosa stai parlando Figlio, Padre e Spirito
  Santo sono nella Trinita' la stessa persona"

 Tanto per curiosità, sapresti fare una lista?
 
Basta cercare un attimo:
http://it.wikipedia.org/wiki/Microsoft_.NET#Linguaggi_di_programmazione_.NET
 
 
Poi non so il livello di sviluppo, ma parlando di .NET a me interessava solo C#.
 
 

Dr.Ugo Gagliardelli <do.no...@me.please> ha scritto:

Si ma come dicevo ero interessato al confronto dei linguaggi, a 
prescindere dal fatto che in base alla piattaforma la scelta tra i due 
diventi obbligata.
 


Ad occhio mi pare un pò meno interessante. Ad esempio C# fa il paio con 
Java, poi visual basic non è certo un linguaggio moderno. Resta F# che 
potrebbe fare il paio con Clojure. Per il resto ci sono linguaggi già 
esistenti come python integrati nell'ambiente .NET.
 
In Java vedo nuovi linguaggi come Scala, Groovy Ceylon, quindi mi pare 
un pò più avvincente la cosa ;)


 diventi obbligata.
 
la comparazione è presto detta:
http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java
 
sicuramente c# ha molti più "yes" di java, resta da capire se ciò ne fa 
davvero un linguaggio diverso. per quella che è la mia modesta e limitata 
esperienza in c# si continua fondamentalmente a programmare a oggetti 
solo con pattern diversi rispetto a java. è vero che, ad esempio, c'è 
l'overload degli operatori, ma non è che si spinge più di tanto perché in 
un'ottica di programmazione imperativa e a oggetti tendi a generare solo 
incomprensione del codice. quello che voglio dire è che potrebbero anche 
smettere di aggiungere "features" perché tanto chi nasce tondo non 
diventa quadro.
 

 solo java, se invece è .net/mono puoi usare solo c#.
 
Se non ricordo male, J# era un porting di Java su .NET
 
Enrico

 legato ai linguaggi che alle piattaforme.
 
Che non ha senso visto che, secondo me, confrontare i due linguaggi in 
questione senza prendere in esame la piattaforma su cui girano non ha senso
 
Enrico


In buona sostanza sì, ma ormai sono 7-8 anni che non è più presente in 
Visual Studio.
 
 
 
fe...@delenda.net
 
-- 
http://delendanet.blogspot.com
 

 questione senza prendere in esame la piattaforma su cui girano non ha senso
 
Per me andrebbe fatto anche un discorso piu' terra a terra:
cosa ci fai con java e cosa ci fai con c#
 
(perchè a livello di mera sintassi shimo, i linguaggi sono molto simili)
 
c# sei legato all'ambiente microsoft (vabeh il discorso mono...)
java hai android, dispositivi embedded
 
 
windows phones per ora non compete significativamente
con android...
 
 
ciao, Jasmine
 

 java hai android, dispositivi embedded
 
Le differenze non sono solo queste, ma anche molte altre. Ad esempio, C# 
permette un'interazione con il sistema operativo molto piu` semplice 
rispetto a Java, che deve ricorrere necessariamente a JNI o a JNA (molto, ma 
molto meno documentato rispetto al primo) per fare la stessa cosa
 
Enrico

il 07.01.2013 23:00, Scrive Enrico 'Henryx' Bianchi 319932412:

Ovviamente questa considerazione vale *solo* per un unico sistema 
operativo, Windows appunto. Sia per definizione che per indole del 
produttore.
Altri produttori permettono interazioni strette con il sistema operativo 
senza ricorrere obbligatoriamente al JNI, ed aperte all'utilizzo, oltre 
che con Java anche con altri linguaggi.
M$ se ne guarda bene.
 

 M$ se ne guarda bene.
 
Falso. A meno di non utilizzare una JVM proprietaria (inesistente, visto che 
avrebbe invalidato la licenza di Sun), l'unico modo per ottenere, ad 
esempio, una lista di processi attivi sulla macchina e` tramite JNI o 
Subprocess. Una mezza pezza ce l'hanno messa con JNA, che pero` soffre della 
mancanza di documentazione (a parte quella ufficiale) e, soprattutto, di 
esempi. In C# (ma anche in Python) una cosa del genere la fai via libreria. 
Da questo punto di vista, Microsoft fu l'unica a proporre un'alternativa 
valida che permetteva di caricare una libreria nativa tramite J/Direct che, 
in sostanza, funzionava tramite l'uso di un particolare tag javadoc (se 
all'epoca ci fossero state le annotation sarebbe stato associato a queste). 
Purtroppo (o per fortuna, dipende dai punti di vista), Sun fece causa a 
Microsoft per aver infranto gli accordi legati a Java, causa che vinse e che 
decreto` la morte della JVM di Redmond (e che porto` alla nascita di .NET e 
C#)
 
Enrico

 avrebbe invalidato la licenza di Sun),
Palle.
IBM, ad esempio, da sempre produce una JVM per le sue piattaforme 
(windows incluso) su licenza SUN (ora Oracle).
Sempre IBM, ad esempio, include dei servizi per accedere alle risorse 
del sistema senza utilizzare JNI. Gli stessi servizi sono disponibili 
per qualsiasi linguaggio, anche da remoto, do diesis incluso, ma anche 
Java e Php.  Per Java fornisce un toolkit 100% java, per do diesis 
fornisce le dll, per php la Zend ha prodotto un toolkit che utilizza 
quei servizi.
 
 

 del sistema senza utilizzare JNI
 
Sarebbe interessante vedere un'implementazione relative all'uso di queste 
funzionalita`, anche perche` presumo che abbiano un funzionamento simile a 
JNA e che siano implementate in package specifici di IBM (cosa che non mi 
dispiacerebbe, anzi, un'implementazione in piu` fa sempre comodo). Ma rimane 
pur sempre qualcosa di esterno alla JVM e al linguaggio stesso, anche 
perche` altrimenti ci sarebbe stata un'altra causa in stile Microsoft
 
Enrico

il 09.01.2013 21:42, Scrive Enrico 'Henryx' Bianchi 171924844:

Io utilizzo spesso il jt400, o la sua versione open-source jtOpen, che 
e' l'interfaccia 100% pure java verso il sistema operativo os400. Ha le 
stesse funzionalitï¿œ sia in locale che in remoto. Se viene utilizzato 
lato server, si puï¿œ decidere se utilizzare le classi jni (per 
beneficoare di migliori performance) oppure forzare le sole classi 
socket, definendo una system property.
 
 

 e' l'interfaccia 100% pure java verso il sistema operativo os400.
 
Quindi e` come pensavo, ovvero non hai una implementazione interna al 
linguaggio (cosa che ha portato alla causa Microsoft/Sun ed ha permesso la 
creazione di C#), ma hai una libreria esterna simile a JNA che si preoccupa 
di gestire le eventuali implementazioni lato sistema/JNI. In sostanza, come 
dicevo, non hai una JVM che ti permette di interfacciarti direttaamente con 
il sistema operativo, ma una libreria, che e` molto differente
 
Enrico

il 11.01.2013 20:52, Scrive Enrico 'Henryx' Bianchi 124114188:

Certamente, ma non vedo come possa essere diversamente.
Ogni sistema operativo ha caratteristiche diverse, certe funzionalità 
presenti sull'uno potrebbero non essere presenti sull'altro e viceversa.
Il vero problema e' che ben pochi hanno rilasciato una libreria del genere.
 

 genere.
 
Ho capito solo ora cosa intendessi nei tuoi precedenti post, ovvero che i 
produttori di sistemi operativi (o esterni) potrebbero rilasciare liberie 
che si interfaccino direttamente con il sistema operativo (cosa che IBM fa 
con jt400). Il mio discorso, invece, verteva sul fatto che, oltre a JNI, 
Java non permette di interfacciarti in modo semplice e veloce a funzioni del 
sistema operativo, ne` mette a disposizione direttamente delle librerie che 
permettano di farlo (in teoria le cose sono un po' cambiate con Java7, 
soprattutto lato rete e lato file system). In C# hai a disposizione sia una 
sintassi che ti permette di chiamare una libreria esterna, sia un set di 
librerie che consentono di dialogare con il sistema operativo (la maggior 
parte presenti nella STL di .NET e Mono). Ed e` soprattutto la prima 
funzionalita` ad aver portato alla causa Sun/Microsoft
 
Enricp