Java con licenza Open Source? Sun dice no

[Redazione di Hardware Upg]

Link alla notizia: http://news.hwupgrade.it/12225.html

IBM ha chiesto un incontro a Sun per verificare la possibilità di rilasciare Java con licenza Open Source, ma Jonathan Schwartz alza gli scudi!

Click sul link per visualizzare la notizia.

[Marci]

Secondo me per la situazione precaria in cui si trova Sun rendere una tecnologia opensource l'aiuterebbe soltanto a scavare la fossa che gli si sta aprendo sotto.
Byezz

[Kralizek]

in effetti non posso dare torto a Schwartz.
Se Java fosse Open Source vi sarebbero i pro ed i contro (come in tutte le cose):

pro: forse gli open developper potrebbero dare una mano nella manutenzione delle classi base che, è opinione di tutti i maggiori esperti di java, sono il maggior freno nelle prestazioni di un programma java. Infatti l'agognato 1:1,5 (rapporto tra applicazioni c++ e applicazioni java) con il Java HotSpot è stato solo avvicinato ma è ancora lontano da essere raggiunto.
contro: una frammentazione senza controllo di versioni diverse del java runtime environment.

Conoscendo i motivi che portano alla nascita di Java, i contro superano di molto i vantaggi.

IMHO

[bizzu]

Sono d'accordo in pieno con Schwartz. E poi a cosa servirebbe Java opensource? Forse a permettere a IBM di fare una sua versione?
Se non ti piace una classe, la ridefinisci! (visto in modo molto semplicistico )

[cionci]

Potrebbe benissimo essere OpenSource, ma non GPL...la licenza GPL è troppo limitativo...ovviamente IMHO...

[joe4th]

Onestamente le affermazioni sulla compatibilita'
sono ridicole; soprattutto perche' ci sono
cosi' tante macchine virtuali Java rilasciate
da SUN, IBM, etc., che nemmeno loro sanno piu' starci dietro, per non parlare di tutte le incompatibilita
che sorgono usando le macchine virtuali di
SUN compilate con compilatori vecchi su distro
preistoriche, su kernel 2.6...
Altro che write once run everywhere: write
once, run nowhere e' la situazione attuale...

Credo che alla fin fine ci sono piu' release
di macchine virtuali SUN che applicazioni Java...

[krokus]

Anche io sono d'accordo con Schwartz. Concordo nel pensare che la GPL sia un'ottima cosa per certi tipi di software, ma questo non è il caso di Java. Piuttosto, esistono licenze open che comunque limitano la frammentazione selvaggia, forse si potrebbe vedere su una cosa del genere...

[xtg]

concordo con cionci, la gpl pone troppi obblighi per un progetto come java

[Ikitt_Claw]

Originariamente inviato da Kralizek
contro: una frammentazione senza controllo di versioni diverse del java runtime environment.

Mi fai un nome di un progetto OSS di una certa rilevanza dove questo accade?

[joe4th]

vogliamo parlare delle implementazioni Java per Athlon
64 disponibili grazie alla licenza di SUN?

Ci sono migliaia di progetti failure proof in GPL,
basti pensare al perl, al python, al PHP e
quindi spaventarsi di frammentazioni (laddove
di solito quando avvengono frammentazioni si
cambia anche il nome) mi sembra eccessivo, tanto
gia' la situazione attuale e' pessima (causa
macchine virtuali marce) e vede gia' Java inusabile
in applicazioni di una certa importanza...

[bizzu]

Originariamente inviato da joe4th
vogliamo parlare delle implementazioni Java per Athlon
64 disponibili grazie alla licenza di SUN?

Ci sono migliaia di progetti failure proof in GPL,
basti pensare al perl, al python, al PHP e
quindi spaventarsi di frammentazioni (laddove
di solito quando avvengono frammentazioni si
cambia anche il nome) mi sembra eccessivo, tanto
gia' la situazione attuale e' pessima (causa
macchine virtuali marce) e vede gia' Java inusabile
in applicazioni di una certa importanza...

