Oracle kan verplicht worden om te waarschuwen bij onveilige Java-versies

Volgens een aanklacht van de FTC heeft Oracle gebruikers misleid door te stellen dat bepaalde updates beveiligingsproblemen in Java zouden oplossen. Er is nu een voorstel opgesteld waarbij Oracle gebruikers moet inlichten over het verwijderen van onveilige versies van Java.

Oracle nam Sun en daarmee Java over in 2010. Sindsdien heeft het volgens de klacht van de Amerikaanse FTC stelselmatig gebruikers verkeerd geïnformeerd over de veiligheid van Java. Het bedrijf beweerde dat oude, onveilige versies van het programma zouden worden verwijderd tijdens de installatie van een nieuwe versie.

Het bleek echter dat alleen de voorgaande versie werd verwijderd, waardoor allerlei oude versies op het systeem achterbleven. Eerder was het namelijk zo dat er tijdens de installatie van Java nieuwe versies naast oude versies geïnstalleerd werden. Het probleem hierbij was dat de oude versies van Java veel beveiligingsgebreken bevatten.

De partijen zijn tot een voorlopige overeenstemming gekomen, waarbij Oracle twee jaar lang gebruikers via een mededeling op zijn website moet informeren over de misleiding en informatie moet verstrekken over hoe zij zich beter kunnen beschermen. Ook zou een dwangsom van omgerekend ongeveer 14.500 euro per nieuwe overtreding onderdeel zijn van het voorstel, dat over dertig dagen van kracht kan worden. Uiteraard moet Oracle ook mogelijkheden bieden om de verouderde Java-versies te verwijderen.

Reacties (51)

[Aetje]

Met als resultaat dat volgende updates alle oude versies wel opruimen - maar waarbij vergeten wordt dat Java niet altijd even backwards compatible is. Die problemen spelen bij veel corporate omgevingen - zelf ondersteun ik ook een klant die nog altijd van een JRE 1.6 gebruik maakt omdat enkele applicaties niet werken op hogere versies.

Geen geweldige API wat dat betreft.

[snrwo1]

dan vraag ik mij af waarom ze nog met de SW werken waar die JRE 1.6 voor noodzakelijk is. Dom dom en opeens moet je, maar dan is er natuurlijk geen tijd/geld.

[DinoBe]

Goh, de software van de Belgische federale overheid voor het uitreiken van de elektronische identiteitskaarten werkt enkel en alleen met java 1.6.45.....

[Kees]

Omdat ze bijvoorbeeld servers van 5 jaar oud gebruiken waar de remote console alleen werkt met Java 1.6 en er geen firmware updates voor zijn.

Om die reden heb ik in een 'java' directory in mijn homemap ook allerlei oude versies van Java staan, puur zodat ik die oude beheerssoftware nog kan draaien. En daar is weinig onveilig aan, ik moet het handmatig aanroepen, staat niet in een path, zit niet in de browser. Daar kan weinig fout gaan.

[Aetje]

Voornamelijk omdat er gewerkt wordt met legacy pakketten die met allerlei kunst, vlieg en scriptwerk aan elkaar gehaakt zijn waardoor een upgrade voor een ondersteuning van een hogere API versie de-facto betekent dat je je gehele IT van de grond af aan opnieuw gaat opbouwen. Wat opzich geen slechte zaak zou zijn, maar zie maar eens toestemming bij de directie te krijgen voor een dergelijk project. Nee, totdat er een gevaarlijk incident vastgesteld wordt waardoor van bovenaf met de "en nu veilig" mokerhamer gezwaaid wordt en daarmee het fundament onder de legacy systemen weggeslagen wordt, zie ik nog niet snel een upgrade komen. En ik vrees dat dit bij veel (overheids en grote corporaties) bedrijven het geval is.

Bij IT security wordt er te veel gedacht aan VPN, firewall, wachtwoord complexiteit... en niet aan de fundamentele opbouw van je eigen infrastructuur. Ander recent voorbeeldje: Flash was vanwege die zero day lekken uitgebannen, maar moest op last van boven weer actief gezet worden omdat een online training van een extern bedrijf flash vereiste... Maar tegelijkertijd zijn zo ongeveer alle IT beheerders hun admin rechten wel kwijt "omdat dat veiliger is". Prioriteiten...

