Oracle dicht tientallen ernstige kwetsbaarheden in Java

Oracle dicht in een patch die dinsdag uitkomt 36 kwetsbaarheden in Java, waaronder 34 kwetsbaarheden die op afstand zijn te misbruiken en daardoor als ernstig te classificeren zijn. In totaal worden dinsdag 147 kwetsbaarheden in Oracle-producten gedicht.

De 34 Java-kwetsbaarheden die op afstand zijn te misbruiken zijn het ernstigst: die stellen een aanvaller mogelijk in staat om bijvoorbeeld vanuit een webbrowser malware te installeren op de pc van de gebruiker. Het is niet duidelijk bij hoeveel van de kwetsbaarheden dat daadwerkelijk kan. In een van de gevallen gaat het om een kwetsbaarheid waarvan de ernst op een schaal van 1 tot 10 een '10' meekrijgt.

Oracle geeft elk kwartaal een grote beveiligingspatch uit. In totaal worden 147 bugs geplet in de opkomende patchronde, waarmee het een van Oracles grootste patchrondes tot nu toe is. Naast kwetsbaarheden in Java worden ook beveiligingsproblemen in Solaris, Oracles databasesoftware en Oracle Fusion gedicht.

Kwetsbaarheden in Java worden vaak gebruikt om malware te installeren. Daarvoor worden kant-en-klare tools gebruikt, zogenoemde exploit kits. Via malafide banners of door een website te hacken wordt de exploit kit aan slachtoffers geserveerd. In het verleden boden meerdere grote Nederlandse websites per abuis exploit kits aan, waaronder NU.nl, NRC.nl en Telegraaf.nl. Onlangs verspreidde het Surinaamse ministerie van financiën malware via bugs in Java.

Reacties (129)

[OMX2000]

Behoorlijk zorgelijk dat ze in een klap tientallen bugs fixen. Ik zou me er beter bij voelen als er wekelijks hooguit 2-3 bugs gepatcht worden. Misschien moeten ze zoals Microsoft met XP bijvoorbeeld een half jaar alleen maar security bugs fixen.

[Milmoor]

Oracle heeft Java 8 uitgesteld om de patchen. Dat is wat anders dan wekelijkse patchen, maar geeft wel aan dat ze er serieus mee bezig zijn.

[Reactie gewijzigd door Milmoor op 23 juli 2024 15:50]

[BeyondThunder]

Java is noodzakelijk in veel bedrijfsomgevingen, maar als system administrator wordt je er soms wel tureluurs van. Kent iemand een goede tool om java (updates) te automatiseren?
Thuis gebruik ik geen java.

Veel (niet bijgewerkte) java apps / intranet sites werken ook gewoon niet meer met de laatste versies van java.

[Reactie gewijzigd door BeyondThunder op 23 juli 2024 15:50]

[34749]

Voor updates kan je de MSI instal gebruiken: http://www.java.com/en/download/faq/deploy-sysadmin.xml

Daarnaast is in een van de laatste versies de Deployment Rulesets geintroduceerd: http://docs.oracle.com/ja...web/deployment_rules.html . Hiermee kan je per web applicatie instellen welke beveiligings instellingen gebruikt moeten worden en of Applets uberhaupt geactiveerd mogen worden.

[WhiteDog]

MSI install? De naam onwaardig. Het is gewoon hun eigen installer verpakt in een MSI (lees: MSI pakt setup.exe uit en start die op, geen gebruik van echte MSI features). Moesten ze eens 10 minuten tijd steken in een echte MSI dan zou er al heel veel opgelost zijn.

Al jaren proberen wij Java op een gecontroleerde maar vooral probleemloze manier uit te rollen in ons bedrijf. Things I have seen can not be unseen

En voor wie denkt "het is gratis, niet zeuren": we hadden een enterprise agreement rond Java.

Gelukkig zijn we er binnen een paar jaar vanaf. Geen tablet of smartphone die het ondersteunt, geen consument die het nog wil gebruiken. Think about it: hoeveel flash zie je nog (op games na)?.

[34749]

Ik geloof je meteen; Ik heb zelf geen Windows workstations onder beheer (allemaal CentOS) en Servers zijn allemaal OmniOS waarbij ik OpenJDK voor IPS zelf gepackaged heb.

Aangezien ik zelf geen ervaring met MSI heb een oprechte vraag; Kan je niet zelf een MSI package maken die voor je werkt?

[TunefulDJ_Mike]

Ja je kan een losse msi maken van je Java pakket, echter de software daarvoor en de cursus (zo makkelijk is het niet) kosten een paar duizend euro, dus tenzij je alle software om gaat zetten naar msi is het dat niet waard. Overigens zijn er bedrijven die gespecialiseerd zijn in deze werkzaamheden, maar dat kost natuurlijk ook geld.

[WhiteDog]

Wat jij bedoelt heet "repackaging". Dat heb ik ooit vele jaren gedaan (vandaar de ervaring met Java installers). Voor een stukje software dat maandelijks een update krijgt is dat echter niet de beste manier en probeer je voornamelijk de setup van de vendor te gebruiken.

Java is op zich makkelijk te repackagen, het zijn gewoon wat files en registry keys. Maar dat wil je dus niet elke maand doen (en betalen). Je hebt ook geen support op je installatie op die manier.

De problemen met de Java installer (silent install) van Oracle zelf zijn vooral:
- afwijkend gedrag tussen versies (elke build heeft weer zijn eigen bugs)
- slecht omgaan met draaiende Java processen tijdens de upgrade
- Installer die aangeeft dat alles gelukt is terwijl er een half lege Java folder op je systeem staat

Allemaal dingen die Oracle makkelijk kan oplossen door een volwaardige MSI te bouwen. Die komt met JRE 8 is ons beloofd

Gelukkig worden meer en meer bedrijven zich bewust dat hun software op een bedrijfsnetwerk moet geïnstalleerd en onderhouden worden en leveren ze zelf al goeie MSI en MSP (patches) installaties aan. Deze knal je dan zo in SCCM en SCUP met wat parameters. Geen (dure) repackaging meer nodig!

[Oyxl]

Mijn god wat een hoop bullshit zie ik op deze pagina voorbij komen zeg.

Het is dat ik nu niet achter mn laptop wens plaats te nemen, daar staan mn tools op, maar om even wat feiten op een rijtje te zetten, dan doe ik later een lijstje van wat ik me kan herinneren van Java.

Ik ben inmiddels 6 jaar packager met uitgebreide ervaring op het gebied van SCCM, WISE, Installshield (Adminstudio) en App-V.

Java is een product dat elk bedrijf eigenlijk niet zou moeten willen. Het is een applicatie dat script uitvoert op een werkstation of bijv. Citrix server. Java wordt vaak dmv policies volledige vrijheid van handelen gegeven op zowel het netwerk als op het lokaal station. Daar gaat het eigenlijk al fout. Java voert dus script uit. Op het moment dat een gezond mens even nadenkt, kan die bedenken dat iets dat toegang heeft tot alles en SCRIPT uitvoert, met daardoor redelijk vergaande mogelijkheden, schadelijk kan zijn voor een omgeving.

Helaas is de werkelijkheid, dat veel producten gebaseerd zijn op Java. Erger nog, vaak zijn ze gebaseerd op specifieke oudere versies van Java en de applicaties worden niet bijgewerkt op basis van Java Updates, waardoor zwakke plekken in de security tot het einde der tijden open blijven staan.

Los van het feit dat ontwikkelaars Java updates niet verwerken in hun producten, maakt Java er zelf ook een potje van. Nieuwe versies bevatten vaak meer security issues dan de voorgaande versies en door de wijzigingen in Java zelf, zou je zelfs als je de version checks uit de applicaties haalt die Java gebruiken, geen gebruik kunnen maken van nieuwere java versies.

Dit zorgt voor een cirkel die niet snel doorbroken wordt. Als Java wordt geupdate moet eigenlijk de applicatie die het gebruikt ook worden geupdate. Dit betekent dat alle bedrijven die gebruik maken van Java en Java updaten, ook de applicatie moeten updaten. Aangezien veel ontwikkelaars dikke schijt hebben aan java versies (en gelijk hebben ze, security is een ROFLMAO bij JAVA) betekent dit dat de applicaties over het algemeen niet worden bijgewerkt binnen de bedrijven die er gebruik van maken, met als gevolg dat er uiteindelijk een groot aantal verschillende java versies aanwezig zijn binnen een omgeving. Dit kan door middel van Virtualisatie enigszins worden gereguleerd en security technisch is virtualisatie ook een iets veiligere methode om Java op deze manier te gebruiken, maar er blijven nog steeds zat vulnerabilities actief.

Over naar de installaties:
- Java is gewoon een MSI in een wrapper.
- Java auto-update is tricky. Door bovenstaande kun je niet zomaar de Java versie omhoog flikkeren, tenzij je omgeving alle versie-afhankelijke apps netjes virtueel heeft draaien, met daarbij java ingesloten, of, afhankelijk van de techniek, waarbij java kan worden aangeroepen. Vaak wordt gekozen voor een wijzigingsproces, met een gefaseerde uitrol.
- Een MSI is niets meer of minder dan een rij tabellen met daarin informatie.
- Java kan gewoon worden geupdate, ook al is deze actief. Als je packagers dit niet voor elkaar hebben gekregen, vraag ik me af waar ze mee bezig zijn.

