Java draait niet lekker volgens sun?

[Slagroom]

Hallo,

Ik las de eula van MDAC door en zag dit er in staan:

12. OPMERKING OVER JAVA-ONDERSTEUNING.

HET IS MOGELIJK DAT HET PRODUCT ONDERSTEUNING BIEDT VOOR PROGRAMMA'S DIE ZIJN GESCHREVEN IN JAVA. DE JAVA-TECHNOLOGIE IS NIET FOUTBESTENDIG EN IS NIET ONTWORPEN, VERVAARDIGD OF BEDOELD VOOR GEBRUIK OF WEDERVERKOOP ALS ON LINE CONTROLEMECHANISME IN RISICOVOLLE OMGEVINGEN WAARIN EEN FOUTLOZE WERKING WORDT VEREIST, ZOALS IN NUCLEAIRE FACILITEITEN, VLIEGTUIGNAVIGATIE- OF COMMUNICATIESYSTEMEN, LUCHTVERKEERSBEGELEIDINGSSYSTEMEN, MEDISCHE APPARATUUR ZOALS HART-LONGMACHINES OF WAPENSYSTEMEN, WAARBIJ EEN GEBREK IN DE JAVA-TECHNOLOGIE RECHTSTREEKS KAN LEIDEN TOT OVERLIJDEN, LICHAMELIJK LETSEL OF ERNSTIGE SCHADE AAN HET MILIEU. Sun Microsystems, Inc. heeft Microsoft contractueel verplicht deze verklaring op te nemen.

Betekent dit dan Sun niet zo veel vertouwen in Java heeft en dus eigenlijk zegt dat Java brak is? Of lees ik het verkeerd?

[whoami]

Ik meen ooit eens ergens gelezen te hebben dat Sun zelf geen Java gebruikt voor hun eigen enterprise-app's.
Ik zal dat artikel vanavond of dit weekend eens opnieuw proberen op te vissen.

[TrailBlazer]

Je leest denk ik meer dat SUN een amerikaans bedrijf is wat rekening houdt met die achtelijke amerikaanse claims. In elke taal kan je fouten maken waardoor er iemand overlijdt sun heeft dit echter meteen van zich afgeschreven. Het probleem is namelijk C++ is geen taal van een bedrijf en JAVA wel als ik het goed heb

[drm]

TrailBlazer:
Je leest denk ik meer dat SUN een amerikaans bedrijf is wat rekening houdt met die achtelijke amerikaanse claims.

Dat denk ik ook

In elke taal kan je fouten maken waardoor er iemand overlijdt sun heeft dit echter meteen van zich afgeschreven. Het probleem is namelijk C++ is geen taal van een bedrijf en JAVA wel als ik het goed heb

Het gaat waarschijnlijk niet zozeer om de taal, maar om de "technologie" als in: runtime environments, bytecode interpreters, etc. Het is dus een disclaimer voor een stuk software dat sun afgeleverd heeft, niet een disclaimer voor de taal Java. Dat zou ook nergens op slaan want de taal Java opzich is een zinloos iets, zonder compiler (software) en interpreter (software).

[Verwijderd]

Java is niet van sun, maar van een consortium waarin Sun permanente zitting heeft

[mbravenboer]

Heb je weleens een willekeurige licentie gelezen? Zulke indekking is standaard.

[Slagroom]

TrailBlazer schreef op 04 June 2003 @ 11:25:
Je leest denk ik meer dat SUN een amerikaans bedrijf is wat rekening houdt met die achtelijke amerikaanse claims. In elke taal kan je fouten maken waardoor er iemand overlijdt sun heeft dit echter meteen van zich afgeschreven. Het probleem is namelijk C++ is geen taal van een bedrijf en JAVA wel als ik het goed heb

Als ik dit zo lees:
DE JAVA-TECHNOLOGIE IS NIET FOUTBESTENDIG
dan denk ik toch dat het wel aan java zelf ligt en niet aan de programmeur.

Toch vindt ik wel dat je gedeeltelijk gelijk hebt. In Amerika heb je denk ik snel een claim aan je broek.

[Slagroom]

mbravenboer schreef op 04 juni 2003 @ 11:31:
Heb je weleens een willekeurige licentie gelezen? Zulke indekking is standaard.

