Newsgroup: it.comp.java
Titolo: Incredibile disclaimer di SUN

Quando l'ho letto non  ci potevo credere.
Nel 2000, la SUN ha obbligato la Microsoft ad inserire nel product use
rights"di "Map point" una nota a dir poco allarmante.
Riferimento: 
http://technology.pitt.edu/software/userights/mappoint.pdf
Estratto:
NOTE ON JAVA SUPPORT. THE SOFTWARE MAY CONTAIN SUPPORT
FOR PROGRAMS WRITTEN IN JAVA. JAVA TECHNOLOGY IS NOT FAULT
TOLERANT AND IS NOT DESIGNED, MANUFACTURED, OR INTENDED FOR
USE OR RESALE AS ONLINE CONTROL EQUIPTMENT IN HAZARDOUS
ENVIRONMENTS REQUIRING FAIL-SAFE PERFORMANCE, SUCH AS IN THE
OPERATION OF NUCLEAR FACILITIES, AIRCRAFT NAVIGATION OR
COMMUNICATIONS SYSTEMS, IN WHICH THE FAILURE OF JAVA
TECHNOLOGY COULD LEAD DIRECTLY TO DEATH, PERSONAL INJURY, OR
SEVERE PHYSICAL OR ENVIRONMENTAL DAMAGE. Sun Microsystems, Inc. has
contractually obligated Microsoft to make this disclaimer.

 Quando l'ho letto non  ci potevo credere.
Er.. no? Guarda che quella clausola esiste per praticamente ogni 
linguaggio/compilatore/etc non esplicitamente costruito per usi critici.
O pensavi si facessero controller centrale nucleari in visual basic? :-D
Anzi, un paio d'anni fa per Java e' stata tolta la limitazione su sistemi
di controllo di volo, e recentemente e' in fase di test (se non ricordo 
male) il primo fly display scritto interamente in java.
-- 
You dont know what to do when you dont know what you're doing.
http://space.tin.it/computer/csadun



Nulla di allarmante, solo questioni legali. Con questo sistema la Sun si
para il culo preventivamente, in modo da non poter essere coinvolti come
responsabili nel caso in cui l'uso di qualunque software scritto in Java
abbia come conseguenza diretta uno qualunque dei danni fisici estremi citati
nel disclaimer... e non a caso citano anche il controllo di sistemi nucleari
- sai mai che un qualche baco nella embedded JVM porti a calcolare in modo
errato il livello di immersione delle barre di uranio nel deuterio... A chi
pensi si rivolgerebbero per primi gli avvocati?
Comunque questo disclaimer è presente sin dalla primissima versione di Java,
e dato che MapPoint la usa direttamente, anche se si tratta della JVM
microsoft, Sun ha pienamente diritto di far inserire il proprio disclaimer
anche in questo prodotto.
-- 
Fermate Scientology prima che sia troppo tardi!!!
http://xenu.com-it.net
 - 
http://xenu.freewinds.cx/
(per rispondere personalmente leva IlDitoDalCulo)

> O pensavi si facessero controller centrale nucleari in visual basic? :-D
Adesso che centra visual basic?
Non credo che sia una bella pubblicità per SUN.
A questo punto mi chiedo se questa situazione è valida solo per i linguaggi
pseudo interpretati o e generale per tutti.
Ciao,
CC

 Non credo che sia una bella pubblicità per SUN.
Guarda che è assolutamente normale trovare questi tipi di disclaimer, non 
solo nei linguaggi di programmazione (per i quali anzi secondo me la cosa è 
anche più che giustificata) ma in qualunque tipo di *oggetto* soggetto alla 
vendita.
Ci sono casi esilaranti (non so quanto veri), come il costume di carnevale 
da Superman con su scritto: "indossare quest'abito non permetterà di 
volare".
Il problema è che se le aziende che non si "parano" con questi espedienti 
spesso (soprattutto negli USA per quanto ne so) rischiano in caso di 
incidenti di essere portate in tribunale e *perdere* seriamente.
Ovviamente io non credo che loro siano tanto sfiduciati nella loro 
tecnologia... pensa che ad esempio Java è utilizzato in formula 1 dalla 
McLaren... ma un accusa di disastro nucleare/ambientale "colposo" penso 
sarebbe in grado di mettere in ginocchio anche la Sun.
IMHO la Sun ha fatto bene a mettere il disclaimer :)
pole
-- 
Note: Some input words use a deprecated author.
Note: Read with -deprecation to understand.

 linguaggi pseudo interpretati o e generale per tutti.