Als een laatste footnote en waarschijnlijk het meest belangrijke. Datgene wat eigenlijk altijd volstaat als ze vragen of je iets weet over JAVA.... Java is een wanstaltig kutproduct.

Edit ivm zins structuur hier en daar.
Edit2: Het moge duidelijk zijn dat het hier Java SCRIPT betreft, datgene wat de Java Client afhandelt op het werkstation en niet de programmeertaal Java, maar diegenen die daar over vallen snappen volgens mij uberhaupt het verschil tussen een programmeertaal en een applicatie niet.

[Reactie gewijzigd door Oyxl op 23 juli 2024 15:50]

[SPee]

Mijn god wat een hoop bullshit zie ik op deze pagina voorbij komen zeg.

En daar doe je lekker zelf aan mee!

1. Java (de JRE) voert geen scripts uit, maar gecompileerde byte code
2. Versie afhankelijkheid komt veelal door zeer sterke terughoudendheid van de fabrikant. De Java API zelf behoud backwards compatibiliteit. Je kan nog code die voor Java 1.3 (2000) is gecompileerd nog draaien op JRE 7.
3. Je hebt gelijk dat veel ontwikkelaars zich té afhankelijk van een bepaalde versie zijn. (al dan niet ingegeven vanwege (onderhouds)contracten)
4. Security staat (nu) hoog op de agenda
5. Je kan meerdere JRE naast elkaar hebben staan. Een installatie is niet echt nodig. Sommige applicaties leveren het zelfs als directory mee.

[Oyxl]

Correct op bijna alles. Wat wil je dat ik daarmee terug neem? Het feit is dat op elke regel uitzonderingen bestaan en dit neemt niet weg dat die backwards compatability geen 100% feit is, maar slechts een algemene regel die absoluut niet van toepassing is in alle gevallen. Dit kan zowel aan de applicatie liggen als aan Java zelf. Als je goed leest zeg ik ook niet dat het de schuld is van Oracle, ik stel alleen dat je de leverancier/ontwikkelaar nodig hebt om bepaalde ramp-producten die nieuwere versies van java niet ondersteunen open te breken om die garantie te krijgen.

I stand corrected on the Java bytecode. Waar het mij voornamelijk om gaat/ging is het feit dat het niet JAVA de programmeertaal is en dat Java, indien het data op de juiste wijze gepresenteerd krijgt, elk command vrij kan uitvoeren binnen de rechten van de user waaronder de java client draait. Aangezien dit nog best veel is over het algemeen is dit potentieel een probleem.

Het spijt me van bovenstaande, ik zit niet letterlijk IN Java, goddank niet, ik programmeer enkel C# en verder doe ik wat VBS/VB/PS, maar het punt verandert er niet door.

Security staat altijd al hoog op de agenda, alleen in het geval van Java...Java is zelf een lek. Het is het grootste lek dat op je systeem draait.

Ik ontken nergens dat meerdere java naast elkaar kunnen draaien, ik vermeld alleen dat virtualisatie bij kan dragen aan het beperken van de security risks.

[Reactie gewijzigd door Oyxl op 23 juli 2024 15:50]

[SPee]

Java heeft zelf een interne security manager waarbij je bij het starten kan aangeven wat de rechten zijn. Zo kun je verbieden om bepaalde locaties te kunnen lezen of schrijven, of een connectie te maken met enkel die ene website. (lees meer hier)

Maar dit brengt veel complexiteit mee en wordt dus bijna nooit gedaan. Toch wel jammer.
Ditzelfde security mechanisme wordt ook voor applets gebruikt waar het al zwaarder staat ingesteld. Helaas zitten hier dus soms bugs in.

[borft]

Je weet dat de JRE een VM is? Volgens mij heb je echt geen idee hoe het java platform in elkaar zit. Als je al denkt dat javascript en java op wat voor manier dan ook aan elkaar gerelateerd zijn

[Thundy]

Leuke frustatiepost van de zoveelste zelfbenoemde Java expert die niet eens weet wat Java en JavaScript is.

Bij deze zal je dan toch maar een paar pointers geven:
Het product Java zoals geïnstalleerd op een client draait geen JavaScript maar alleen Java programmas. Zowel standalone Java programmatuur zoals oude fat client applicaties (die meestal trouwens met een eigen meeverpakte versie van Java komen), dan wel Java Applets in webpaginas met behulp van een browser plugin.

Dit alles staat volledig los van Java Script dat niet eens van dezelfde maker is.

Anyway mijn advies is simpel:
Laat je intranet applet vrij maken en laat leveranciers van standalone Java applicaties zelf een private Java Runtime meeleveren.

Dan hoef je dus totaal geen Java te installeren/onderhouden op werkstations en zijn ze ook niet vatbaar voor de security risks veelal afkomstig van het aan de browser opstellen van de Java client tbv applets.

[34749]

Als een laatste footnote en waarschijnlijk het meest belangrijke. Datgene wat eigenlijk altijd volstaat als ze vragen of je iets weet over JAVA.... Java is een wanstaltig kutproduct.

Goed beargumenteerde opmerking. Zit geen enkele frustratie in... Ik snap niet dat als je zegt zoveel ervaring met het packagen van producten te hebben dat het je dan niet lukt om Java te packagen.

Compile OpenJDK en package het zoals je zelf wilt. Ik heb zelf OpenJDK gebuild en gepackaged voor Solaris IPS en nooit problemen gehad. Of misschien moet ik zeggen "nooit problemen ervaart".

Nieuwe versies bevatten vaak meer security issues dan de voorgaande versies en door de wijzigingen in Java zelf, zou je zelfs als je de version checks uit de applicaties haalt die Java gebruiken, geen gebruik kunnen maken van nieuwere java versies.

Java is een standaard. Java 6 is Java 6 punt. De versie van de implementatie maakt niks uit voor de applicatie. Dat je kennelijk voor software van leveranciers gekozen hebt die het teveel moeite vonden om zich aan standaarden te houden zegt weinig over de taal. Zelfde kan overigens gezegd worden over .net. Hoeveel applicaties werken daar wel niet bijvoorbeeld enkel op .net 3.5?

[gise]

Je kan heel makkelijk de setup.exe starten, de echte MSI uit je appdata vissen en die aanpassen met Orca (gratis)

[WhiteDog]

Dat is het juist. Er is geen echte MSI. Een MSI een is database met bestanden registry keys, acties, ...

De Java installer is als volgt:
- Je hebt een setup die een MSI uitpakt.
- Deze MSI bevat geen mooie database maar heeft maar één actie
- Het uitpakken van wat containers en een andere setup die de uiteindelijke installatie doet.

Er wordt dus nergens gebruik gemaakt van MSI logica en technologie om bv. bestanden die in gebruik zijn bij een volgende boot te vervangen.

[[Yellow]]

Er wordt dus nergens gebruik gemaakt van MSI logica en technologie om bv. bestanden die in gebruik zijn bij een volgende boot te vervangen.

Nee, omdat dat alléén nodig is op Windows platformen. Op alle andere kun je bestanden gewoon vervangen wanneer je dat nodig acht. En als er dan tóch een bestand gelockt is (bv een database) dan kun je het pakket gewoon afsluiten zonder dat een systeem herstart nodig is..

P.S. Waarschijnlijk zullen de meesten van jullie mijn reaktie nergens op vinden slaan. Maar ik ontwikkel voor veel verschillende systemen en doe kleinschalig beheer voor Linux Mac en Windows systemen dus ik weet echt wel waarover ik praat. Voordat je me downmod a.u.b. eerst je eigen kennis doorspitten

[WhiteDog]

Daar gaat het toch niet om? Als process X (bv. een browser) bezig is met Java dan kan je onder Windows niet zomaar die bestanden vervangen. Dan moet je eerst process X sluiten of het bestand later vervangen.

Als je Java met GUI installeert maakt hij hier melding van (sluit venster). Als je Java silent installeert dan zegt hij doodleuk dat de installatie een success is terwijl er maar een halve Java meer op systeem staat... iets dat ze kunnen oplossen door bv. een echte MSI te bouwen OF een degelijke installer OF Java wat ombouwen zodat je gewoon zaken door elkaar kan gebruiken.

Hoe ga jij het "pakket gewoon afsluiten" tijdens een silent install terwijl de gebruiker met het pakket aan het werken is?

Chrome is net hetzelfde verhaal (een fake MSI) maar die vervangt zichzelf gewoon de volgende keer dat je hem start.

[johnkeates]

Wat Yellow bedoelt is dat je bij Windows files 'in gebruik' kan hebben, terwijl ze in de praktijk gewoon al in het RAM geladen zijn en prima verwijderd en vervangen kunnen worden.

Daarnaast kan je in 99% van de Linux distro's en 100% van de Mac OS X installaties gewoon nieuwe versies installeren, om dat software niet rechtstreeks een of andere binary aanspreekt, maar een binary die 'current' of de 'A-versie' is, wat vaak gewoon een symlink of een wrapper voor de huidige nieuwste versie is.