Dit is de eerste keer dat ik een licentie overeenkomst doorlees en ik keek er wel van op dat Sun haar eigen (en die van anderen???) Java niet vertrouwt.

[drm]

mbravenboer:
Heb je weleens een willekeurige licentie gelezen? Zulke indekking is standaard.

Inderdaad.

[catfish]

op elk tabakspakje staat "schadelijk voor de gezondheid", maar in de VS is het wel perfect mogelijk om een fabriakant aan te klagen als je longkanker krijgt... spreekt toch voor zich?
SUN is gewoon een bedrijf dat geen idoterijen wilt

er zijn bv wel degelijk medische monitor programma's die op windows draaien enzo (al weet iedereen dat dat nie zo'n super idee is), ik veronderstel dat MS dus ook wel zoiets heeft staan in z'n licence agreement (nooit gelezen)

[ACM]

Volgens mij vergeten jullie even de context waarin je dit moet lezen...

DE JAVA-TECHNOLOGIE IS NIET FOUTBESTENDIG EN IS NIET ONTWORPEN, VERVAARDIGD OF BEDOELD VOOR GEBRUIK OF WEDERVERKOOP ALS ON LINE CONTROLEMECHANISME IN RISICOVOLLE OMGEVINGEN WAARIN EEN FOUTLOZE WERKING WORDT VEREIST, ZOALS IN NUCLEAIRE FACILITEITEN, VLIEGTUIGNAVIGATIE- OF COMMUNICATIESYSTEMEN, LUCHTVERKEERSBEGELEIDINGSSYSTEMEN, MEDISCHE APPARATUUR ZOALS HART-LONGMACHINES OF WAPENSYSTEMEN, WAARBIJ EEN GEBREK IN DE JAVA-TECHNOLOGIE RECHTSTREEKS KAN LEIDEN TOT OVERLIJDEN, LICHAMELIJK LETSEL OF ERNSTIGE SCHADE AAN HET MILIEU.

Java is bedoeld voor mainstream apps, applets, servlets etc. Maar zeer zeker (en dus uitdrukkelijk) niet voor realtime, highrisk applicaties zoals de controle aplicaties in een nucleare reactor etc...
Maar dat is C#, C, C++, etc ook niet. Iig niet in de standaard uitrustingen.

De eisen die bij dat soort systemen gesteld (moeten) worden zijn _zo_ hoog dat Sun dat niet kan en wil garanderen. Wellicht dat de Realtime Java die ontwikkeld wordt er wel tegen kan, maar dit statement zegt alleen maar dat Sun er over nagedacht heeft het te melden, niet dat ze laks zijn of geen vertrouwen in hun software hebben...

[EfBe]

