Bytecode

[atragon]

Il mio quesito è una mera curiosità e, visto che non sono un grandissimo conoscitore di java e dei suoi misteri, chiedo lumi. Partiamo da lontano: una delle caratteristiche del framework .Net di MS (calma, poi arrivo al punto ;) )è la sua caratteristica di essere cross-language, cioè ogni compilatore che generi MSIL ovvero sia .Net compliant, può giovarsi delle potenzialità dell'ambiente. E infatti esistono parecchi compilatori, Cobol, Fortran e quant'altri, che si appoggiano su .Net. Bene, chiarissimo. Perchè non si è mai realizzato un approccio simile con Java? Cioè perchè non è possibile che un compilatore C o Delphi o che diavolo si vuole generi bytecode che si appoggia sulla JVM? La domanda mi è sorta leggendo un vecchio e ovviamente non ufficiale documento su Delphi (la ver. 6 se ricordo bene) in cui si diceva che sarebbe stata inclusa la facoltà di generare bytecode Java e, vagamente, rammento che su alcuni newsgroup la cosa aveva generato parecchio interesse. E' una semplice questione di inutilità dello sforzo, come mi pare di aver capito o c'è qualche altro motivo?

[kingv]

e' probabile che ci siano grossi problemi di licenza in questo caso.
Esistono compilatori alternativi a quello fornito da Sun, come jikes o lo stesso gcc, ma sono comunque compilatori per java.

bella osservazione ;)

[fek]

E' una semplice questione di inutilità dello sforzo, come mi pare di aver capito o c'è qualche altro motivo?

Da una parte c'e' un problema legale, la questione della licenza di produrre bytecode java da un altro compilatore non Sun.

Dall'altra c'e' un discorso quasi filosofico dietro: MSIL e Java Bytecode sono una soluzione molto simile per risolvere due problemi molto differenti.

MSIL risolve il problema di scrivere una classe e poterla usare facilmente in ambienti (linguaggi) differenti; e' nato come evoluzione di COM e come soluzione dei suoi problemi. Quindi in questo caso e' naturale che piu' linguaggi producano MSIL perche' e' questo lo scopo stesso per cui e' nato.

Java Bytecode risolve il problema di scrivere una classe e poterla eseguire su architetture hardware/software differenti.

Sebbene dal punto di vista tecnico nessuno vieti di scrivere un equivalente del CLR (cosa priva di royalty da pagare) su un sistema con architettura differente da Wintel, e nessuno vieti di compilare altri linguaggi in Java Bytecode, i problemi risolti dalle due soluzioni sono differenti.

[/\/\@®¢Ø]

Perchè non si è mai realizzato un approccio simile con Java?
Perchè è stato fatto :D
Il piu' famoso e' forse Jython ( http://www.jython.org ), un port di Python per la JVM.
E' divertente e pratico da fare, secondo me pure piu' del Java stesso (ad esempio per sperimentare col codice, apri una console interattiva e man mano che costruisci l'interfaccia grafica appare a video).
Ce ne sono altri piu' o meno sconosciuti:
Il seguente sito ne elenca all'incirca 200 ( ! )
http://www.robert-tolksdorf.de/vmlanguages.html

Sicuramente nel caso del CLR lo sviluppo di linguaggi alternativi e' stato sicuramente piu' attivo, probabilmente per il fatto che mentre per la Sun VM e Linguaggio sono quasi un tutt'uno, Microsoft stessa ha proposto piu' linguaggi e finanziato lo sviluppo di altri (anche modificando il CLR per renderlo piu' adatta a questi ultimi ).

[atragon]

Si, il discorso licenze era stato anche il mio primo pensiero ma tutto sommato avevo pensato che in qualche modo quello si può anche mediare; ;) anche se resta un (o forse IL) problema di base. Pensavo ad una qualche problematica legata a un gap prestazionale. Certo esiste anche un discorso di filosofia, o meglio ancora di finalità, rispetto a MSIL onde per cui il concetto di cross language male si attaglia ad un qualche cosa nato per interfacciarsi con più piattaforme piuttosto che con più linguaggi. Tuttavia l'idea resta affascinante: un compilatore, prendo sempre ad esempio il neutrale Delphi, che fosse in grado con una qualche direttiva o opzione del compilatore di generare un eseguibile o bytecode sarebbe molto interessante. Da quel che ho capito l'idea di Borland era proprio quello di fare di Delphi un ambiente "universale" orientato a Win32, Web e Linux (o altro) attraverso il ponte con JVM. Tuttavia sappiamo come è andata a finire: Delphi genera eseguibili Win32, per Linux c'è Kylix e per il Web ci si appoggia a .Net. Delphi, quindi l'Object Pascal è solo un esempio, evidentemente. Potrei parlare del C++ per restare in un ambito object oriented o ancora di più SmallTalk. Certo se è solo per motivi "politici" mi parrebbe un autogol di Sun (che ha una certa propensione al masochismo, peraltro...)

[atragon]

Perchè è stato fatto :D
Il piu' famoso e' forse Jython ( http://www.jython.org ), un port di Python per la JVM.
E' divertente e pratico da fare, secondo me pure piu' del Java stesso (ad esempio per sperimentare col codice, apri una console interattiva e man mano che costruisci l'interfaccia grafica appare a video).
Ce ne sono altri piu' o meno sconosciuti:
Il seguente sito ne elenca all'incirca 200 ( ! )
http://www.robert-tolksdorf.de/vmlanguages.html

Sicuramente nel caso del CLR lo sviluppo di linguaggi alternativi e' stato sicuramente piu' attivo, probabilmente per il fatto che mentre per la Sun VM e Linguaggio sono quasi un tutt'uno, Microsoft stessa ha proposto piu' linguaggi e finanziato lo sviluppo di altri (anche modificando il CLR per renderlo piu' adatta a questi ultimi ).

Azz, ho fatto tanto parlare per nulla :) non avevo letto il post... ora vado a vedere, la cosa mi incuriosisce (resta una domandina: come mai se ne parla così poco, sempre che non sia ignoranza da parte mia... o forse è meno interessante come approccio di quanto pensavo...)

[/\/\@®¢Ø]

(resta una domandina: come mai se ne parla così poco, sempre che non sia ignoranza da parte mia... o forse è meno interessante come approccio di quanto pensavo...)
Forse perche', come dicevo sopra, Sun non ha avuto e non ha interesse a vedere fiorire questi linguaggi (faccio presente per inciso che della schiera presentata nel link precedente, ben pochi hanno raggiunto un certo livello di maturita'). Sun fa i soldi col mercato legato al linguaggio Java, non la vm in se'.
Viceversa a Microsoft non interessa che linguaggio usi, ma che lo fai usando la sua piattaforma e le sue librerie (e di conseguenza i suoi sistemi operativi, perlomeno per il momento).