Op Windows werkt dat gewoon niet, op z'n best heb je de DLL-hell, WinSXS en een beetje WOW64, maar dat is gewoon niet te vergelijken, en door de architectuur van Windows ook nooit te 'repareren'. Windows applicaties zijn hard gelinkt aan bepaalde namen en libs. Je hebt geen ldd/ld...

[trogdor]

Daarnaast kan je in 99% van de Linux distro's en 100% van de Mac OS X installaties gewoon nieuwe versies installeren, om dat software niet rechtstreeks een of andere binary aanspreekt, maar een binary die 'current' of de 'A-versie' is, wat vaak gewoon een symlink of een wrapper voor de huidige nieuwste versie is.

Behalve, op de mac, rapapa rapapa (drumroll) : Microsoft office ! (goh wie had dat nou gedacht)
Daarvoor moet je alles van microsoft afsluiten, inclusief terminalserver sessies, en ook alle browsers. Wat the hell hebben die browsers met een office update te maken vraag je? Beats me, echt, geen idee.

[johnkeates]

Haha, ja. Net als sommige hardware vendors die denken dat je Mac OS X moet herstarten voordat je drivers kan inladen. FTDI heeft daar bijv. wel een handje van, net als Prolific.

[Reactie gewijzigd door johnkeates op 23 juli 2024 15:50]

[[Yellow]]

Dankjewel voor de reakties van de personen die meer zien dan alleen 'windows systemen in de grote bedrijven' sector. Blijft het toch nog een beetje tweakers

[twslex]

Lees http://msiwisdom.com/arti...ent-version-7-0-update-45 over wat java msi is..

[TunefulDJ_Mike]

Het programma wat wij gebruikte was iets geavanceerder, het maakte eerst een snapshot van je systeem, vervolgens installeerde je het programma en dat maakte hij weer een snapshot, zo kon je een user onafhankelijke msi installer maken, deze liet geen sporen na in bepaalde directory's of registers. Zo kon je zorgen dat bijvoorbeeld user profielen niet met onzzinge data vol werden gezet. Nu weet ik niet hoe Orca werkt, ik weet wel dat dit programma en die mensen die dit kunnen op het moment erg gewilt zijn in de IT wereld, het namelijk bijzonderhandig op Enterprise netwerken om dit soort MSI's naar eigen specificatie te hebben. Hier zijn overigens aparte banen voor, namelijk Software Package Deployment Specialists.

[ppl]

Je verwoording is veel te algemeen en daardoor voor hele andere interpretaties vatbaar. Je kunt prima zelf msi packages maken, dat is al jarenlang standaard om te doen. Je hebt dan zelf de controle over hoe iets geïnstalleerd maar bovenal ook, hoe iets geconfigureerd wordt. Als de msi van de fabrikant goed in elkaar steekt dan wordt het een heel stuk eenvoudiger omdat je dan alles via de commandline switches kunt regelen maar dat komt niet zo vaak voor (installatie is vaak geen probleem, de configuratie daarentegen wel, dat zou nog via policies kunnen als de betreffende app dat ondersteund).

Het wordt voornamelijk gebruikt om grip te houden op releases en software installaties bij de gebruiker. Doordat de gebruiker het zelf kan doen levert dat voor hun ook een voordeel op. Bij BYOD wordt er iets vergelijkbaars gebruikt.

Kortom, die software en cursussen worden voor een veel breder nut toegepast dan dat ene pakket (Java). Daardoor kost het geen geld maar levert het geld op omdat je nu efficiënter werkt.

Op werk maken we van Java ook een eigen pakket die we uitrollen. Dat komt doordat er nog het een en ander aan geconfigureerd moet worden en er nog een onderdeeltje bij komt. Dat doen we omdat de applicaties die er gebruik van maken dat bijna allemaal toch nodig hebben. Deze applicaties zijn trouwens webbased. We kunnen niet verwachten dat de gebruiker weet welke onderdelen hij moet installeren om de webbased Java applicatie die hij nodig heeft werkend te krijgen. Dat is immers ook onze taak

[Reactie gewijzigd door ppl op 23 juli 2024 15:50]

[Joolee]

Volgens mij haal je Flash en Java door elkaar. Het gedrocht Flash kan inderdaad niet snel genoeg verdwijnen. Java als browser-plugin zie je gelukkig ook bijna nooit meer (ik verwijder ook overal waar ik het tegenkom de browser plugins) maar Java als taal wordt nog heel veel gebruikt. Tomcat webservers, embedded systemen, backends voor bedrijfssoftware. Vergeet ook niet het dialect van Java dat op Android wordt toegepast.

[Pendaco]

Java als browser-plugin zie je gelukkig ook bijna nooit meer (ik verwijder ook overal waar ik het tegenkom de browser plugins)

Ik gooi de client ook van elke pc af die ik onder ogen krijg. Helaas staat Java er bij veel OEM pc's/laptops standaard op, en dan ook nog eens een 32-bit en 64-bit versie, die ook weer apart van elkaar bijgewerkt moeten worden

Nee, de Java client komt hier nergens meer op.

[borft]

Helaas zijn er soms applicaties die het nodig hebben. Bijvoorbeeld server management consoles, zoals HP (ILO) en Dell (iDrac) die aanbieden (om maar es wat te noemen). Dan kan je er bijna niet omheen.

[[Yellow]]

Think about it: hoeveel flash zie je nog (op games na)?.

Euh, Youtube?

[WhiteDog]

Euh, HTML5?
YouTube op je Android / iOS / WP al geprobeerd en nog flash nodig gehad?

[[Yellow]]

Nee, niet op mobiel nee...
Op de desktop echter: HTML5 video is nog steeds niet de standaard voor Youtube. Zowel Firefox als Safari en de oudere IE's gebruiken nog altijd Flash.

[sliekens]

Voor de gewone gebruiker: Ninite biedt een algemene oplossing onder de vorm van Ninite Updater. Deze is niet gratis, maar kan naast Java ook een heleboel andere programma's automatisch bijwerken.

[Henk Poley]

Soortgelijk en voor thuisgebruik wel gratis Secunia PSI.

[dura]

Kende ik nog niet, bedankt!

[BeyondThunder]

Ninite heb ik onderzocht toen het nog een echte start-up was. Maar ik heb het er helaas niet door gekregen in ons bedrijf. Ninite is zeer krachtig mits goed ingericht.
En (msi) packagen doe ik al meer dan 10 jaar, maar is best veel werk, Java is geen standaard app. Hetzelfde als het packagen van .NET Framework, Niet aan beginnen ;-)
Updaten doen we met SCCM, maar er blijft handwerk aan zitten.

Inderdaad maar hopen dat java doodbloedt in een paar jaar.
Verder bedankt voor de tips.

[chopper88]

Inderdaad maar hopen dat java doodbloedt in een paar jaar.

Not gonna happen!
http://langpop.com/
http://adtmag.com/article...va-most-popular-2013.aspx

Onderzoeken bieden geen harde cijfers, maar geloof me dat het einde van Java heeeel ver weg is.

Ik word wel eens moe van dat "pissen op Java", ik zou eerder zeggen "Maar hopen dat mensen eens gaan begrijpen wat Java doet/kan in een paar jaar".

[sharkwouter]

Java en Oracle Java zijn 2 verschillende dingen, al verwacht ik ook niet dat Oracle Java over een paar jaar niet meer bestaat.

[Anoniem: 415197]

Java is gewoon een nogal vreemde virtual machine technologie met een stack-gebaseerde instructieset waar heel lastig naar te compileren is vanuit andere talen. Hadden ze daar beter over nagedacht, dan was die java virtual machine misschien nog zo gek niet geweest. Maar op dit moment is het huilen met de pet op.

Sowieso hebben de Java-mensen vaak last van "one language to rule them all" syndrome. Denk je eens in dat je een OS zou gebruiken waar je maar in 1 taal voor zou kunnen programmeren. Dat zou toch onaanvaardbaar zijn? Maar Java positioneert zichzelf als een compleet platform waar dat wel voor geldt. Onacceptabel natuurlijk.

[Reactie gewijzigd door Anoniem: 415197 op 23 juli 2024 15:50]

[Anoniem: 415197]

Onderzoeken bieden geen harde cijfers, maar geloof me dat het einde van Java heeeel ver weg is.

Oracle is anders nare adware aan het meeleveren met hun Java installers/updaters.

Zie: http://www.zdnet.com/a-cl...-java-updates-7000010038/

Ik denk dat alleen al hierdoor Java heel snel niet meer serieus genomen zal worden door developers.

[johnkeates]

De kans dat C# doodbloedt is groter dan de kans dat Java doodbloedt... C# is gebonden aan .NET en aan Windows, en daarmee aan een platform dat onmogelijk opeens alle mobile device-OSsen gaat overheersen, en ook niet opeens alle mainframes en enterprise farms gaat wegduwen. Op z'n best heb je het op Windows desktop en Windows Phone. En die markt is nou niet bepaald gigantisch aan het groeien ofzo. Zelfs Objective-C is groter, en dat is de primaire taal voor Mac OS X en iOS! (Maar kan ook prima op Unix, Linux en Windows gebruikt worden om binaries mee te maken die gewoon goed draaien).

[Dreamvoid]

Mobile devices hebben hier weinig mee te maken. Wat daar gebeurt, heeft weinig invloed op Oracle's Java.