[Edit] @hierboven: Windows XP en zelfs 98 zie ik hier en daar nog altijd gebruikt worden. Wederom ivm gebrek aan backwards compatiblitity. Win98 was de laatste (stabiele *hoestMEhoest*) versie die 8 bits applicaties ondersteund. WinXP de laatste die 16 bits applicaties ondersteunt. Sommige van dat soort legacy meuk is simpelweg niet te moderniseren, of de wil/middelen om het te doen ontbreken.

[Reactie gewijzigd door Aetje op 23 juli 2024 14:39]

[Oyxl]

Even voor jouw beeldvorming, álle overheid en het gros van het bedrijfsleven gebruiken zwaar verouderde java versies, zoals 1.6. Dat is geen uitzondering, dat is regel.

Dat java (niet de taal) een kudtproduct is waar elk lek gepatched wordt met een lek wordt even buiten beschouwing gelaten. Dat elk bedrijf javaW.exe standaard op de firewall toestemming geeft, dat vind men allemaal maar best. Veiligheid is vooral schijn naar buiten toe, maar je moet niet in de keuken kijken.

Er zijn geen organisaties die geld uitgeven totdat het noodzakelijk wordt en dat merk je pas de afgelopen paar jaar echt, i.v.m. het verdwijnen van winXP.

[TonnyTonny]

Applicaties die een specifieke versie nodig hebben kunnen die in hun eigen software folder opslaan en die gebruiken in plaats van de systeem-wijde default Java. (Dat is ook de officiële aanbeveling.)
(Versie 1.6 is sowieso niet zo erg. Die krijgt zelfs nog security-updates. Ik kom 1.3 en 1.4 nog tegen...)

Die systeem-wijde Java is specifiek waar we het hier over hebben.
Ik zou het overigens een ramp vinden als hij echt oude versies verwijderd. Ik heb gevallen waar ik 1.6, 1.7 rn 1.8 naast elkaar op systeem niveau nodig heb omdat sommige software botweg de system-Java gebruikt i.p.v. zijn eigen copy.
Wat een veel betere oplossing zou zijn in mijn optiek is dat de installer je waarschuwt en je de optie geeft om de oudere versies te updaten naar de laatste (indien beschikbaar) en/of te de-installeren. Is de keus aan jou.

Als ze toch die installer updaten moeten ze tevens verplicht worden die Yahoo/Ask zooi (of whatever er ze deze week instoppen...) er uit te halen. Als ik die meuk wil hebben (alleen al dit schrijven geeft me een vieze smaak in de mond...) installeer ik het zelf wel.

[kdekker]

Er is een setting waarmee je automatisch 3rd party spul verbied. Ben even de setting kwijt.
En iedereen een eigen kopie van java is een crime wat betreft updaten (voor bijv. beveiligingslekken). Zo gek is het idee niet om slechts 1 runtime (of JDK) op 1 systeem te hebben.

[TonnyTonny]

Sorry voor de late reactie... Kerstvakantie :-)

Die setting: Weet ik, maar om dat op iedere PC opnieuw te moeten instellen... Zou niet nodig moeten zijn. Of in ieder geval de mogleijkheid geven om bij de allereerste install te zeggen "ik wil die meuk nooit" en dan maakt hij zelf de setting.

Wta betreft 1 kopie: In een perfecte ideale wereld heb je gelijk. Maar Java main-versies zijn niet altijd 100% compatible met elkaar en het zeer begrijpelijk dat een applicatie-ontwikkelaar liever de versie waarmee ontwikkeld en getest is vastkoppeld aan zijn software.
Het grote probleem is dat er stupide ontwikkelaars zijn die, als ze een gegeven versie eisen, deze niet in hun applicatie embedden, maar toch de systeem-versie willen gebruiken. (Dit is ook TEGEN de Java development guidelines.)

En dan krijg je klote-situatie dat je meerdere systeem-java's naast elkaar aktief moet hebben. Gelukkig heb je dan nog wel in het java-configuration scherm de mogelijkheid om de laatste als default te zetten. Als een applicatie niet expliciet een bepaalde versie vraagt krijgt hij die default. (En de default "defaults" naar de versie met het hoogste versie-nummer, als je zelf niks instelt. Dat is vrij safe dus.)

