Oracle brengt Java 8 18 maart 2014 uit

Oracle heeft de releasedatum van Java 8 op 18 maart 2014 gezet, waar de oorspronkelijke verschijningsdatum op september van dit jaar stond. Het zat er al langer aan te komen dat Oracle tot uitstel ging besluiten, om tijd vrij te maken alle features in te bouwen.

Het officiële uitstel en de nieuwe releasedatum werden bekendgemaakt door Mark Reinhold, Chief Architect van de Java Platform Group bij Oracle. "Vorige week stelde ik voor de release van Java 8 uit te stellen om Project Lambda af te kunnen ronden, dat uitgesteld is dankzij Oracles hernieuwde focus op de beveiliging van het Java Platform", schrijft Reinhold, die daar aan toevoegt dat hij uit feedback opmaakt dat de meeste mensen, hoewel teleurgesteld, voor waren. Vorige week kon uit het voorstel al opgemaakt worden dat Oracle tot uitstel zou besluiten.

De deadline stond tot voor kort op september, maar er zijn al langer aanwijzingen dat de release vertraging op zou lopen. Begin dit jaar zou de zesde milestone-release van Java 8 al feature complete moeten zijn geweest, maar dat werd bij lange na niet gehaald. Grootste boosdoener is Project Lambda; veel gewenste features voor dit project duren langer om te implementeren dan gedacht.

JDK 8 moet nu op 23 mei feature complete zijn en in september moet de Developer Preview volgen, volgens het releaseschema dat Heise schetst. Eind januari zal de eerste Release Candidate verschijnen als alles goed gaat en vervolgens moet Java 8 op 18 maart verschijnen. De geplande release van Java 9 is doorgeschoven naar begin 2016.

Reacties (46)

Ik ben dan wel benieuwd wat "alle features inbouwen" inhoud.
Welke features bijvoorbeeld?

Ik heb wel de indruk dat java te log aan het worden is.
Misschien tijd voor een andere partij om een wat simpelere alternatief te lanceren.

Één van de nieuwe dingen in Java 8 is de introductie van compact profiles. Dit zijn kleinere versies van de JRE waarbij niet de volledige standaard libraries worden meegeleverd, maar een minimale subset daarvan. Er worden drie profiles geïntroduceerd (compact1 t/m compact3), waarbij ieder profile een aantal extra packages toevoegt aan de vorige profile. Het idee hierachter is om Java juist veel kleiner te maken zodat deze makkelijker kan draaien op resource constrained devices zoals de Raspberry Pi. Het doel van het compact1 profile was om de volledige JRE terug te brengen naar <10MB. Ter vergelijking, de OSX versie van JRE 1.7u21 is 141MB.

Deze compact profiles zijn een klein opstapje naar een volledig modulaire JRE in Java 9, waar de hele set aan standaard libraries wordt opgedeeld in kleinere modules. De modules die niet of nauwelijks gebruikt worden hoeven dan bijvoorbeeld niet geïnstalleerd te worden totdat ze nodig zijn. Er wordt dus behoorlijk wat tijd geïnvesteerd om er voor te zorgen dat Java niet bloated wordt, maar juist een heel stuk kleiner kan worden.