C# icm .NET wordt voornamelijk serverside gebruikt, en daar heeft Microsoft de afgelopen jaren een behoorlijke opkomst gemaakt. Net als de Linux + JEE combo overigens, het zijn alle legacy UNIX platforms die rap verdwijnen. Er is niet echt iets dat eventjes 1-2-3 de boel totaal gaat omgooien.

[johnkeates]

Zelfs PHP wordt meer server-side gebruikt van C#/.NET ...

Ja, .NET (en daarmee C#) heeft lekker zitten groeien, maar dat maakt het niet automatisch groot.

Uiteindelijk denk ik ook niet dat het opeens zal verdwijnen, net zo min als dat C, C++, Obj-C, Java of PHP zomaar zouden verdwijnen. Het gaat er om dat platformen zichzelf graag groot zien, terwijl het over het algemeen vooral over de mensen die het hardst of het meeste (als het om een groep mensen gaat) schreeuwen.

Misschien dat we in de toekomst een verschuiving zien, bijvoorbeeld dat Mantle DirectX aan de kant duwt, en door Nvidia omarmd wordt. Dan heb je opeens een cross-platform graphics API (want dat kan Mantle prima zijn, het is immers GPU en dus hardware based), wat weer opties maakt om cross-platform software te schrijven die van degelijke hardware acceleratie gebruik maken. Dat vraagt dan weer om talen die cross-platform lekker werken, en dan valt C# automatisch af. Java zal misschien nog bekeken worden, en dan kom je daarna automatisch op C/C++/Obj-C uit, want dat draait overal met native speeds. Dan heb je per OS misschien nog een loader, maar dan houdt het ook op, en kunnen we eindelijk niet meer voor het OS programmeren, maar gewoon voor hardware API's die overal beschikbaar zijn.

Waarschijnlijk is het ook vooral makkelijker om dat er nu maar 2 grote GPU en CPU vendors zijn voor de PC markt, waarbij Intel voor z'n IGP's ook nog prima Mantle erbij kan doen. Dan zitten we helemaal goed, want dan is alles gewoon x86_64 + Mantle, en kan je overal bij, zolang het OS niet in de weg zit.

[SpoekGTi]

Hey het is geen Flash he

[mutley69]

Ninite.com heeft een tool om die java te updaten. Of die veilig is??? tja - dat weet je nooit. Maar ze halen wel de reclame-ellende eruit - en dat op zich is al een dikke bonus!

[oxtan]

als je java van de ontwikkelar site download krijg je geen reclame te zien ;-), geen ask bar of dergelijke.

http://www.oracle.com/tec...e7-downloads-1880261.html

[Wim-Bart]

Het updaten van Java in een Enterprise omgeving is totaal geen probleem met RES Automation Manager/SSCM et cetera. Alles unattended, zonder dat de gebruiker er iets van hoeft te merken.

Het updaten is dan ook geen probleem, het grootste probleem met "Java troep" is dat een minor upgrade vaak door en door getest moet worden omdat soms complete bedrijfsapplicaties omvallen. Neem nu bijvoorbeeld van Java 6 naar Java 7, dat is een grote update, maar kan meestal niet omdat core applicaties omvallen. Zelfs van 6ud3x naar 6ud4x kan al een applicatie laten omvallen.

Echt, Java moet net zoals Flash gewoon worden uit gefaseerd. Java is nergens goed voor (net zoals .NET) want het beperkt de ontwikkeling van software door compatibiliteit problemen tussen versies. Daarnaast, en dat zullen Java ontwikkelaars me kwalijk nemen, biedt Java zo veel mogelijkheden om "slordig" te programmeren met de zogenaamde "garbage collection" algoritmes wat gewoon er voor zorgt dat een applicatie veel meer resources nodig heeft dan nodig is. Maar dat komt misschien doordat ik in verleden meer in C++ programmeerde en daar was het "Object aanmaken" "Object gebruiken" "Object afbreken" maar met Java en .NET zie ik mensen die gewoon alles laten afhangen van Garbage collection en niks netjes opruimen. Maar dat kan ik fout hebben.

Maar uiteindelijk, Java en .NET vreten gewoon te veel resources, meer dan nodig is.

[BeyondThunder]

Dat klopt, prima te doen met SCCM e.d. maar het blijft handwerk.
Wat je wil is een bitje omzetten zodat alle werkplekken de laatste versie van java krijgen.
Maar het test traject is inderdaad het grootste probleem.
Over .NET ben ik het niet met je eens. Deployment via Windows Updates. En een goed ingerichte ontwikkelomgeving (we hebben zo ongeveer 50 programmeurs in dienst) is erg effectief. Misschien te veel resources? Dat kan. Maar dat weegt niet op tegen de voordelen die het biedt (en de snelheid waarmee ontwikkelt kan worden).

[Thundy]

Absoluut, Java gebruikt vééél te vééél resources!
Vandaar ook dat alle grote internet giganten het ook gebruiken op hun servers!

[Wim-Bart]

En gooien er hardware tegen aan. Java is gewoon een resource vretend gedrocht. En de reden dat veel het gebruiken is omdat het portable is niet omdat het wel of geen resources zou gebruiken.

Ik heb voor grote bedrijven testen gedaan met diverse producten zoals load runner, en ik kan je zeggen, het vreet echt veel meer dan native C++ code.

[Thundy]

De rede dat deze bedrijven Java gebruiken is juist vanwege performance en stabiliteit en schaalbaarheid, dat kun je binnen 5 minuten googlen.

Ja native c++ programmas gebruiken minder geheugen, maar dienen doorgaans ook een totaal ander doel. Als je echt appels met appels wilt vergelijken, ga dan eerst eens op zoek naar een in C++ geschreven webapplicatie.

Verder zou ik je willen adviseren toch eens een stapje verder te kijken dan hoeveel geheugen iets pakt. Aangezien zowel het van te voren claimen van geheugen en het in memory houden van veel gebruikten data/code de performance juist ten goeden komen.

[Wim-Bart]

Heb geregeld gewerkt met in zowel Delphi als C++ web applicaties, vanwege de performance. Draaiend onder IIS. Het waren wel in Borland applicaties en retesnel. Bijvoorbeeld Cares uit de zorg is zo een applicatie.

[Anoniem: 486334]

Ninite gebruik ik zelf erg veel, maar is hieronder al genoemd.

Daarnaast is nog een tool genaamd JavaRa: http://singularlabs.com/software/javara/.
Dit programma kan java updaten Én oudere versies van Java verwijderen.

[Anoniem: 114984]

Misschien JavaRA ?
Ik zie dat het al geopperd was ! Maar beter dubbel dan niets!

[Reactie gewijzigd door Anoniem: 114984 op 23 juli 2024 15:50]

[RxTweak]

http://i39.tinypic.com/2dhh6qu.png

[BeyondThunder]

Ehh, de gebruiker zelf laten updaten in een enterprise omgeving. Niet verstandig.

[RxTweak]

kan prima. alleen even een handleiding schrijven voor de eindgebruikers.

[BeyondThunder]

Mijn ervaring is dat het geven van dergelijke rechten aan gebruikers veel storing oplevert, En natuurlijk zijn de gebruikers geen administrator op de werkplek.

[metalmania_666]

En als je dan nog nagaat dat een bedrijf vaak 1 versie achterloopt ivm testen en dergelijke, wordt je niet vrolijk

Het zou beter zijn als ze maandelijks patches uitbrengen

[Cobalt]

Je kan je software testen op de laatste versie van Java voordat de Java update officieel wordt uitgebracht. http://www.oracle.com/tec...nloads/ea-jsp-142245.html
of http://openjdk.java.net/projects/jdk7u/

[Anoniem: 14038]

Helemaal mee eens. Alleen is Java van opzet redelijk oud en hebben ze nooit echt rekening gehouden dat het zo snel achter elkaar gepatched zou moeten kunnen worden. Maar wat dat betreft mogen ze het update model wel wat beter stroomlijnen zodat updaten snel probleemloos en makkelijk wordt (vergelijkbaar met een smartphone app bijv).

[Dreamvoid]

Alleen is Java van opzet redelijk oud

Dat geldt ook voor Windows (NT), OS X (NeXTSTEP) en Linux, en die worden ook al decennia lang vrolijk doorgepatched. Niks mis met oudere robuuste applicatieplatforms. Wel mis is om zo'n complex en krachtig platform rechtstreeks web code te laten uitvoeren via een browserplugin

[William_H]

Die dan ook lekker standaard wordt geblokkeerd door Firefox, zodat je het ook niet per ongeluk aan kan hebben staan. Jammer voor die enkele site die het nog nodig vindt om Java te moeten draaien, maar die komt er bij mij dan helaas niet meer in.
Draai het alleen nog maar lokaal voor sommige software die het vereist (zoals Playstation/Ultimate Media Server).

[stijn_goethals]

Ik zou denken na aldie jaren dat java al volledig toe gepatch is. Ik ben blij daat er niet zo'n grote problemen zijn met de HTML5 standaaard.

[ACM]

Java en HTML5 vergelijken slaat in deze context helemaal nergens op... HTML5 is in deze context beter vergelijkbaar met de Java Language Specification en die laatste kent ook geen security bugs