In een thuis-situatie maakt het meestal niet veel uit en kun je gewoonlijk volstaan met 1 (de laatste) systeem-java.

Maar in een zakelijke omgeving met veel legacy software die om business-redenen niet kan worden vervangen/ge-upgrade... Soms is het behoorlijk prutsen.
Ik heb situaties gehad waar we voor 1 applicatie (uiteraard de leverancier failliet en geen support meer) de gebruikers een VM moesten geven met een zeer specifieke Java omdat de software ALLEEN werkte met expliciet versie 1.6.0.XX en die moest dan ook nog eens als default systeem-java ingesteld staan. Uiteraard was die versie hopeloos verouderd, maar de software weigerde zelfs te maar starten ("incorrect Java version detected") als je hem naar de laatste 1.6 upgrade.
Uiteindelijk heeft één van onze programmeurs met een debugger en een hex-editor the executable gemodificeerd zodat die versie-check altijd succesvol was, ongeacht welke 1.6 versie er aanwezig was.
Toen bleek dat de software gewoon werkte met de allerlaatste 1.6. (Maar niet met 1.7 en 1.8.)
Dus tegenwoordig draaien we de (aangepaste) software weer gewoon normaal en laten we op die machines 1.6 staan (maar dan wel in de laatste versie, die nog steeds security updates krijgt).

[CAPSLOCK2000]

Met als resultaat dat volgende updates alle oude versies wel opruimen - maar waarbij vergeten wordt dat Java niet altijd even backwards compatible is. Die problemen spelen bij veel corporate omgevingen - zelf ondersteun ik ook een klant die nog altijd van een JRE 1.6 gebruik maakt omdat enkele applicaties niet werken op hogere versies.

Het is geen fraaie situatie want je moet kiezen tussen twee kwaden: oude, onveilige software gebruiken of (veel) geld investeren in iets nieuws.

Momenteel is de default keuze om de beveilingsproblemen maar voor lief te nemen. Een luie admin die niet zelf nadenkt maar gewoon de defaults accepteert is zo makkelijk af, alles blijft werken (zolang je niet gekraakt wordt) en je kan toch zeggen dat je alle updates hebt geinstalleerd
De nieuwe default zorgt er voor dat de luie admin in de problemen komt, opeens werkt oude software niet meer. Hierdoor wordt de admin gedwongen om een bewuste keuze te maken. Helaas zal dit in een aantal gevallen betekenen dat updates helemaal worden uitgeschakeld maar dat is nog altijd beter dan de huidige situatie. Momenteel worden goedwillende maar ontwetende admins benadeeld in het voordeel van de luiheid, gemakzucht of onverschilligheid van hun collega's.

Nu wordt het omgedraait. Wie de afgelopen jaren braaf z'n updates heeft geinstalleerd en de applicaties heeft bijgewerkt die heeft geen enkel probleem. Wie de boel jarenlang heeft laten verstoffen en niet heeft geinvesteerd in modernisering die gaat het nu rauw op z'n dak krijgen.

[kdekker]

Ik ken eigenlijk geen taal waar in opvolgende versies geen (kleine) incompatibiliteiten kwamen. Waar fouten gemaakt worden (dat kan ook in het ontwerp van een taal) worden ook fixes gemaakt. Die kunnen soms incompatibel zijn.

Ik ken Java niet zo goed, maar dacht dat Java redelijk compatibel is. In ieder geval zijn er genoeg talen die vele malen incompatibeler zijn (bijv. Visual Basic). Juist talen die breed gedragen zijn en gestandariseerd (C/C++) komt incompatibiliteit veel minder voor. Java is wel een standaard, maar lang door 1 bedrijf gedomineerd. Daarom vergelijk ik met VB. Daar is de overstap van VB.6 naar bijv. VB.net meer incompatibel dan de java 1.6, 7 en 8 versies, toch?

De basisregel voor programmeertalen en (systeem)bibliotheken zou moeten zijn dat je APIs niet breekt. Nieuwe APIs toevoegen kan. En na lange tijd eventueel oude opruimen kan dan ook nog. Met het toverwoord security kun je soms ook wat bereiken (ik doe geen uitspraken of dit terecht of mogelijk onterecht gebruikt wordt).

[Jojakim]