Volgens mij is MDAC van Microsoft. (en dus dat zo'n anti-java verklaring niet zo onlogisch is).

Btw, deze verklaring heeft betrekking op het ontbreken van support voor COM+ transactions, waardoor je op windows systemen EN gebruik makend van java, je (volgens MS) geen transactional code kunt bouwen zonder externe transaction monitor erbij te betrekken.

[ Voor 83% gewijzigd door EfBe op 04-06-2003 13:40 ]

[Glimi]

ACM schreef op 04 juni 2003 @ 11:57:
De eisen die bij dat soort systemen gesteld (moeten) worden zijn _zo_ hoog dat Sun dat niet kan en wil garanderen. Wellicht dat de Realtime Java die ontwikkeld wordt er wel tegen kan, maar dit statement zegt alleen maar dat Sun er over nagedacht heeft het te melden, niet dat ze laks zijn of geen vertrouwen in hun software hebben...

Mwoah, de software voor zulk soort producten moet gewoon bug vrij zijn. Daardoor moeten de functies die gebruikt worden te 'bewijzen' zijn.

Dat is echt heel moeilijk in imperatieve talen waarbij alles kan afhangen van factoren van buitenaf (systeemtijd bijv) of er zomaar geïnterrupt kan worden (denk aan exceptions, thread, weet ik het allemaal)
Om een functie goed te kunnen bewijzen is het eigenlijk van belang dat deze 'puur' is, dwz de functie geeft met bepaalde input ALTIJD dezelfde output, en niet opeens andere output door user input oid

Soms wordt gebruik gemaakt van de (meta )taal Z geloof ik, om dit te bewijzen voor de procedures. Maar veel weet ik daar niet van af, daar kunnen Efbe en MSalters wel meer over vertellen

[ Voor 3% gewijzigd door Glimi op 04-06-2003 14:17 ]

[Slagroom]

EfBe schreef op 04 June 2003 @ 13:38:
Volgens mij is MDAC van Microsoft. (en dus dat zo'n anti-java verklaring niet zo onlogisch is).

Btw, deze verklaring heeft betrekking op het ontbreken van support voor COM+ transactions, waardoor je op windows systemen EN gebruik makend van java, je (volgens MS) geen transactional code kunt bouwen zonder externe transaction monitor erbij te betrekken.

Denk ik niet:

Sun Microsystems, Inc. heeft Microsoft contractueel verplicht deze verklaring op te nemen.

[alienfruit]

Naja, elke software heeft wel zo'n disclaimer, hoop ik
Want anders als het stuk software problemen veroorzaakt met het OS en/of hardware, waardoor het systeem crasht en jij was bezig met je fantastische script.

[Olaf van der Spek]

Glimi schreef op 04 June 2003 @ 13:40:
Dat is echt heel moeilijk in imperatieve talen waarbij alles kan afhangen van factoren van buitenaf (systeemtijd bijv) of er zomaar geïnterrupt kan worden (denk aan exceptions, thread, weet ik het allemaal)
Om een functie goed te kunnen bewijzen is het eigenlijk van belang dat deze 'puur' is, dwz de functie geeft met bepaalde input ALTIJD dezelfde output, en niet opeens andere output door user input oid

Imperatieve talen eisen toch niet dat een functie afhankelijk is van externe factoren?
Als jij je functies zo schrijft dat ze niet puur zijn ligt dat aan jou en niet aan de taal.

[mbravenboer]

Programmeren met state is de opzet van een imperatieve taal, dus het zou ook een merkwaardige eis zijn (voor een imperatieve taal)

[MSalters]

ACM schreef op 04 June 2003 @ 11:57:
Volgens mij vergeten jullie even de context waarin je dit moet lezen...

DE JAVA-TECHNOLOGIE IS NIET FOUTBESTENDIG EN IS NIET ONTWORPEN, VERVAARDIGD OF BEDOELD VOOR GEBRUIK OF WEDERVERKOOP ALS ON LINE CONTROLEMECHANISME IN RISICOVOLLE OMGEVINGEN WAARIN EEN FOUTLOZE WERKING WORDT VEREIST, ZOALS IN NUCLEAIRE FACILITEITEN, VLIEGTUIGNAVIGATIE- OF COMMUNICATIESYSTEMEN, LUCHTVERKEERSBEGELEIDINGSSYSTEMEN, MEDISCHE APPARATUUR ZOALS HART-LONGMACHINES OF WAPENSYSTEMEN, WAARBIJ EEN GEBREK IN DE JAVA-TECHNOLOGIE RECHTSTREEKS KAN LEIDEN TOT OVERLIJDEN, LICHAMELIJK LETSEL OF ERNSTIGE SCHADE AAN HET MILIEU.

Java is bedoeld voor mainstream apps, applets, servlets etc. Maar zeer zeker (en dus uitdrukkelijk) niet voor realtime, highrisk applicaties zoals de controle aplicaties in een nucleare reactor etc...
Maar dat is C#, C, C++, etc ook niet. Iig niet in de standaard uitrustingen.

C# niet. C en C++ wel. Uiteraard heb je zoiets als een zwakste-schakel effect, dus het OS en de HW moet ook aan dat soort eisen voldoen. Maar C++ op Stratus is veilig genoeg om Rotterdam droog te houden (Het BOSysteem van de Maeslant kering )

De eisen die bij dat soort systemen gesteld (moeten) worden zijn _zo_ hoog dat Sun dat niet kan en wil garanderen. Wellicht dat de Realtime Java die ontwikkeld wordt er wel tegen kan, maar dit statement zegt alleen maar dat Sun er over nagedacht heeft het te melden, niet dat ze laks zijn of geen vertrouwen in hun software hebben...

Realtime is iets heel anders; dat wil je ook al in een auto hebben waar "maar"een paar doden vallen als het fout gaat. Zelfs in een mobieltje heb je soms realtime functionaliteit nodig - dan is RealTime Java eerder op z'n plaats.