Er zijn echter zat HTML5-implementaties met security bugs. O.a. browsers worden regelmatig van beveiligingsfixes voorzien. Zie bijvoorbeeld maar de diverse nieuwsberichten over Google die jaarlijks duizenden euro's aan beloningen voor security issues in Chrome betaald of bekijk de changelogs van Firefox.

Het is een meervoudig probleem, die het een stuk lastiger maken om er een simpel waarde oordeel als "veilig" of "onveilig" aan te hangen:
- Er komen nieuwe features bij in de JVM's en die kunnen in potentie weer nieuwe (security) bugs bevatten.
- Er is voortschrijdend inzicht bij security analyses, waardoor problemen die voorheen niet als security issue werden gezien of waarbij voorheen uberhaupt niet bekend was dat een bepaalde aanpak een beveiligingsprobleem kon zijn.
- Er is tegenwoordig meer rekencapaciteit en internetverbondenheid mogelijk, waardoor manieren van aanvallen voorheen onmogelijk werden geacht en tegenwoordig niet meer of er domweg nieuwe manieren zijn verzonnen.
- Er zijn issues waarvan niet echt duidelijk is of en hoe het te misbruiken is, maar dat het mogelijk ooit wel te misbruiken zou kunnen zijn. Of die mogelijk te misbruiken worden zodra andere issues naar voren komen. Die worden vaak ook als security issue gekwalificeerd.

Bovenstaande geldt overigens voor alle software, zeker bij dit soort complexe software als de JVM en webbrowsers.

[Reactie gewijzigd door ACM op 23 juli 2024 15:50]

[Milmoor]

Waarschijnlijk haalt stijn_goethals Java en javascript door elkaar. Hij is niet de enige die door de op elkaar lijkende namen in de war raakt.

[Qws]

Dan nog is het een rare vergelijking...

[34749]

HTML5 is een standaard. Het artikel gaat over de Oracle's Java implementatie. Appel, dit is peer, peer dit is appel...

Webkit is een implementatie van HTML5, Triton is een implementatie van HTML5, Gecko is een implementatie van HTML5. En ja die hebben ook weer zo hun eigen problemen.

[batjes]

Trident*

[benjamin94]

Het probleem is dat er telkens nieuwe libraries worden geschreven en dat die ook lekken kunnen bevatten, oftewel dweilen met de kraan open.

[Anoniem: 136725]

Dit geld voor alle OS'en

[Ramon]

Java en HTML5 zijn niet echt vergelijkbaar. Je zegt het zelf al; Java is een implementatie en HTML5 is een [soort van] standaard die door browserfabrikanten wordt geïmplementeerd. Beveiligingsproblemen komen ook zeker wel voor in browsers, maar aangezien browserfabrikanten al veel langer bezig zijn met veiligheid dan Oracle dat is, moet Oracle nu een inhaalslag doen.

[Artimunor]

Ik zou 'java' in browsers niet eens java willen noemen, wanneer gaan men eens onderscheid maken tussen die 2? Ik gebruik de programmeer taal java (o.a. voor android programmeren) maar ik ben niet gediend van de browser plugins die applets etc draaien, die ik na installatie allemaal weer uit mijn browser kan slopen.

De JDK geinstalled hebben staan of de JVM zonder browser plugin is al een stuk veiliger (ook al zitten zelfs daar ook lekken in)

[Amiga3000]

Was de gedachte van Java juist niet dat het niet uitmaakt waar het draait?
De lekken in Java zijn niet alleen browser gerelateerd, ze zijn alleen eenvoudiger toe te passen.

Al die jaren van gezeur over een virtual waarin Java code draait, bla bla bla.
Zodra je links hebt naar een onderliggende laag, disk, scherm etc.. zullen dit soort zaken altijd blijven en zijn ze taal onafhankelijk. Ja dus ook Java heeft hier last van.

Alleen is Oracle gewoon te laks geweest om serieus de problemen aan te pakken.

Java zou compatible moeten zijn, ik ken alleen maar problemen tussen alle versies.

[34749]

Was de gedachte van Java juist niet dat het niet uitmaakt waar het draait?
De lekken in Java zijn niet alleen browser gerelateerd, ze zijn alleen eenvoudiger toe te passen.

Nee die lekken zijn enkel in de browser toe te passen omdat het juist gaat om het toegang verkrijgen tot iemands OS via de browser. Zonder browser zijn die lekken niks waard.

Al die jaren van gezeur over een virtual waarin Java code draait, bla bla bla.
Zodra je links hebt naar een onderliggende laag, disk, scherm etc.. zullen dit soort zaken altijd blijven en zijn ze taal onafhankelijk. Ja dus ook Java heeft hier last van.

"een virtual" ? Je bedoelt waarschijnlijk de sandbox waarin Java code uitgevoerd. Net zoals in de Microsoft .Net implementatie of Google Chrome. En ja, met een sandbox ben je veiliger dan zonder sandbox. En nee, niemands sandbox is water dicht.

Alleen is Oracle gewoon te laks geweest om serieus de problemen aan te pakken.

Ik zie plenty of bugs opgeslost worden op https://bugs.openjdk.java.net/browse/JDK . Maak zelf ook welleens een patch.

Java zou compatible moeten zijn, ik ken alleen maar problemen tussen alle versies.

Ooit welleens bedacht dat je in iedere taal crappy software kan schrijven? Als je je gewoon aan de regels houd als programmeur werkt Java 1.4 code prima op een 1.7 JVM.

[Amiga3000]

Lees de lijst van fixes eens door Timezone security fix is bijvoorbeeld niet alleen in de browser van toepassing. Ja de meeste zijn Internet gebaseerd.

JVM is toch Java Virtual Machine !!!
Sandboxing is een techniek die ook wordt toegepast door chrome. En is dus eigenlijk anders dan een JVM. Lang voordat iedereen over sandboxing leuterde is de term JVM (virtual) gebruikt.

Lees de historie eens door over het dichten van lekken door Oracle dan kom je misschien op andere gedachten.

Echt onzin, veel van de patches zijn geen bugs omdat iets niet werkt. Nee het zijn fixes tegen misbruik daarom noemt men ze in het artikel kwetsbaarheden !!!
Dit zijn gewoon fouten die in Java zelf zitten en ja soms kan je daardoor niet meer werken met een oudere versie van de Java runtime. En ja Hello world werkt overal.
Doordat kwetsbaarheden soms de werking veranderen kan je niet anders, anders moet Oracle alle versie patchen en dat doen ze niet.

Voor servers is helaas veel van de onderhoud software in Java gemaakt, vreselijk traag en je moet de oude versie vol met problemen gebruiken.

[34749]

In de aankomende release (update 60) zit geen "Timezone security fix". Misschien zie ik hem over het hoofd, dus wijs hem even aan ajb: http://download.java.net/.../changes/jdk7u60-b02.html

Of heb je het serieus over deze exploit uit 2009? https://web.nvd.nist.gov/...tail?vulnId=CVE-2009-3884 (Die overigens zonder browser nul waarde heeft).

Snap overigens ook niet hoe tweakers aan de getallen zoals 36 kwetsbaarheden komt. Aangezien er geen bronvermelding bij staat is dat ook lastig te zien. Maar goed Java 7 is de enige Oracle Java in omloop (Oracle Java 6 is EOL en Java 8 is prerelease). Dus het moet wel Java 7 Update 60 zijn.

En is dus eigenlijk anders dan een JVM.

Nee, de JVM is een sandbox. Sandbox is een paraplu term net zoals VOIP en SIP een VOIP standaard is. En niemand heeft het over "Virtual". De VM (Virtual Machine) word wel gebruikt maar niemand heeft het over "de virtual".

Doordat kwetsbaarheden soms de werking veranderen kan je niet anders, anders moet Oracle alle versie patchen en dat doen ze niet.

Dat de werking soms wijzigt maakt helemaal niet uit. Zolang je je maar aan de standaard houd. De implementatie is altijd compatible met de standaard. Daarvoor is de JCP: https://www.jcp.org daar word de standaard vast gesteld. Hoe de implementatie werkt maakt niet uit. Je programmeerd tegen de standaard, niet de implementatie. En als je tegen de implementatie aan programmeerd ben je slecht bezig. En ja dat er mensen zijn die dat doen dat klopt. Dat dan je applicatie kan breken bij een update dat klopt. Maar dat werkt overal zo. Java, .Net, Python, Ruby, you name it.

Voor servers is helaas veel van de onderhoud software in Java gemaakt, vreselijk traag en je moet de oude versie vol met problemen gebruiken.

Lekker concreet; Je blijft maar terug vallen in onderbuik gevoelens en aannames. Ik heb een dozijn high performance applicaties geschreven in zowel C als Java. Wat je hier verklaart is echt onzin. Waarom denk je dat GMail op Java werkt? LinkedIn? NetFlix? Heb je enig idee hoeveel er wel niet op Java draait? Kijk hier is: https://wiki.apache.org/hadoop/PoweredBy

[Amiga3000]

Gewoon even beter lezen in de laatste update 45, dan zie je het vanzelf.

Sandbox, JVM allemaal mooie woorden. Het begon allemaal met JVM en later kwam de term sandbox (lekker spelen zonder zorgen).

Helaas is dat dus niet zo, soms zijn er wel degelijk wijzigingen die ervoor zorgen dat je programma gewijzigd moet worden. Heeft niets met een standaard te maken, wat Java overigens niet is.