Dalle tue affermazioni si deduce che non hai proprio idea di come sia fatta una virtual machine...
Java viene compilato in bytecode che NON è un linguaggio macchina, ha quindi bisogno di un interprete che porti le istruzioni JVM a quelle della macchina. Questo vuol dire che ci deve essere una JVM per ogni architettura.
Aggiungi poi le chiamate alle funzioni del sistema operativo per le GUI o altro, e avrai una JVM per (quasi) ogni SO.
Quindi mi sembra lampante che ci debbano essere molte JVM diverse per avere compatibilità.
La JVM non è assolutamente marcia come dici tu, ha invece tecniche molto avanzate che migliorano di release in release (è un po' impossibile fare un software universale in una sola versione che vada bene con tutto...).
Java è interpretato: è logico che non vada bene per tutti i tipi di applicazioni... se vuoi prestazioni usa il C++.

[krokus]

Originariamente inviato da Ikitt_Claw
Mi fai un nome di un progetto OSS di una certa rilevanza dove questo accade?

Non vorrei scatenare flame, anche perchè non ne so abbastanza al riguardo, ma il buon KDE ha tra le sue caratteristiche il fatto di non essere retrocompatibile, cioè una applicazione scritta per KDE 1.x non gira su KDE 2 o KDE 3 e nessuna applicazione scritta per KDE 2.x gira sul 3.
Non so se sia colpa della licenza LGPL, di sicuro non è una bella cosa.
Il tanto mazziato Windows se non altro permette che una applicazione scritta per il 95 giri senza troppi problemi su XP.
Questo è un caso di cosiddetta "autoincompatibilità", cioè un software è incompatibile con sè stesso. Ripeto, non sono competente, non vorrei sbagliare, ma mi sembra che i casi più gravi siano proprio nel software GPL.
Per "frammentazione" si può anche intendere questo caso particolare.

[joe4th]

Non sto dicendo che la java virtual machine
e' marcia di per se, ma per il modo in cui
SUN la distribuisce, tenendola chiusa e distribuendo
solo lei i sorgenti (a parte blackdown)
fa si che risulti "marcia" per molte degli
applicativi non appena cambia qualcosa in qualche libreria o nel kernel.

Tanto per citare il vecchio plugin libjavaplugin_oji.so
compilato con il vecchio egcs 1.1.2 che non andava
su tutte gli applicativi compilati con gcc 3.2.X.

Per cui alla fine ciascuna applicazione ha bisogno
della sua specifica JVM e non sempre le
JVM vecchie funzionano su sistemi con librerie
nuove.

[Ikitt_Claw]

Originariamente inviato da krokus
Non vorrei scatenare flame, anche perche non ne so abbastanza al riguardo,

Se dipende da me (la flame) no problem...

ma il buon KDE ha tra le sue caratteristiche il fatto di non essere retrocompatibile, cioe una applicazione scritta per KDE 1.x non gira su KDE 2 o KDE 3 e nessuna applicazione scritta per KDE 2.x gira sul 3.

Si ma...
1) il KDE non ha subito io fork di cui tanto si ha paura...
2) AFAIK l'incompatibilita` deriva principalmente dal cambio QT2->QT3, che sta alla base di KDE. (Inciso: e chi produce QT? Esatto, un'azienda commerciale... OK che e` sotto GPL, ma teniamo comunque a mente la TrollTech Inc.)

Non so se sia colpa della licenza LGPL, di sicuro non e una bella cosa.

E come potrebbe essere colpa della LGPL?

Il tanto mazziato Windows se non altro permette che una applicazione scritta per il 95 giri senza troppi problemi su XP.

...Le ricordo solo io i vari casi di incompatibilita` pre XP/Post XP? si eh?

[quote]
ma mi sembra che i casi piu gravi siano proprio nel software GPL.
[/quoOTE]

A me sembra di no. Vogliamo fare qualche altro nome?

[Ecio]