Zou java nog eens dezelfde kan op kunnen gaan als Flash, dat het verbannen wordt omdat er te vaak lekken inzitten? Of is het daar te onvervangbaar voor?

[CyBeRSPiN]

Het is inderdaad de browser addon die risico's oplevert. Java als taal is niet inherent onveilig, al lijkt men die conclusie hier vaak welk te trekken.
"C++" is in die zin nog veel onveiliger

[kdekker]

Een taal is nooit onveilig, maar de programmeur die onveilige dingen programmeert i.c.m. de rechten waaronder een programma draait.

Wel is waar dat de ene taal makkelijker 'onveilige' dingen toestaat c.q. niet waarschuwt. Dat heeft aan de ene kant te maken met bijv. buffer overflows (die je in de ene taal makkelijker voor elkaar krijgt als een andere) en de bijbehorende (systeem) bibliotheken.

Op zich zou een browser plug-in nooit onveiliger moeten zijn dan de rechten waar de browser zelf draait. Als de browser niet met de kernel kan bemoeien + de rechten van de browser tot een minimum beperkt zijn, zou zelfs een slecht geschreven plug-in niet meer dan de browser(sessie) onderuit halen. Met nadruk op zou

[svenslootweg]

Ik zou stellen dat een taal die onnodig of te gemakkelijk onveilige dingen toestaat (denk hier aan PHP, C, C++, ...) ook als "onveilig" gezien kan worden, omdat dit simpelweg een ontwerpfout is. Het ontwerp van een taal is van zeer grote invloed op de kwaliteit van de programma's die erin geschreven worden.

Zie als tegenstelling bijvoorbeeld Rust, waar code standaard veilig is en je uitdrukkelijk ervoor moet kiezen om onveilige code te schrijven. Dit is een stuk veiliger.

[Reactie gewijzigd door svenslootweg op 23 juli 2024 14:39]

[r_j]