Kijk maar eens naar Insight Manager van Compaq/HP was een prima product tot ze het in Java overdeden. Kan je zeggen hebben ze fout gedaan maar het feit dat ik een oude Java versie moet gebruiken in een oude browser zegt genoeg. Ze hadden het lekker C moeten laten toen was het snel en geen browser geneuzel.

Heb geen onderbuik gevoelens en doe geen aannames. Daar loop ik te lang voor mee, zijn gewoon keiharde feiten. Kan me nog een grote implementatie
voor de dag halen met Java. Dan heb ik het over een tijd geleden, de servers konden niet aangesleept worden vanwege de JVM ellende. Grote memory footprint, schaalde niet. Toen werd er besloten om de transacties op de oude code te laten lopen, windows C++, dat werkte prima en nu nog steeds (Java heeft dit nooit kunnen overnemen).

Heb niets tegen Java maar vindt de .Net oplossing beter en je bent niet afhankelijk van 1 taal. Maar als ik kijk naar hoe beide omgaan met geheugen en performance geef mij dan maar C of C++.

Code die snel moet zijn schrijf ik nog steeds in C of C++ en voor de UI C# (wat wel een ECMA standaard is)

Mijn grootste probleem is Oracle die heeft er gewoon te laat aandacht aangegeven, patches bleven achter etc.. En nee dat is geen aanname of onderbuik gevoel, dit is gebeurt.

Wil je veilig zijn neem dan een mainframe met Cobol, de taal die nog steeds veel wordt toegepast. Ben wel blij dat ik dat zelf niet meer hoef te doen, maar voor rekenen is Fortran nog steeds de beste.

[34749]

Gewoon even beter lezen in de laatste update 45, dan zie je het vanzelf.

Link graag en met uitleg hoe jij die exploit lokaal gaat gebruiken. Dus zonder browser. Jij bent ingelogd op een PC waar lokaal de JVM met die bug geinstalleerd is. Vertel maar hoe je door deze bug iets kan doen wat je normaal als user niet zou kunnen. Of remote op mijn part; Er draait een Java applicatie op de Oracle JVM 7u40 waarmee je connect. Vertel het maar. Ik ken deze bug en ik kan je alvast verklappen; Dat kan niet.

Kan je zeggen hebben ze fout gedaan maar het feit dat ik een oude Java versie moet gebruiken in een oude browser zegt genoeg.

Ja dat zegt inderdaad genoeg. Als ik een applicatie in .Net 2.5 schrijf die enkel in .Net 2.5 werkt ga je dan klagen bij Microsoft?

Heb geen onderbuik gevoelens en doe geen aannames. Daar loop ik te lang voor mee, zijn gewoon keiharde feiten.

0 links en 0 referenties in je posts niks concreet en al helemaal niks verifieerbaars. ZInnen als "een tijd geleden" en "Grote memory footprint, schaalde niet." zegt natuurlijk helemaal niks zonder context die voor mij na te trekken is. Het enige wat ik nu weet is dat jij onderdeel was van een half mislukte uitrol.

Heb niets tegen Java maar vindt de .Net oplossing beter en je bent niet afhankelijk van 1 taal.

Als je dat zo belangrijk vind; Op de JVM draaien ook meerdere talen. Scala, JRuby, etc. en je bent bij .Net afhankelijk van 1 platform; Windows en 1 leverancier: Microsoft. In tegenstelling tot Java waarbij je het kan draaien op Windows, Linux, Solaris, OS X, FreeBSD, etc. En nee, Mono stelt je niet in staat om zomaar iedere .Net applicatie ergens anders op te draaien.

Code die snel moet zijn schrijf ik nog steeds in C of C++ en voor de UI C# (wat wel een ECMA standaard is)

Ok laat maar zien. Post hier een stuk code met enkel ECMA C# dat een database connectie opent. Dat kan dus niet want enkel CORE C# is een ECMA standaard. Alle API's zijn Microsoft proprietary. Begrijp je wat dat inhoud? Enkel de low level taal is een standaard. Dat houd in dat enkel de if'jes en de else'jes en de classes gestandaardiseerd zijn. Je kan zelfs geen venster in Windows openen met enkel ECMA C# zonder Microsoft API's te gebruiken. Met andere woorden: Het is een wassen neus.

Heeft niets met een standaard te maken, wat Java overigens niet is.

Oracle heeft zijn eigen JVM implementatie, IBM heeft zijn eigen JVM, Apache heeft zijn eigen JVM, etc. Je kan de standaard hier downloaden: http://docs.oracle.com/javase/specs/ . Plus alle API's zijn standaarden via de JCP. Verwijs mij even naar de website van Microsoft voor .Net waar in samenspraak met de industrie aanpassingen aan .Net API's worden voorgelegd. Ik kan je verklappen; Die is er dus niet. Tevens mag je die API's in .Net beter niet zelf implementeren omdat de "niet aanklaag" belofte van Microsoft enkel geld voor ECMA C# en niet voor de API's.

Snap je wel dat .Net met C# eigenlijk gewoon Microsoft's take op Java is? Microsoft betaald Oracle zelfs voor patenten die ze in .Net gebruiken. Je zegt dat Java traag is maar C# is snel kennelijk? C# compiled ook naar een intermediary code net als Java naar bytecode gaat en beide worden daarna uitgevoerd in een VM...

Mijn grootste probleem is Oracle die heeft er gewoon te laat aandacht aangegeven, patches bleven achter etc.. En nee dat is geen aanname of onderbuik gevoel, dit is gebeurt.

Je kwantificeert helemaal niks, gebruikt weinig meetbare woorden als "te laat" en je zegt daarna "dit is gebeurt." en ik moet geloven dat het geen onderbuik gevoel is?

[Dreamvoid]

Oracle heeft zijn eigen JVM implementatie, IBM heeft zijn eigen JVM, Apache heeft zijn eigen JVM, etc

Da's natuurlijk niet helemaal waar, inmiddels werken ze allemaal samen in het OpenJDK project en maken hun eigen distributies op basis van die gezamenlijke codebase. Alleen Google maakt hun eigen Dalvik JVM.

Nogmaals Java is geen standaard PUNT.

Java is een gedetailleerd gedocumenteerde specifiatie, op basis waarvan iedereen een eigen implementatie kan maken. Na het doorlopen van een hoop tests kan zo'n implementatie gecertificeerd worden als Java compliant. In goed engels: een Specification (technical standard)

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 15:50]

[34749]

C is een standaard, de libs die gemaakt zijn niet. Misschien maakt dat het duidelijk voor je.

En dat is dus letterlijk wat ik zeg in mijn post... Enkel de if'fjes en de elsjes zijn een ECMA standaard bij C# de rest allemaal niet. Je kan nog geen venster in Windows tonen met enkel de C# ECMA standaard. Zelfs iets simpels de database API is Microsoft proprietary.

Java is niet de bron van deze manier van werken, pascal was hier ooit mee begonnen en ja zelfs de oude visual basic van micosoft werkte zo.

Pascal en de eerdere versies van Visual basic (voor .Net) compilen niet naar een intermediate code en draaien al helemaal niet in een VM?

Weet niet wat dit er mee te maken heeft maar ik denk dat M$ meer inkomsten heeft uit patenten dan andersom.

Ik heb het ook helemaal niet over inkomsten. Het gaat erom dat Microsoft moet betalen aan (destijds) Sun en nu Oracle omdat ze technieken moeten licenseren voor .Net omdat ze hetzelfde zijn als in Java.

Laat jij nou eens zien waar staat dat Java een standaard is, poging ooit mislukt !!! Heb je overal een linkje bij nodig?

Dat doe ik toch in mijn bovenstaande post? Hier staan alle Java standaarden: http:/www.jcp.org/ voor iedereen vrij om te implementeren gevrijwaard van patent recht zaken. Je kan zelfs een zetel krijgen om mee te stemmen over de standaarden. En dit is de VM standaard: http://docs.oracle.com/javase/specs/jvms/se7/jvms7.pdf . Op jcp.org staan zelfs de TCK's, applicaties waarmee je kan testen of je implementatie aan de standaard voldoet.

TimeZone.setDefault Change

Dit is het....serieus ?? Het is geen eens fix voor een beveiligings gat... Er staat ook letterlijk "change". Ik zal uitleggen wat het inhoud: Vanaf nu is het zo dat je in je een permisie moet aanvragen in de JVM als je in je eigen Java applicatie een tijdzone wil gebruiken die anders is dan die van de gebruiker zijn systeem. Die default tijdzone geld enkel in jouw applicatie. Dus je wijzigt niet de tijdzone van het systeem of andere applicaties. Enkel binnen jouw applicatie. Vertel me alsjeblieft hoe dit voorheen een beveiliginsgat was?

[Amiga3000]

Zielig..

p-code pascal, de link naar Microsoft is er niet meer dus kan ik je niet geven. Maar die hadden een gelijk concept ooit.

http://dl.acm.org/citation.cfm?id=806971

Geef eens een link naar die betalingen, is onderbuik gevoel van je met aannames.

Als ik een link naar Microsoft geef is het dan een standaard, raar hoor.

Waarom dan de fix, het kon zonder en nu moet het met !! en de fix is ook nog eens crappy met een omweg te omzeilen.