Originariamente inviato da bizzu
Sono d'accordo in pieno con Schwartz. E poi a cosa servirebbe Java opensource? Forse a permettere a IBM di fare una sua versione?

veramente IBM gia' realizza una JVM (oltre che un JDK) sua , cosi' come la faceva Microsoft (che non aggiorna piu' dal giurassico) o come la fanno altri (vedi BEA).

Non per altro esiste un comitato che definisce le funzionalita' di Java, chiaramente Sun sara' il membro + importante, ma ci sono anche altri...

[krokus]

Allora non mi è chiaro come fa KDE ad essere sotto LGPL se le librerie su cui si basa non lo sono! Soprattutto non capisco perchè buttare al vento fior di software (tipo Kisocd, per esempio) per un cambio di librerie....ma non è il solo esempio....insomma, come si spiega la bestiale autoincompatibilità di Linux? e perchè FreeBSD non presenta questo difetto? è colpa delle licenze diverse o è un caso?
Per quello che riguarda il pre o post XP, io non ho mai avuto problemi a mettere software vecchio sotto XP, tranne nel caso di accesso diretto all'hardware, e mi è capitato solo una volta con un programma di pilotaggio di PLC (Siemens Step7)....qualcuno mi illumina?

[Ikitt_Claw]

Originariamente inviato da krokus
Allora non mi è chiaro come fa KDE ad essere sotto LGPL se le librerie su cui si basa non lo sono!

AFAIK le QT sono GPL non LGPL. Ma non seguo molto bene il mondo della kappa per cui puo` darsi benissimo che sia poco aggiornato.

Soprattutto non capisco perchè buttare al vento fior di software (tipo Kisocd, per esempio) per un cambio di librerie....ma non è il solo esempio....

Major release, API change. Ci sta, voglio dire, non e` fuori dal mondo.

insomma, come si spiega la bestiale autoincompatibilità di Linux?

Una certa tendenza (irritante in certi casi) a reinventare la ruota e a rivoluzionare piu` che evolvere, e questa c'e`.
Ma da qui alla "bestiale incompatibilita`" mancano ancora qualche ampia serie di altri esempi, perche` io in vari anni di Linux 'sta incompatibilita` mostruosa mica l'ho vista, sara` stata solo fortuna che devo dirti.

e perchè FreeBSD non presenta questo difetto? è colpa delle licenze diverse o è un caso?

Che io sappia il passaggio 4.x -> 5.x non e` proprio painless.
Inciso: la licenza non c'entra nulla IMHO, e` un problema di modalita` di sviluppo. In linux, come detto, c'e` questa tendenza a rivoluzionare, in BSD molto meno (d'altronde, la storia parla in modo molto eloquente).

Per quello che riguarda il pre o post XP, io non ho mai avuto problemi a mettere software vecchio sotto XP,

Io si. Risolvibile, per carita`. E` bastato aspettare un poco, per carita`. Non ho ammattito quasi nulla, per carita`. Ma c'e` stato. E non si e` risolto in una reingegnerizzazione del SW (forse del SW che andava su KDE2 e non e` stato portato su KDE3 non era proprio ottimo ottimo), ma, a quanto mi risulta, a colpi di pezze dentro windows. Questo e` tollerabile in un'entita` commerciale. Alla Linux. Inc. non vogliono conquistare la borsa, vogliono solo fare un lavoro tecnicamente migliore possibile, quindi quando serve l'API change, si fa l'API change. Qualcuno patchera` i sorgenti o produrra` nuovo SW per le nuove API.

[krokus]

Sì, il passaggio da FreeBSD 4.x al 5.x non è indolore, però le applicazioni nate per la versione 5 generalmente possono funzionare senza troppi problemi anche sul 4, e questo perchè nel caso di BSD, la versione 5 non è una evoluzione della 4, ma sono due branche separate di sviluppo, una considerata "stable" non nel senso di "esente da crash", ma nel senso "sviluppo senza stravolgimenti" e l'altra nominata "current" per indicare "sviluppo continuativo". Dalla current periodicamente viene estratta una distribuzione vera e propria detta "release"
Per Linux io invece mi sono scornato diverse volte su cose del tipo "questo pacchetto richiede il pacchetto XYZ 0.1.2_rc4, versione attualmente installata 0.1.2_rc5" oppure "il pacchetto Pincopallo 0.3.4 beta2 è in conflitto con il pacchetto Pincopallo 0.3.4 beta2 bis" o ancora "il modulo è compilato con gcc versione 2.x mentre il kernel è compilato con gcc versione 3.x. Non funzionerà"
E vai di installazione di gcc 2.x....
Insomma, nel caso di Java, già così ci sono un tot di problemi, ma non vorrei trovarmi con un Java a GPL con decine di versioni sparse in giro, nominate PippoJava 0.0.2 beta4_rc3 o JavaToni 20050402 alpha87_1 e discussioni del tipo "il mio Java è migliore del tuo"...."non è vero, il tuo fa schifo" e diventare deficienti ogni volta che un applet salta fuori con la scritta "questo programma richiede JavaPincoPallo e non funziona con JavaCelentano che hai installato"



...scusa, mi sono lasciato trasportare...

[cionci]

Originariamente inviato da krokus
Insomma, nel caso di Java, già così ci sono un tot di problemi, ma non vorrei trovarmi con un Java a GPL con decine di versioni sparse in giro, nominate PippoJava 0.0.2 beta4_rc3 o JavaToni 20050402 alpha87_1 e discussioni del tipo "il mio Java è migliore del tuo"...."non è vero, il tuo fa schifo" e diventare deficienti ogni volta che un applet salta fuori con la scritta "questo programma richiede JavaPincoPallo e non funziona con JavaCelentano che hai installato"

Secondo me hai ragione...è per questo che sarebbe adatta una licenza OpenSource, ma non GPL Una licenza che non consenta fork del progetto esterni...

[Ikitt_Claw]

Originariamente inviato da krokus
Per Linux io invece mi sono scornato diverse volte su cose del tipo "questo pacchetto richiede il pacchetto XYZ 0.1.2_rc4, versione attualmente installata 0.1.2_rc5" oppure "il pacchetto Pincopallo 0.3.4 beta2 è in conflitto con il pacchetto Pincopallo 0.3.4 beta2 bis"

E` capitato anche a me, questo.
RPM fatti a bestia probabilmente, nel qual caso il legame con GPL, Linux od OSS e` quantomeno discutibile

o ancora "il modulo è compilato con gcc versione 2.x mentre il kernel è compilato con gcc versione 3.x. Non funzionerà"

Questo e` un'altro dei grossi nomi di cui parlavo e di cui volevo un'esempio, e questo in effetti e` fastidioso. GCC3 e` stato molto discusso per questo ed altri motivi.

Insomma, nel caso di Java, già così ci sono un tot di problemi, ma non vorrei trovarmi con un Java a GPL con decine di versioni sparse in giro, nominate PippoJava 0.0.2 beta4_rc3 o JavaToni 20050402 alpha87_1

Si, ma tornando al punto originale, sono emersi sinora vari problemi e problemini dell'OSS e di Linux, ma manco un caso di progetto grosso e famoso con una caterva di fork a giro che creano problemi di incompatibilita`
Se vuoi io ti cito un paio di questi casi:
- egcs vs gcc: durato qualche mese, poi egcs e` stato riassorbito da gcc
- samba fork: qualche mese indipendentemente poi i due progetti, AFAIK, si sono riuniti
- mplayer VS mplayexp: mplayerxp e` praticamente morto
- caso del kernel: ci sono N tree a giro, ma uno ed uno solo e` ufficiale, e c'e` comunque forte scambio di codice tra i tree.
(e comunque in questi casi c'e` comunque una compatibilita` piu` o meno vasta, e provata sol campo, tra i vari progetti)

Morale: a me pare che si faccia di tutta l'erba un gran fascio, specialmente quando si parla di problemi e controindicazioni dell'OSS.