Dat is natuurlijk onzin. Dat C geen runtimecheck doet moet je zien in de tijd. Op het moment dat het ontwikkeld werd was machinetijd kostbaar, en snelheid cruciaal. Als je zoals ik begonnen bent met assembler programmeren is C al een enorme vooruitgang (met z'n standaard loopcontrukties). Ik praat hier over de jaren 70 en 80 van de vorige eeuw. Wij zeiden toen al dat C een luxe assembler was!

[svenslootweg]

De geschiedenis van C heeft geen bal te maken met hoe veilig het is. Op z'n hoogst zou je kunnen stellen dat er destijds geen veiligere optie was - prima, maar dat heeft natuurlijk nul relevantie voor een discussie die we in 2015 hebben, nu dat geen probleem meer is.

"Het is veilig" en "het is niet veilig, maar we hadden geen andere keus" zijn twee heel verschillende beweringen, die je absoluut niet met elkaar moet verwarren.

[kdekker]

Ik ken de taal 'rust' niet. Een snelle scan leert dat deze taal bewust ontworpen is voor veiligheid. Ik vermoed dat de taal (gezien de ontstaansdatum) niet gebruikt wordt als bijv. kerncomponent in bijv. een operating systeem.

Omdat ik op AIX, HPUX, Linux (diverse smaken), Solaris, Windows en nog vele andere OS versies werk(te), valt een nieuwe taal ook al af, domweg omdat de platform support onvoldoende is. Windows & Linux gaat vaak nog wel, maar daar houdt het dan vaak ook op (zo ook voor de taal rust aldus de Engelse Wiki).

Eerlijk gezegd mag je ook wel verwachten dat een taal uit 2012 geleerd heeft van een taal die bijna 50 jaar oud is. Daarbij: als er eenmaal een code base is die gebruik maakt van een bepaalde taal, kun je ook niet zomaar overschakelen. Dit is geschiedenis waar je als bedrijf/programmeur aan vast zit.

En verder sluit ik me aan wat r_j zegt. 50 jaar geleden woekerde je met CPU kracht en geheugen. In zekere zin is dat nu terug, maar is geheugen goedkoper, zodat je daar meer op kunt gaan leunen. Maar in alle gevallen had je 15+ jaar geleden niet de luxe om alles 3 dubbel te checken (op overflows etc). De geschiedenis speelt wel degelijk hier een rol.

Maar mijn hoofdpunt van kritiek was: al is de taal nog zo veilig, als je er dingen mee kunt die ingrijpen op het functioneren van je systeem, dan is sandboxing en privilege management veel belangrijker. Het is niet voor niets dat ook op Unix varianten dingen komen waardoor root ook (lang niet altijd meer) alles mag (of in kan zien).

Wat dat betreft is Windows van den beginne af verkeerd ontworpen (single user die ook nog eens admin was). Ondanks dat het nu (veel meer) multi-user is, zijn er nog steeds dingen waaraan je de single user erfenis kunt afleiden.

Voorbeeld 1: probeer eens alle user data op een non-system drive te krijgen, c.q. een default home drive, anders dan de default. Het is een crime (lastig of veel werk) om dit voor elkaar te krijgen.

Voorbeeld 2: het elevated verhaal is een 'beperking van de schade van de veel gebruikte (en soms noodzakelijke) je moet admin zijn' mentaliteit. Je ziet dat Windows hier wel evolueeert naar iets beters dan wat het was, maar *NIX heeft altijd al vanaf de andere kant gewerkt (werk met de minste rechten).

[mxcreep]

In PHP is anders prima in de php.ini en included files in te stellen wat wel en niet mag, dat men het niet doet is niet de schuld van de taal. Het gaat hier dan ook meestal om allerlei modules in plaats van de 'core' taal zelf.

Ikzelf hou wel van die flexibiliteit in een taal, het is aan de programmeur om de verantwoordelijkheid te nemen wat wel en niet kan. Helaas hebben veel programmeurs weinig kennis van wat bepaalde onderdelen uit de taal nu werkelijk op het systeem zelf doen. Men leert een taaltje en niet de totale interactie die plaatsvind met een systeem en dat is naar mijn mening slecht. Echt een 'het werkt toch' houding kom je veel tegen terwijl er dan zeer slechte code is geproduceerd.

Vaak is het dan aan de taal om de boel maar af te schermen maar in de praktijk verzint met dan allerlei rampen constructies om dat wat je niet zou moeten willen toch voor elkaar te krijgen.

[svenslootweg]

Nee. Ongeacht hoeveel je PHP configureert (en dat zou sowieso niet nodig moeten zijn - secure defaults zijn essentieel), zijn er vele problemen die tot onveiligere code leiden. Het valt niet te fixen. Dat heeft overigens heel weinig te maken met "flexibiliteit" - Javascript bijvoorbeeld is vele malen flexibeler dan PHP, en is alsnog een veel veiligere taal om in te werken.

Om maar even een voorbeeld te noemen: probeer maar eens een stukje code te schrijven in PHP dat een JSON-string decode, en het herkent als de betreffende input ongeldig was. Ik kan je bijna garanderen dat je het fout doet.

[Reactie gewijzigd door svenslootweg op 23 juli 2024 14:39]

[Neko Koneko]

Het is inderdaad de browser addon die risico's oplevert. Java als taal is niet inherent onveilig, al lijkt men die conclusie hier vaak welk te trekken.
"C++" is in die zin nog veel onveiliger

Het gaat niet om de taal maar het framework en de runtime environment waar applicaties die in de taal geschreven zijn op draaien. De browser plugin is daar een onderdeel van.

[Janoz]

Nee, het gaat hier om de browserplugin.

[Tim_bots]

Je kunt de Java plugin uitschakelen in de Java settings. Bij mij staat deze al enige tijd uit en nog maar 1 a 2 sites tegengekomen waar dit een probleem was.

De Java plugin is voor mij niet noodzakelijk.

[elley]

Leuk als je systeem beheerder bent en elk stukje hardware wel een web based management interfaceje heeft dat werkt of niet werkt met een andere versie van java.

Wordt helemaal leuk als browsers dan ook nog gaan beslissen welke api's er wel en niet mogen draaien en welke pagina's wel en niet open mogen.

Voor de meeste dingen kan je wel nog de ssh gebruiken, maar om console views te krijgen is dat meestal geen optie en wordt het hoe langer hoe moeilijker om op die hardware te geraken.

[Standeman]

Veel te onvervangbaar. Java in de browser is al zo dood al een pier (gelukkig), maar aan de server kant is het gewoon niet weg te denken, net zoals C++ of .Net

[hackerhater]

Met JAVA op zich is niks mis. Die taal wordt heel veel nog gebruikt. Vooral op servers en smartphones (Android!)
Die webplugin is een ramp en zou niet standaard geïnstalleerd moeten worden.

[leuk_he]

Java heeft alleen de NPAPI plug-in. deze wordt niet ondersteund in moderne chrome browsers, en zonder op te zoeken, denk ik ook netscape.

Om het erger te maken, draait explorer geloof ik alleen signed applicatie, die dan verdorie niet meer zuiver in de sandbox draaien.

Kortom, java in de browser is een pad waar je echt niet meer in moet investeren. (kuch Oracle forms kuch)

[Anoniem: 58485]

Java is voor enkele dingen nog steeds gewoon vereist. Denk aan het bekijken van teletext online bijv.

[434365]

Over de web plugin, ja, hier gaan we naartoe.
Oracle zal waarschijnlijk wel beter z'n best doen dan Adobe destijds om de boel overeind te houden.

Over de niet web versie, die zal nog jaren blijven bestaan, precies hetzelfde gebeurd momenteel met flash, de webversie word overal eruit gewerkt, maar de offline versies (en dan doel ik niet alleen op flash op een pc/laptop) zullen nog jaren bestaan.

[CyBeRSPiN]

Er zijn vaak goede redenen om nog oude versies op je systeem te hebben staan.
Kan misschien beter zijn voor de veiligheid, maar ik zit er niet op de wachten als er ongevraagd versies gedeinstalleerd worden.

[atillav]

14.5 k per overtreding.....pfffff, maak daar nou eens 1 miljard van. Dat vinden ze minder prettig.

[Balder©]

Zover ik heb gezien worden bij de installaties de laatste tijd alle versies verwijderd.
Net nog uitgevoerd, 10 oude verwijderd na de installatie.
Gecontroleerd en ze zijn verwijderd.
Dit bericht zou een dik half jaar geleden hebben geklopt.

[Oerdond3r]

Door al deze negatieve berichtgeving denken mensen bij 'Java' als een ongewenst en onveilig programma dat je van je computer moet gooien.

Alleen de browser-plugin is onveilig. Ik denk dat Java ook nooit bedoeld is om code geschreven door niet te vertrouwen partijen op jouw computer te laten draaien. Gelukkig neemt HTML5/Javascript dit over waardoor het browsen een stuk veiliger wordt.

Ik vind het dat ook jammer dat Oracle het zover heeft laten komen ( de reputatie van Java zo laten zakken door de beveiliging van de browser-plugin niet serieus genoeg te nemen ) . Java zelf is namelijk nog steeds de nummer 1 (!) meest gebruikte programmeertaal en het is aan het stijgen! Ook ik vind het heerlijk om in Java programma's te schrijven

( Bron: http://www.tiobe.com/inde...paperinfo/tpci/index.html )

[Anoniem: 80487]

Die hele java runtime moet je laten wieberen, samen met flash. Soms worden sommige versies ook afgedwongen door software. Ik kan me bijvoorbeeld herinneren dat de router/switch configuratie tool van Cisco een of andere antieke versie van Java wil hebben en nieuwe varianten dus niet backwards compatibel zijn. Dat is altijd zo lekker...

[Zezura]

nog een reden waarom ik geen java wil gebruiken, en daarom haat ik dat ik het speciaal moet installeren voor android studio.

[Standeman]

Ja, gek he.. Android Studio draait op Java. Dat is in de andere ecosystemen niet veel anders behalve dat het meegeleverd wordt. Voor iOS ben je zelfs verplicht om een mac aan te schaffen...

Maar het probleem is niet zozeer java, de extreem brakke browserplugins die meegeleverd worden zijn dat wel. En dat terwijl vrijwel niemand die nodig heeft. Volgens mij staan ze tegenwoordig standaard op disabled in FireFox en Chrome (gelukkig!)

[Zezura]

ik snap dat "Android Studio" Java gebruikt dat is vrij logisch, xcode heb je inderdaad een mac nodig en voor visual studio heb je windows nodig. maar dat is toch een stukje anders dan android studio waar je jdk voor nodig hebt.

en juist omdat die browser plugin een ramp is, heb ik een hekel gekregen aan de programmeer taal: Java.

echter kan ik weeldegelijk Java, ik zal lievere in de C talen schrijven, en tegenwoordig schrijf je voor veel kleine dingen, of extendable voortaan in Javascript (HTML5).

[Anoniem: 197341]

"en juist omdat die browser plugin een ramp is, heb ik een hekel gekregen aan de programmeer taal: Java."

Je verwart een runtime met een programmeertaal. Wat maakt het überhaupt uit of je in C#, java of c++ programmeert?

[Zezura]

Wat het uitmaakt .. Nou de runtime programmeertaal en de omgeving om in te werken.

Visual studio is super tof. Vergeleken met netbeans of eclipse.

[wvc_]

Wat bedoel je met 'super tof' ?
Ik snap ook niet goed waarom je met Android Studio werkt als je een hekel hebt aan Java. Je kan Android Apps ook bvb maken met Xamarin dan kun je de super toffe IDE Visual Studion gebruiken (heb zelf geen ervaring met Xamarin dus verbeter me maar indien nodig).
Tevens zijn er nog andere IDE zoals IntellIJ welke krachtige en toffe features heeft.

[Zezura]

als ik al Android schrijf zal ik het of in Java doen of in C++ maar ik ga niet zoiets als xamerin gebruiken. Toen ik er naar keek kosten dat flink wat geld. Vind het alleen niet fijn heel die Java wereld zoals de IDE's de taal en de runtime. Ik ben meer geneigd om de andere talen te gebruiken, dat staat me meer. Ieder heeft zijn voorkeuren.

[r_j]

Het is sowieso al ouderwets om Java of C/C++ te schrijven. Dat genereer je toch gewoon... Daarmee worden dan meteen de 'standaard programmeer fouten' voorkomen. Voorbeeld: Voor professionele transactiegerichte applicaties CA-Gen (Kan Cobol!!, C of Java genereren), of voor wat kleinere dingen Outsystems (www.outsystems.com).

[kdekker]

Waar dacht je waar de code generators in geschreven zijn? (vaak C/C++ of Java)?

En door wie? (mensen die fouten maken).

Je hebt gelijk dat codegeneratoren fouten kunnen voorkomen, maar daardoor is de flexibiliteit ook minder. Je ziet wel regelmatig een mix ontstaan: een deel van de applicatie (uiterlijk) is modelleerbaar (wat niet hetzelfde is als programmeren), maar maatwerk is toch vaak programmeerwerk (in wat voor taal dan ook).

[Zezura]

denk niet dat dit soort systemen echt het verschil zullen maken, ja voor bedrijfjes die simpele oplossingen nodig hebben waar je een app aan een database hangt of rest.

maar niet waar ik momenteel aan werk.

[gimbal]

Raar verhaal, de browser plugin heeft totaal niets met de programmeertaal te maken. Je raakt zelf al Android studio aan - Voor Android wordt ook de Java taal hergebruikt, geen browser plugin te bekennen in de SDK of runtime.

De haat zit te diep.

[Standeman]

Tja, ik ga geen heel platform afschrijven vanwege een brakke plugin die praktisch niemand nodig heeft. Dat is imo toch echt wel de baby met het badwater weggooien.

[Zezura]

zo heeft elk gek zijn gebrek, ik programmeer liever in andere talen.

[Anoniem: 343906]

http://www.infoq.com/news/2015/05/android-studio-1-3

[Pathogen]

Nou woeptiedoe... Dit klinkt niet als iets dat daadwerkelijk gevolgen heeft voor Oracle. Zelfs als het 2 weken duurt voordat ze de website hebben aangepast is het peanuts voor een bedrijf in deze orde van grootte.

[haling]

Nou woeptiedoe... Dit klinkt niet als iets dat daadwerkelijk gevolgen heeft voor Oracle. Zelfs als het 2 weken duurt voordat ze de website hebben aangepast is het peanuts voor een bedrijf in deze orde van grootte.

Helaas maakt zo'n veroordeling Oracle geen criminele organisatie, anders zou het voor overheden onmogelijk worden om er zaken mee te doen. Net als draaideurcrimineel Microsoft.

Ergens is dat wel krom; des te groter de organisatie, des te meer veroordelingen ze op hun naam mogen hebben voordat ze op een zwarte lijst terecht zouden komen.