Jammer dat je oogkleppen op hebt en alleen maar Java ziet, je bent duidelijk een nieuwkomer met een beperkte opleiding.

[34749]

Geef eens een link naar die betalingen, is onderbuik gevoel van je met aannames.

Die patenten zijn onderdeel van de schikking van 2 miljard dollar die Microsoft destijds betaald heeft aan Sun (900 miljoen was voor patenten): http://www.theregister.co.uk/2004/04/02/sun_settles_with_ms/

Wellicht moet je dit ook is lezen:

http://jonathanischwartz....copy-great-artists-steal/ .

Jonathan Schwartz was CEO van Sun destijds.

So that interaction was good preparation for a later meeting with Bill Gates and Steve Ballmer.
-------
As we sat down in our Menlo Park conference room, Bill skipped the small talk, and went straight to the point, “Microsoft owns the office productivity market, and our patents read all over OpenOffice.”
-----
So when they created their web application platform, .NET, it was obvious their designers had been staring at Java – which was exactly my retort. “We’ve looked at .NET, and you’re trampling all over a huge number of Java patents. So what will you pay us for every copy of Windows?” Bill explained the software business was all about building variable revenue streams from a fixed engineering cost base, so royalties didn’t fit with their model… which is to say, it was a short meeting.

Of dit interview met James Gosling: https://web.archive.org/w...25,NAV47_STO69691,00.html

Ga jij nog wat dingen staven die je gezegd heb?

Waarom dan de fix, het kon zonder en nu moet het met !! en de fix is ook nog eens crappy met een omweg te omzeilen.

Het is ook geen "fix". Er staat toch duidelijk " method has been changed"? Wijs even het woord "fix" aan in onderstaand stuk:

TimeZone.setDefault Change

The java.util.TimeZone.setDefault(TimeZone) method has been changed to throw a SecurityException if the method is called by any code with which the security manager's checkPermission call denies PropertyPermission("user.timezone", "write"). The new system property jdk.util.TimeZone.allowSetDefault (a boolean) is provided so that the compatible behavior can be enabled. The property will be evaluated only once when the java.util.TimeZone class is loaded and initialized.

Zielig..

Jammer dat je oogkleppen op hebt en alleen maar Java ziet, je bent duidelijk een nieuwkomer met een beperkte opleiding.

Oogkleppen? Iemand die vraagt om concrete argumenten heeft oogkleppen? Daarna vind je het ook nodig om het op de man te spelen? Heel volwassen.

[Amiga3000]

Ja als ik evangelisten interview zijn ze altijd voor hun eigen parochie. Lijkt me niet zo vreemd. heb ik niets aan en is van geen waarde. De periode dat Sun dat geld heeft ontvangen was denk ik met name te danken aan de EU, M$ hadden net verloren en moesten overstag gaan. Volgens mij dat gezeur over windows media player enzo. Maar ja Sun heeft dat niet zoveel opgeleverd dezelfde week 3300 mensen ontslagen.

Ok wijzigingen voor beveiliging zijn voortaan changes.

Volgens mij heb ik je voldoende links gegeven en dat wil je niet lezen, jammer. Ja als iemand begint over onderbuik gevoelens dan heeft deze oogkleppen. Kan het zelf niet hard maken en moet zich dan daarop beroepen. Dat is de volwassenheid die je zelf toont dus dat moet ik je daar even op wijzen.

ook leuk om te lezen, is wel later
http://www.fosspatents.co...uld-have-invested-as.html

Later nog meer patenten maar dan google.
http://www.theregister.co...n_goofy_patent_contestas/

nog meer changes..
meuk: Oracle Java 7 update 51

http://www.oracle.com/tec...1972949.html#AppendixJAVA

Gelukkig alleen maar web

http://web.nvd.nist.gov/v...a&search_type=all&cves=on

[34749]

De periode dat Sun dat geld heeft ontvangen was denk ik met name te danken aan de EU, M$ hadden net verloren en moesten overstag gaan. Volgens mij dat gezeur over windows media player enzo.

De Sun rechtzaak kwam ten einde in 2001. De EU MS Media player etc. zoals jij hem noemt begon in 2004 en kwam rond 2007 ten einde... Met andere woorden toen MS settlde met Sun was de EU rechtzaak nog niet eens begonnen. Zoek maar op in de Wikipedia ofzo. Bizar, je creert gewoon je eigen werkelijkheid.

Ok wijzigingen voor beveiliging zijn voortaan changes.

Iedere change is dus in jouw ogen kennelijk een beveiligings gat? Bizar... Je bent duidelijk geen progammeur. Ik schat in dat je primair een systeembeheerder bent die welleens een applicatie geschreven heeft ofzo.

De links over de Sun patenten kan ik al helemaal niet plaatsen. Ja, Sun heeft bergen patenten aangevraagd op onder andere dingen als Java, dus? IBM heeft ook bergen patenten. IBM heeft zelfs patent op het communiceren met buitenaards leven. Sun heeft patent op het concept webshop. So what?

En ja, er zitten beveiligingsgaten in Java zoals in alle software. Als er een CVE voor is dan is het inderdaad vaak een beveiligingsgat. Maar voor jouw timezone parade paardje is geen CVE. Dat geeft wel aan dat je helemaal niet snapt hoe je zulk soort dingen moet interpreteren.

[Amiga3000]

Je moet wel goed lezen, maar ja dat is moeilijk voor een Java mens. Denk dat ik meer programmeer talen en programma code heb gemaakt dan jij kan bevatten.

Lees nou eens je eigen verhalen. ze werden pas veel later betaald. En dat ging niet alleen om patenten maar ook om de ANTITRUST. En die laatste zorgde voor veel onrust bij M$.

Under the 10-year pact with Microsoft, the software company will pay Sun $700 million to resolve antitrust issues and $900 million to resolve patent issues, the companies said. The companies will pay royalties to use each other's technology; Microsoft is paying $350 million now, with Sun to make payments when it incorporates technology later.

http://news.cnet.com/Sun-.../2100-1014_3-5183848.html

Leer nou eens lezen en niet alleen je eigen verhaal te verzinnen.

Het gaat erom dat Sun Patenten heeft getracht in geld om te laten zetten en dat deze als ronduit belachelijk werden gezien door het gerecht. Daar gaan deze links over.

Ik denk dat jij niet verder gekomen bent dan een HBO met alleen HTML en Java in je pakketje, heb je die bij InHolland behaald (verkregen) ?

[reinouts]

De JVM ondersteunt elke taal die compileert naar bytecode. Bekend voorbeeld is Scala, dat is dus al meer dan 1.

[terje7601]

Snap overigens ook niet hoe tweakers aan de getallen zoals 36 kwetsbaarheden komt. Aangezien er geen bronvermelding bij staat is dat ook lastig te zien. Maar goed Java 7 is de enige Oracle Java in omloop (Oracle Java 6 is EOL en Java 8 is prerelease). Dus het moet wel Java 7 Update 60 zijn.

Bron: http://www.oracle.com/tec...1972949.html#AppendixJAVA
Java 7 Update 60 is de volgende feature release & zal pas na deze security release komen.

[34749]

Tja dat is wel erg weinig om op te gaan. Maarja daarom heet het waarschijnlijk ook de "Executive Summary" . Alhoewel ik wel dacht dat ik op tweakers.net zat en niet op computable.nl

Java SE (Standard Edition) is de benaming voor een Java standaard. Oracle JRockit en de Oracle Java SE implementatie zijn 2 verschillende code bases. Met andere woorden hebben net zoveel te maken met elkaar als Firefox en Chrome. JRockit is de 'oude' Java implementatie van BEA wat ook overgenomen is door Oracle. Niemand heeft in feite wat te maken met JRockit (tenzij je BEA Websphere hebt draaien). Als daar de helft van de kwetsbaarheden in zit geeft dit artikel wel een enigsinds vertekend beeld.

[Webgnome]

Dat laatste is natuurlijk niet altijd te voorspellen. Als Sun Oracle besluit om in 1.7 bepaalde api's eruit te knikkeren dan werkt je 1.4 code dus echt niet meer..

[34749]

Als Sun Oracle besluit om in 1.7 bepaalde api's eruit te knikkeren dan werkt je 1.4 code dus echt niet meer..

Er zijn geen betaalde API's in standaard Java. Oracle kan daarnaast niet zomaar besluiten wat wel en niet een API word die in de volgende versie van de taal land. Dat word besloten in de JCP: https://jcp.org . De Java 7 EE specification staat bijvoorbeeld hier: https://jcp.org/en/jsr/detail?id=342 en zoals je ziet zitten daar ook partijen bij zoals IBM, Google, RedHat, etc.

[New]

Dat is wel de gedachte, maar dat wil niet zeggen dat een Applet ook meteen geschikt is voor een telefoon, PC of andersom.

Zonder meteen in de verdediging te schieten: de beveiligingslekken in Java zijn wel heel erg vaak applet of WebStart gerelateerd. Door deze technieken niet te gebruiken zit je redelijk veilig. Daarbuiten is het een vrij solide platform. Maar naarmate software complexer wordt, en mensen non-public APIs (of andere smerige trucs) gaan gebruiken willen er inderdaad wel eens compatibiliteitsproblemen e.d. ontstaan.