Occhio che una cosa e' un linguaggio, un'altra una sua implementazione in 
termini di compilatore, sistema runtime, eccetera. Certi linguaggi sono 
disegnati per essere _implementati_ coi requisiti necessari per qel tipo di 
applicazioni (l'esempio piu' noto e' Ada); altri no, ma potrebbero 
(C/C++/Java e molti linguaggi moderni) solo a patto pero' di costruire 
un'implementazione che aderisce a certi criteri.



Cosa ci trovi di allarmente o grave?
Mai visto un teschio dietro un prodotto chimico particolare (come una colla
super potente)?
Si avverte soltanto che utilizzare Java in certi ambienti puo' essere
pericoloso e dannoso per l'uomo. Se l'uomo vuole ugualmente usarla, la Sun
non si assume nessuna responsabilita'.
Ora una domanda: saliresti mai in un aereo dove le sequenze di partenza ed
atterraggio sono pilotate da un software scritto in Java? Io no!
-- 
Marco "Duff" Palermo
http://www.marcoduff.com/

 volare".
[CUT]
Te ne dico io uno vero (spuntato su moltissimi quotidiani molti anni fa):
una signora americana, dopo avergli fatto il bagnetto, ha infilato il suo
gatto nel microonde per asciugarlo... il gatto (poverino) e' esploso!
La signora ha fatto causa al venditore del microonde e gli avvocati si sono
attaccati al fatto che ne' il manuale, ne' la scatola dicevano che "non si
possono infilare animali nel microonde" e che "il gatto rappresentava un
affetto insostituibile della vedova signora"...
La signora e' miliardaria...


 Te ne dico io uno vero [...]
LOL :-D
Ora che ci penso mi sovviene che quest'estate, sul materassino gonfiabile da 
mare di mio nipotino, vicino al cuscino, campeggiava l'avviso in 5 o 6 
lingue: "non applicare motori fuoribordo" (!!) Evidentemente qualche 
svitato ci avrebbe pure provato...
Ora però stiamo diventando un po' troppo OT :-))
ciao :)


 atterraggio sono pilotate da un software scritto in Java? Io no!
<Solo_per_cominciare_un_flame>
    Dipende da chi ha scritto il programma
    e non dallinguaggio di programmazione.
</Solo_per_cominciare_un_flame>
- Dario

 </Solo_per_cominciare_un_flame>
<estintore :-)>
Credo si riferisse al fatto che la tecnologia potrebbe non essere studiata 
per questi scopi, per cui anche un programmatore bravo potrebbe incappare 
in problemi non dipendenti (e quindi non gestibili) da lui.
Anche se nel caso dell'aeronautica, stando a quanto dice Cristiano, sembra 
ci sia il via libera da parte di Sun.
Nel senso più generale dell'affermazione sono invece d'accordo con te :)
</estintore :-)>


 [cut]
Mi hanno raccontato (ipse dixit)  che B.Boehm ha un pacemaker con un sw 
di cui ha compartecipato la progettazione. E che lui dice che è la 
punizione che si meritava, il sw dei concorrenti era fatto molto meglio.
uL
P.S. comunque quel tipo di disclaimer c'e' per qualsiasi prodotto sw non 
*esplicitamente* progettato/customizzato per usi critici. Il che non 
esclude versioni di Java customizzate ad hoc, o versioni di S.O., ecc. 
ecc. Nessuno si sognerebbe di installare Mandrake comprato in edicola su 
uno shuttle, magari pilotato da un sw scritto in java su jvm blackdown. 
Ma una versione speciale di linux con una vm speciale magari si.

 pseudo interpretati o e generale per tutti.