Op werk hebben we voor een aantal projecten Avian( http://oss.readytalk.com/avian/ ) gebruikt. Een JVM die +/- 800 KB is. Niet alles word nog ondersteund maar genoeg om bijvoorbeeld een GUI applicatie op basis van SWT te distribueren.

Alle frameworks worden log naar verloop van tijd. Maar de VM is altijd sneller geworden, niet trager. Deze release zal dat ongetwijfeld weer wat aan schaven. Op zich wel leuk dat mijn oudere programma's dus steeds sneller zijn gaan draaien (en dat is ook zeker te merken). Grootste issue van Java is natuurlijk het geheugengebruik. Maar ook de garbage collector is steeds beter geworden.

Wat ook een probleem is is dat de JRE nogal veel features bevat. Op zich is dat goed voor de software ontwikkelaar, maar het kan onhandig zijn als je gewoon een kleine web-app aan het maken bent (en gebruikers daarvoor de hele JRE up to date moeten brengen). Java 8 heeft als het goed is super packages om meer modulair te werken. Maar waarschijnlijk moet je dat meer als eerste stap zien. Verder is het natuurlijk altijd lastig om "tight coupling" tegen te gaan, elke serieuze ontwikkelaar zal dat be-amen. En de JRE is ooit als een monolithic systeem opgezet....

Bijvoorbeeld dit: "Blacklist certificate used with malware. "

Dit zijn volgens mij alle features in Java 8 SDK: http://download.java.net/...dk8/changes/jdk8-b87.html

[Reactie gewijzigd door Qws op 27 april 2013 19:23]

Het heeft naar mijn mening totaal geen zin om extra veel tijd in de 'beveiliging' van Java in de browser te steken. De Java sandbox (waarvan het doel is dat programma's met beperktere priviliges kunnen draaien dan een normaal userspace proces) is fundamenteel onveilig: je kunt weliswaar elk individuele lek afplakken, maar gezien de complexiteit van het systeem zal er altijd binnen de kortste keren iemand een manier vinden uit de zandbak te ontsnappen.

Java is echter prima te gebruiken als je je gewoon bedenkt dat een malafide Java-applicatie potentieel dezelfde schade aan kan richten als elk andere programma en je daarom je browser niet toestaat zonder toestemming applets uit te voeren (of Java in de browser gewoon uit zet, want je hebt het waarschijnlijk toch niet nodig).

Oracle moet gewoon toegeven dat het hele sandboxmechanisme binnen Java faalt en niet te repareren is. Ze kunnen er net zo goed mee stoppen.

Je kan complexiteit tegengaan door dingen in lagen in te delen, en die lagen zo veilig mogelijk te maken. Het idee dat sandboxing niet werkt is natuurlijk onzin, het wordt ondertussen juist steeds meer toegepast. IE bevat sandboxing, Android werkt met sandboxing etc.

Alle software, en unmanaged software helemaal, heeft het probleem dat de veiligheid afneemt als het aan te vallen oppervlak (attack surface) groter wordt. De truk is dus om dat opervlak zo klein mogelijk te houden en zo goed mogelijk te beveiligen. Sandboxing kan daar prima een rol in spelen, als onderdeel van een totaal beveiligings plaatje.

Feit is wel dat Java hier niet de beste taal voor is. Het is wel managed en bevat dus geheugen beveiliging. Maar objecten kunnen zelf nog wel redelijk makkelijk aangepast worden als de interface dat toe laat (of als er native code uitgevoerd kan worden). Daar in valt nog veel te verbeteren.

Helaas ben ik nog geen talen tegengekomen die dit beter doen - en ik heb er heel wat geprobeerd. De meeste talen richten zich op gemak en maximum aan functionaliteit. Meer security gerichte talen (of eigenlijk omgevingen) zou zeer wenselijk zijn.

Sandboxing is ook niet altijd de heilige graal
Een enkele kwetsbaarheid is niet meer voldoende voor full code execution als er een sandbox aanwezig, om de sandbox te breken is minimaal een tweede kwetsbaarheid in de sandbox zelf nodig. Dit maakt het iets moeilijker om shellcode uit te voeren, maar het is niet onmogelijk. Immers zijn al verschillende keren zde sandboxes van IE9/10, Google Chrome en Adobe Reader X/XI gebroken.

Zelfs Google's meesterwerk waar het gaat om beveiliging: Chrome-OS is al een keer gevallen.

Sowieso is het grootste probleem bij Java ook niet memory corruption, maar een erg klein deel van de kwetsbaarheden die de laatste jaren in Java gevonden berust op het principe van geheugen corrupten.

Het probleem zit hem vooral in de JVM (Java Virtual Machine), dus in het gedeelte waarin de applets worden verwerkt. Meestal kan dan bij een succesvolle exploit met de Security Manager worden geknoeid, waarna een executable kan worden gedropt op het systeem van het slachtoffer.

Sowieso zal het -naar mijn mening- nog lang duren voordat er echt veilige talen zijn. En als ze er zijn dan heb je ook weer het probleem dat niet zomaar 100k regels code C++ kan worden herschreven, dat vergt immers een te grote investering voor de meeste bedrijven.

Daarentegen heb je ook nog een stukje compatibiliteit en de afhankelijkheid van third-party software om een programma in de nieuwe veilige programmeertaal X te laten draaien. Waar iedere Windows client wel een applicatie geschreven in Visual C++ kan draaien ofzo, zullen er waarschijnlijk weer additionele drivers nodig zijn voor een nieuwe programmeertaal.

Je zult altijd kwetsbaarheden hebben. Of Java nu volledig wordt omgebouwd en een drastisch andere weg inslaat of dat EMET standaard in Windows wordt ingebouwd. Code kloppen blijft nu eenmaal mensenwerk en daarbij wordt weleens een foutje gemaakt, maar wat verwacht men dan ook van projecten met honderdduizenden regels code?

Het is wel managed en bevat dus geheugen beveiliging.

De Java Virtual Machine is in feite een sandbox. Als je wilt kan je door middel van de Security Manager ( http://www.oracle.com/tec...eccodeguide-139067.html#9 ) 1001 rechten ontnemen van de applicatie die draait in de JVM.

Aanroepen van native code in Java is zeker geen normale zaak. 99.99% van de applicaties geschreven in Java doet dit simpel weg niet (in tegenstelling tot .Net waar het aanroepen van native code meer geaccepteerd is). Je kan de JVM ook makkelijk zo instellen dat geen native code aangeroepen mag worden.

Maar objecten kunnen zelf nog wel redelijk makkelijk aangepast worden als de interface dat toe laat (of als er native code uitgevoerd kan worden)

Ik snap niet helemaal wat je bedoelt? In iedere taal kan je nieuwe types maken welke aan een interface voldoet. Dat is het hele punt van een interface.

99.99 procent van de applicaties lijkt me wat veel. Alles wat onder Eclipse draait heeft er al een native component bij (SWK). Verder is het wel een attack vector, zelfs als de applicatie er zelf in eerste instantie geen gebruik van maakt.

Over het tweede dee: het punt is dat Java veel met objecten die "mutable" zijn werkt. Als je die aan een interface methode mee geeft dan kunnen deze aangepast worden, of ze kunnen gebruikt worden als tussenstation naar een ander "mutable" object. Dat betekend in de praktijk dat je alleen van basis-typen en simpele, immutable objecten uit moet gaan als je een interface maakt die bestand is tegen aanvallen. Een andere optie is het serialiseren van objecten, maar dat is niet altijd even praktisch en heeft zijn eigen problemen.

In C++ kan je bijvoorbeeld een argument als const markeren. Zo'n constructie zou in een managed taal nog handiger zijn omdat je een object niet stiekum terug zou kunnen casten naar iets wat wel mutable is (zoals in C++ wel kan). Maar dit wordt zo wel een erg diepe discussie

Eclipse is een client side IDE. In server side applicaties komt native code niet voor. Ik heb nog nooit een Java EE applicatie gedployed bij een bedrijf gezien welke native code gebruikte. Je zou ook wel een erg goede reden moeten hebben om dat te doen.

Daarnaast draait Eclipse op OSGi welke een nog veel uitgebreider security model heeft dan standaard Java waarbij je ook weer kan specificeren welke bundles (plugins) wel of geen gebruik mogen maken van native code. Dat maakt het dan weer een stuk moeilijker om SWT uberhaupt te exploiten. Overigens als je echt zou willen kan je weer met zoiets als SELinux zorgen dat de JVM enkel bepaalde native code kan uitvoeren.

In C++ kan je bijvoorbeeld een argument als const markeren. Zo'n constructie zou in een managed taal nog handiger zijn omdat je een object niet stiekum terug zou kunnen casten naar iets wat wel mutable is (zoals in C++ wel kan).

In Java kan je zaken final maken waar door ze immutable zijn. In C++11 hebben ze final zelfs toegevoegd aan C. De volgende code levert in Java een onwijzigbaar object op (ie. immutable):

public final class foo {
private final int bar;

public foo(int bar) {
this.bar = bar;
}

public int getBar() {
return bar;
}
}

Ik zie eerlijk gezegd het probleem niet?

[Reactie gewijzigd door 34749 op 28 april 2013 02:32]

De sandboxing is niet beperkt tot applets.
Zet je de security manager aan, dan kun je expliciet aangeven wat wel en niet mag. Zo zal voor webapplicaties veelal de aanroep van System.exit() zijn geblokkeerd. Je kunt instellen welke resources wel of niet geladen mogen worden, waar wel of niet naartoe verbonden mag worden. Voor de meeste desktop applicaties niet nodig. Maar voor b.v. banksystemen wel. Daar wil je wel meer controle hebben.

Oracle moet gewoon toegeven dat het hele sandboxmechanisme binnen Java faalt en niet te repareren is. Ze kunnen er net zo goed mee stoppen.

Hoe had je dat in gedachten? Ondanks het feit dat de gemiddelde tweaker zelden meer met Java applets te maken heeft zijn er ongetwijfeld nog vele miljoenen van in de omloop. Als je dat sandboxmechanisme (dwz de security manager) eruit sloopt werken die dus niet meer.

Het zou mooi zijn als daarmee die applets zouden verdwijnen en er andere oplossingen voor bedacht zouden worden maar de praktijk zal er wel op neer komen dat er links en rechts verouderde Java versies geinstalleerd blijven, een soort van IE6 scenario maar dan zonder de patches. Sun/Oracle zijn nu eenmaal zo'n 15 jaar geleden dit pad ingeslagen en dat kan je niet zomaar even terugdraaien.

Tsja, dan kan iedereen er wel mee stoppen. Browsers zijn net zo hard fundamenteel onveilig (de ene JS exploit na de andere), rootkits op Linux, lekken in Apache, exploits in de OSX core libraries, iOS jailbreaks, en over Windows zullen we het maar niet hebben. Alle sandboxing technieken die er de afgelopen twintig jaar bedacht zijn, zijn op 1 of andere manier omzeild.

Het ironische is dat het enige nog niet (publiek bekend gemaakt) gekraakte mainstream OS, het oude Blackberry OS, volledig Java based was

[Reactie gewijzigd door Dreamvoid op 27 april 2013 21:17]

En wat zijn nu precies (of ongeveer) de nieuwe features in Java 8, of is dat nog niet bekend?

http://www.techempower.co.../everything-about-java-8/

Wow, dat ziet er wel heel goed uit. Lambdas en Streams. Lijkt erop dat ze weer een beetje op C# proberen in te lopen. Streams zijn dan een soort LINQ. En ik moet zeggen dat ik dat idd erg mis in mijn java werk.

Ben wel benieuwd of Android ook Java8 gaat supporten. Ben bang van niet.

Op de volgende pagina kan je de geplande features zien. http://openjdk.java.net/projects/jdk8/milestones
Doordat de deadline opschuift zouden er features kunnen worden te gevoegd die nu gepland staan voor JDK 9.

Ik hoef die updates niet zo nodig. De web interface van onze HP managed switches werkt bijvoorbeeld niet meer, de console sessie van onze KVM switch ook niet. Ik heb expres op een aparte server de ouwe versie in stand gehouden zodat ik er iig nog ergens bij kan.

[Reactie gewijzigd door tiguan op 27 april 2013 16:52]

Dat blijft inderdaad een probleem met de applets.

Gewone java programma's leveren tegenwoordig meer en meer hun eigen, geteste, versie mee om die problemen te vermijden.

Het verbaast me eigenlijk dat er nog niemand iets gevonden heeft om meerdere java versies in dezelfde browser te gebruiken.

Het verbaast me eigenlijk dat er nog niemand iets gevonden heeft om meerdere java versies in dezelfde browser te gebruiken.

Euh, dat kan toch al gewoon? Oracle beschrijft ook hoe dat moet op hun eigen site: http://docs.oracle.com/ja...eloper_guide/version.html

Alleen tijdens sessies kan je maar één versie tegelijk gebruiken, wil je een andere versie gebruiken zal je een nieuwe browser-sessie moeten starten. Dat is by design. Maar meerdere java-versies in dezelfde browser kan dus al gewoon (iig in IE en Firefox, van Chrome en Safari weet ik het niet).

[Reactie gewijzigd door wildhagen op 27 april 2013 17:03]

Dat heeft niks te maken met applets. Dat heeft te maken met programmeurs die niet kunnen programmeren (daar hebben ze vooral bij Cisco en HP een handje van). Iedere Java release is 100% backwards compatible met voorgaande releases. Tot en met versie 1.0 aan toe. Als je als programmeur echter rare dingen gaat doen zoals classes uit de "com.sun" packages gebruiken...tja dat is vragen om problemen. De compiler geeft ook warnings als je dat doet.

De enige fout van de Java compiler is dat het warnings zijn en geen fatal errors...

Switches beheer je via de CLI

Je kan al, bij wijze van preview of om alvast te testen, al wel de Early Access downloaden op dit moment, build 87 (25 april 2013) is de laatste: https://jdk8.java.net/download.html

Zowel de JRE als JDK zijn daar te downloaden.

Maar daar zit helaas niet alles in.
De hele stream api zit alleen nog in de Lambda repository.
Dus je mist nog een groot deel. Vandaar ook de uitstel.

Here you go: https://jdk8.java.net/lambda/

Daar heb je wel Lambda Maar geen JavaFX
Dus er is nog niet 1 release dat *alles* van de toekomstige Java 8 heeft.

Wat versta je onder log? Een taal wordt niet trager als je nieuwe classes toevoegt. Je breidt het uit en als je het niet importeert zit het niet in de bytecode.

Grootste irritatie bij ons binnen het bedrijf is de strenge auto update en security checks die ze ergens in 7_xx ingebouwd hebben. In een bedrijfsomgeving wil je niet dat gebruikers zelf java gaan updaten.

Het is erg lastig dit in een bedrijfsomgeving bij deployment standaard uit te zetten. Verschillen in java versies, browsers, platformen en soorten meldingen maken het er niet gemakkelijker op.

Het zou mooi zijn als ze daar wat op bedachten in aankomende versies.

om tijd vrij te maken alle features in te bouwen

Maak dan meer tijd vrij om Java wat veiliger te maken.

Tis meer een kwestie om te beveiligen dan een nieuwe release.
Makkelijker om het niet te doen dan wel.
Programmeurs moeten het implementeren. Maar het is makkelijker om niet te doen dan wel.
Dat is waar ik tegenaan loop in de praktijk iig.

Quote: "Vorige week stelde ik voor de release van Java 8 uit te stellen om Project Lambda af te kunnen ronden, dat uitgesteld is dankzij Oracles hernieuwde focus op de beveiliging van het Java Platform"

dat is dus kennelijk ook de rede van uitstel.

*reden, een rede heeft een andere betekenis.

Misschien wel, maar is het niet net als bij windows? moeten ze niet gewoon van voor af aan beginnen?

[disclaimer: boto gebruikt al sinds het begin der tijden windows ]

Opnieuw beginnen betekent heel, heel veel nieuwe bugs.

moeten ze niet gewoon van voor af aan beginnen?

Opnieuw beginnen? Je bedoelt zoals bij Windows met de NT kernel? Dat kan je niet vergelijken. De JVM heeft geen design flaws ter grote van MS-DOS, enkel bugs in de implementatie. De de MS-DOS lijn (inclusief Windows 9x, ME) was op papier al totaal brak in de technische zin (programma's die gewoon bijelkaars memory space kunnen komen om maar een voorbeeld te noemen). Ongeacht hoe perfect de implementatie zou zijn zou het nooit beter kunnen worden dan het brakke ontwerp. Ik zeg er duidelijk bij in de technische zin want commercieel was het natuurlijk een top product. Technisch gezien was het echter totaal brak.

Technisch gezien was MS-DOS een fantastisch real-time 16-bit OS. Het was alleen niet zo handig om te verwachten dat dat bruikbaar zou zijn als basis voor een 32-bit multitasking desktop en server OS.

En dan zeker elke week daarna weer een of andere update en beveiligings problemen

Ik mag het wel hopen. Software van die grootte die geen wekelijkse update heeft is niet veilig maar minder veilig. Vervelend maar waar.

Je kan je wel afvragen of de huidige methode om te updaten handig is; meteen de hele JDK updaten is wat veel; groot kans dat ik bijvoorbeeld nooit de CORBA bibliotheek nodig heb. Een meer component gebaseerde methode zou handig zijn, en daar wordt dan ook (wat te voorzichtig) naar toe gewerkt met e.g. super packages.

Als je verwacht dat er geen wekelijkse update nodig zou moeten zijn dan heb je een beter framework nodig. Helaas wordt er bij frameworks, ook door serieuze developers, amper naar security gekeken. Dat Java nog steeds een van de veiligere frameworks is kan hiervoor als voorbeeld gezien worden.

ligt er aan, Java brent een update uit waarmee ze weer een lek erbij hebben.. waardoor ze dat lek weer moeten gaan updaten.... leuk en aardig maar wel verdomd irritant... als je iets doet, doe het dan goed.

Stel dat Windows regelmatig met updates zou komen. Schandalig...

Wie wil er serieus zijn vingers nog branden aan Java?
Zelf (moet) ik het gebruiken voor zaken als PS3/Ultimate Media Server. Maar liever gebruik ik het helemaal niet meer. In de browser staat het dus mooi uit, want wat maakt er op internet nog gebruik van? En wat er nog gebruik van maakt is in mijn ogen niet meer van deze tijd.
Ik hoor mensen klagen over dat er veel en vaak security updates zijn voor dit misbaksel. En dan wordt er weer geklaagd op de klagers dat dat toch goed is dat er updates komen voor gaten. Maar als een fietsband zo lek is dat je wel kunt blijven plakken. Oftewel meer een gatenkaas is, dan iets geheels, dan ga je toch eens nadenken over iets heel nieuws?
Daar komt nog bij dat niet alleen de problemen met Java, mensen het geduld hebben kwijtgeraakt. Het is vooral de manier waarop Oracle daarmee is omgegaan, met die problemen en de erkenning daarvan. Dat zorgt eigenlijk voor het failliet van Java.
Ik probeer het in ieder geval zo weinig mogelijk te gebruiken. Het enige handige eraan is dat het cross-platform software mogelijk maakt, maar dat is dan ook alles.

Java wordt wel voor meer dingen gebruikt dan voor applets in je browser. Ik denk dat Oracle die browser plug-in net zo lief kwijt is, de belangrijkste markt voor Java zit aan de serverzijde en daar voldoet het uitstekend, ook op het gebied van beveiliging.