Eigenlijk dezelfde type problemen die je ook wel eens in .NET ziet. Maar ere wie ere toekomt, over het algemeen patcht Microsoft sneller en beter. Dus wat laksheid betreft zit je wel in de goede richting vind ik.

[Dreamvoid]

Eigenlijk dezelfde type problemen die je ook wel eens in .NET ziet.

Behalve dan dat er geen browser plugin is die de deur naar het .NET framework openzet voor ongeverifieerde remote code. Dat onzalige idee heeft Microsoft al een keer eerder gehad met ActiveX, en heeft dat wijselijk bij .NET achterwege gelaten.

[Thundy]

Nee hoor: http://msdn.microsoft.com...y/aa970060(v=vs.110).aspx

[B64]

Het schrijnende is nou juist, op m'n werklaptop staat Oracle ERP van een redelijk recente versie (volgens mij), die is Java-gebaseerd maar absoluut allergisch voor de laatste updates van Java. Noodgedwongen zitten we nog steeds op Java 6u34...

Je zou toch verwachten van een toko als Oracle dat ze ervoor zorgen dat al hun producten met elkaar kunnen samenwerken, zeker als één van die produkten zulke beveiligingsrisico's met zich meebrengt.

[delenn]

Met hoe het met de kwaliteit van heel veel oracle software gesteld is verbaast me dat helemaal niks. Vrijwel alle serversoftware op linux vereist X om te kunnen installeren bijvoorbeeld

[skiwi2]

Dat ligt aan de ontwikkelaar van het programma, overigens wel schrijnend dat de software in dat geval van Oracle is.

[EchoWhiskey]

Een van de redenen dat ik Java en al helemaal de browser runtime al lange tijd niet meer op mijn systemen heb geinstalleerd.
Oracle is extreem laks in het fixen en uitbrengen van patches.
Geen enkele (OS) software is veilig, maar de manier waarop Oracle er mee omgaat is ronduit slecht

[Dreamvoid]

Het hele idee van het beschikbaar stellen van een krachtige applicatie omgeving via de browser is veel te risicovol. Ongeverifieerde remote code uitvoeren in een complex en krachtige applicatie omgeving is gewoon vragen om problemen. We zagen dit met ActiveX ook al. HTML was door zijn simpelheid een relatief veilig platform (en desondanks zitten we al jaren met de ene javascript exploit na de andere), maar helaas gaat de industrie met alle nieuwe HTML5 extensies (directe hardware toegang voor video, cam/mic toegang, etc) exact dezelfde kant op.

Niks mis met Java als een krachtig (server-side) platform dat lokale code uitvoert, maar in de browser - hell no.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 15:50]

[Amiga3000]

Inderdaad hoe meer toegang tot de hardware en OS delen hoe meer ellende.
Ook alle pogingen tot sandboxing zijn uitstel tot de nieuwe ellende.
En ja niet alleen M$ heeft daar last van ook OS/X raad aan om Java uit te zetten.
gelukkig kunnen ze daar geen ActiveX draaien

[Amiga3000]

Inderdaad !

[lagefrequentie]

Dat was 1 maal -1 van jou.
Al komen er 4000 op die post, het blijft suf dat je de oude installers moet verwijderen via een omweg.
2 updates per week, kwaad willende die zoner problemen op 36 manieren naar binnen kunnen via 1 stukje software ...

[Oyxl]

Van mij? Denk het niet.

Maar inderdaad. Java Client runt script, niets meer niets minder. Zoals ik ver hierboven al eerder en veel uitgebreider beschrijf, is het niet handig om iets te hebben draaien op je systeem dat ongegeneerd alle soorten script uit voert die je het voedt. In de meeste omgevingen draait het ook volledig zonder beperkingen, omdat local en network policies worden aangepast om java executables als trusted te kenmerken.

De mogelijke gevolgen spreken voor zich.

[reinouts]

Lees: in de meeste windowsomgevingen. Zou het securitymodel er misschien ook mee te maken kunnen hebben?

[Dreamvoid]

Uh, ook in Linux omgevingen kan je Java executables als trusted instellen.

[Anoniem: 26306]

Ik weet niet precies wat jij onder Java client verstaat, maar ik neem aan dat je (in dit geval Oracle's) Java Runtime Environment bedoelt. Die runt helemaal geen scripts, die runt (naar bytecode) gecompileerde programma's. Eigenlijk is het heel erg vergelijkbaar met een .NET framework installatie.

Er wordt helemaal niet gerommeld met policies. Een programma draait normaal gesproken gewoon onder een user account zonder bijzondere rechten. Als je van mening bent dat dat anders is, mag je daar bronnen van geven.

[neokarasu]

Waarschijnlijk een stomme vraag, maar is er nog een reden om java überhaupt te blijven gebruiken?

Het lijkt me dat elk alternatief inmiddels als beter te bestempelen is, want de constante pleisters op de grote gaten die nog steeds in Java zitten geeft maar weinig reden tot vertrouwen.

[Amiga3000]

Ja als je het al gebruikt en daarna een manier vinden om er vanaf te komen.
Geef mij maar .Net

[Dreamvoid]

Da's niet echt optie als je een Linux backend hebt, en dat hebben heel, heel veel webbedrijven.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 15:50]

[Amiga3000]

http://en.wikipedia.org/w...hare_of_operating_systems

ook heel heel veel bedrijven wat anders. Linux kan ook zonder Java

[sys64738]

Omdat Java de meest gebruikte programmeertaal is voor webapplicaties en je er simpelweg dus niet meer om heen kunt. Maar applets en browser plugins is toch wel heel erg 2006 en moeten ze gewoon afschaffen. Java hoor op de server thuis... Hoewel Oracle het daar natuurlijk niet mee eens is met hun verwoede pogingen om FX niet een eenzame dood te laten sterven.

En wat zijn de alternatieven? Ruby? Daar komen ook heel vaak patches voor uit die de meest gruwelijke gaten fixen en altijd liever gister dan vandaag geïnstalleerd moeten worden. PHP? Nee dank je. .Net dan? Misschien. Maar alle platformen zijn vrij complex en het blijft gewoon moeilijk om alles netjes dicht te houden. Het is niet zo dat er bij Oracle een stelletje randdebielen aan Java sleutelen.. Daar lopen echt bijzonder slimme mensen rond dus daar ligt het niet aan.

@qws. Dat is een framework en geen taal/platform. draait op JavaScript. Leuk spul inderdaad maar nog vrij jong en ik verwacht dat uit dat framework nog heel veel fouten gehaald gaan worden. En JavaScript zelf is natuurlijk ook verre van heilig.

[Reactie gewijzigd door sys64738 op 23 juli 2024 15:50]

[OMX2000]

Ik weet niet hoe jij web applicaties definieert, maar als het gaat om applicatie die html/css/javascript/json/xml serven heb ik daar een hard hoofd in. Ik denk dat op het web PHP heel populair is, Ruby het heel goed doet, maar .NET het beter doet dan Java. Zie bijvoorbeeld : http://w3techs.com/technologies/details/pl-aspnet/all/all

Java is het wat mij betreft het effectiefst in de backend, waarbij de nadruk op business logica ligt. Java web applicaties voor enterprises bouwen kan goed, maar .NET is in mijn ervaring een hoop productiever. Maar ik denk dat die discussie tegenwoordig steeds minder relevant wordt doordat de architectuur van web applicaties is verandert van server side genereren van html/javascript, naar single web page + json requests is gegaan. Daar zijn platformen zoals node.js of Go een stuk sterker in. Alleen zou ik geen zware, reken intensieve logica in node.js schrijven.

Hier nog wat benchmarks van de verschillende platforms/talen. http://www.techempower.com/benchmarks/ Go is echt absurd snel als het aankomt op request/sec zonder verdere integratie met externe componenten.

[VelhaChica]

Ik heb er geen verstand van, maar ik krijg het idee dat Oracle 'het probleem' Java niet onder controle krijgt. Ook heb ik het idee dat de broncode van Java van noodpleisters aan elkaar hangt en de kwaliteit daardoor eigenlijk niet meer kan worden gegarandeerd.

[Dreamvoid]

Is het probleem Java, of het probleem de browser plugin?

Het is overigens niet alleen Oracle, er zitten tegenwoordig heel veel tech bedrijven in het OpenJDK consortium, oa IBM, HP en Apple.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 15:50]

[delenn]

De meeste leveranciers ondersteunen hun applicatie niet op OpenJDK, alleen op Oracle JDK

[Dreamvoid]

De Oracle JDK is een distributie van OpenJDK, de codebase is hetzelfde.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 15:50]

[Thundy]

ze hebben een grote gemeenschappelijke deler, maar zijn tot nu toe nog nooit volledig hetzelfde geweest qua codebase. Simpelweg omdat niet de hele codebase van Oracle JDK open-sourced is. Verder zijn er voor linux ook 'OpenJDK' distributies die veelal IcedTea based zijn voor de stukken waar Oracle closed-source code voor gebruikt en verschillen daarin dus voor stukken van de codebase wel degelijk van Oracle JDK.

Wat je schrijft is meer het ideaal/toekomstbeeld dan de huidige werkelijkheid.

[Reactie gewijzigd door Thundy op 23 juli 2024 15:50]