come ti hanno gia' detto, è valida per qualsiasi cosa non esplicitamente 
progettata per usi critici, dai sistemi operativi, ai linguaggi, alle 
piattaforme sw, fino ai componenti stessi dell'hw. Tutta l'informatica 
che tu conosci (altrimenti non avresti scritto 'sta cosa)
Puoi leggerla sul tuo disco, cpu, ecc. in una qualche forma (sull'hw mi 
sembra ci sia una "classe", ma potrei ricordare male)
ciao
uL

 Ma una versione speciale di linux con una vm speciale magari si.
Sembra proprio che all'ESA ci stiano pensando:
http://www.aero-project.org/



<Solo_per_buttare_alcool_puro_sul_flame _:)>
Non sono per niente d'accordo!
Ok, un bravo programmatore può ottimizzare al 99% un codice, ma non puo'
sorpassare i *limiti* di un linguaggio.
Java e' troppo lento *e non si ci puo' fare nulla* per gestire la partenza
e l'atterraggio di un aereo (NON parlo di piani di voli!).
Un colpo di vento durante l'atterraggio e la riprogrammazione di tutto (si
parla di equazioni con migliaia di variabili) metterebbe in ginocchio Java!
Non nel senso che Java non sa calcolare quelle equazioni, ma che ci sta
*troppo tempo* nel farlo (parliamo sempre di millesimi di secondo!!!)!
NON esiste, e mi ripeto, NON esiste nessun programma RealTime (se non a
livello amatoriale/dilettantistico/didattico) fatto in Java.
</Solo_per_buttare_alcool_puro_sul_flame _:)>



Vi ricordate il post "Incredibile disclaimer di SUN" e risposte ?
Consiglio a tutti di farsi un bel bookmark della home page di Doug Lea:
http://gee.cs.oswego.edu/dl/
Se vi interessa sapere a grandi linee lo sforzo ingegneristico che serve 
per far volare quei trabiccoli poi, non potete perdervi questo (sempre 
di Doug Lea):
http://gee.cs.oswego.edu/dl/acs/acs/acs.html
Infine sull'affidabilità del software, un'interessantissima collezione 
di white paper, densissimi di concetti secondo me fondamentali per TUTTI 
i progettisti, i programmatori e chiunque abbia a che fare con la 
creazione di software.
Dix

 
Scusate, il mio fido Netscape mi ha "mangiato" l'ultimo link:
http://www.safeware-eng.com/index.php/white-papers


Ci salirei solo se il codice java serve per far scaldare il mio caffè... e
basta.
Non vorrei iniziare un polemica ma fino ad adesso il software che ho visto
fatto con java è tutto terribilmente lento.
java ha altre caratteristiche che lo rendono competitivo ma non la velocità.
Forse costruendo hw che lo esegue nativamente alla velocità della luce (o
poco meno)
ci si potrebbe fidare.
gian

 ci si potrebbe fidare.
...ma andrebbe fuori le specifiche del linguaggio stesso.


 ci si potrebbe fidare.
A parte tante altre cose inesatte che si leggono, la velocità di esecuzione 
non è un fattore che di per sè garantisce sicurezza in applicazioni 
"delicate". 
Molto più importante è l'affidabilità: un robusto supporto per le eccezioni 
e un ambiente di esecuzione stabile e molto ben documentato come la jvm 
(che potrebbe essere realizzata anche in hw), nonché la possibile diretta 
assunzione di responsabilità da parte della casa produttrice (possibile nel 
caso di Java visto che è di proprietà della Sun), sono tutti fattori che 
rendono Java *molto* appetibile per la ricerca e lo sviluppo di 
applicazioni mission-critical. 
L'unico vero fattore critico che finora ha impedito la diffusione di 
software realtime in Java è il suo garbage collector, che per come è 
implementato nelle normali JVM ha un comportamento non del tutto 
prevedibile e quindi non utilizzabile in quel genere di applicazioni che 
richiedono software a "risposta immediata" in *qualunque* condizione.
Alla Sun sono impegnati da tempo su questo fronte. Per vedere cosa accade 
all'interno del jcp vedi 
http://jcp.org/en/jsr/detail?id=1


 applicazioni mission-critical. 
[CUT]
Infatti qui nessuno ha parlato di mission-critical in generale, dove java
ha un gran bel peso!
Nell'atterraggio/decollo di un aereo l'utilizzo di java e' troppo lento a
prescindere dalla sua affidabilita'.
Una applicazione che adesso mi viene in mente, dove java fa da padrona, e'
l'utilizzo dei robot militari per la ricerca di mine (software simile viene
usato dai robot usati dagli artificeri) o per l'utilizzo in zone "calde" di
guerra. Si presuppone che il software debba girare in applicazioni estreme
come parti hw che improvvisamente vengono a mancare a causa di una
esplosione o di un proiettiche che distrugge parte della circuiteria. In
questo campo, java, e' diventato insostituibile grazie alla ottima
robustezza e alla sua gestione delle eccezioni.
