Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Software-update: Oracle Java 8 update 121 / 122

Door , 25 reacties, submitter: sambalbaj, bron: Oracle

Java Oracle heeft updates voor versies 6, 7 en 8 van zowel de developmentkit als de runtime-environment van Java Standard Edition uitgebracht. Naast de versie voor gewone computers is de update ook verkrijgbaar voor embedded systemen. De release notes voor deze uitgave zien er als volgt uit:

Java SE 8 Update 121 and More
Java SE 8u121 (Java SE 8 update 121) is now available. Oracle strongly recommends that most Java SE users upgrade to the latest Java 8 update, which includes important security fixes. For information on new features and bug fixes included in this release, please read the following release notes.

Important Note: Starting with the April Critical Patch Update releases, planned for April 18th 2017, all JRE versions will treat JARs signed with MD5 as unsigned. Learn more and view testing instructions here. For more information on cryptographic algorithm support, please check the JRE and JDK Crypto Roadmap.

Oracle Java SE Embedded Version 8 Update 121 is also available. You can create customized JREs using the JRECreate tool. To get started, download an eJDK bundle suitable for your target platform and follow instructions to create a JRE that suits your application's needs. Also released are Java SE 7u131 and Java SE 6u141, which are both available as part of Oracle Java SE Support. For more information about those releases, please read the following release notes: 

Versienummer 8 update 121 / 122
Releasestatus Final
Besturingssystemen Windows 7, Java, Linux, Windows Vista, Windows Server 2008, Windows Server 2012, Windows 8, Windows 10
Website Oracle
Download https://www.java.com/en/download/win10.jsp
Licentietype Freeware

Reacties (25)

Wijzig sortering
Om de steeds weer terugkerende commentaren van Java-bashers voor te zijn:

Java SE is *niet* hetzelfde als de (onveilige) browser plugin, en ook niet hetzelfde als de JRE waarmee je desktop applicaties kunt draaien.
Java SE is de Java "core" die wordt uitgebracht als een JRE (voor het uitvoeren) en een JDK (om mee te ontwikkelen). Dus ja, zowel de JRE als de JDK zijn Java SE.
"Java Platform, Standard Edition (Java SE) lets you develop and deploy Java applications on desktops and servers, "
Bron

Edit: typo

[Reactie gewijzigd door NLSurfMan op 18 januari 2017 15:57]

Maar hij heeft het over de browser plugin. Wat heeft dit daar nou mee te maken? :?

[Reactie gewijzigd door NotCYF op 18 januari 2017 16:00]

Java SE is *niet* hetzelfde als de (onveilige) browser plugin, en ook niet hetzelfde als de JRE waarmee je desktop applicaties kunt draaien.
Met name over het gedeelte achter de komma.
Oh dat had ik over het hoofd gezien 8)7 :X
Het ging mij meer om opmerkingen als "Wie draait nu nog Java, terwijl iedereen weet dat het zo lek als een mandje is", die hier altijd verschijnen als er een nieuwe versie van Java SE (of EE) uitkomt. En inderdaad, JRE is onderdeel van SE.
Met die browser plugin is niets mis, de problemen zaten altijd in het Java sandbox/security model. Gewoon onderdeel van Java SE.
De browser plugin was de middel waarmee rogue java applicaties gemakkelijk uitgevoerd werden. Dit is toch precies hetzelfde wanneer je op een .Exe drukt? Ga jij nu zeggen dat Windows ook onveilig is als er een browser plugin voor .exe win32 applicaties beschikbaar is waarmee virussen gemakkelijk worden uitgevoerd?

Java is net als Windows zo veilig als jij zelf bent.

[Reactie gewijzigd door NotCYF op 18 januari 2017 16:11]

Je mist duidelijk de kennis van het Java security model dat er voor hoort te zorgen dat een rogue Java applicatie net zoveel kan als een willekeurige Javascript applicatie. Een dergelijk mechanisme bestaat niet voor exe files. De browser plugin was er alleen maar verantwoordelijk voor om de applets met de juiste security context in de VM te launchen, en dat deed (en doet) die plugin ook naar behoren. De exploits (!) waren allemaal mogelijk doordat er gaten in het betreffende security model zaten, niet omdat een applet per definitie gevaarlijk is. Sla het Wikipedia artikel er maar op na.
Daar doelde ik dan ook op: Automatisch openen van applets/applicaties is totaal niet veilig; Zonder de browserplugin kan dit niet(Java Web-start althans is zo veilig als wanneer jij op een .jar drukt)
Onjuist. Applets starten vanuit de browser is perfect veilig. Daar zit het security model tussen. Als je er in slaagt een applet te maken die hetzelfde kan als een applicatie is dat een (0 day) exploit. Kan je rijk mee worden.
Nou ja, niets mis.. Los van alle security issues is het ook een draak van een systeem. De meeste browser-plugins trouwens. Java Apples in een website zien 'foreign' uit aangezien ze altijd de Java widgets gebruiken ipv de desktop native widgets, ze starten traag, bombarderen je met een lading aan waarschuwingen, en tegenwoordig biedt HTML5 nagenoeg alles wat je in een applet zou willen stoppen.

Dus er is zeker wel wat mis met de browser plugin: hij heeft gewoon weinig bestaansrecht.
Ja ok, ging me er meer om te benoemen waar de veiligheidsproblemen bij applets hun oorsprong hebben. Verder vooral bezwaren van plugins in zijn algemeenheid en achterhaald door de tijd. Eind jaren 90 leek het best een aardig idee, maar dat heeft dus duidelijk anders uitgepakt. Maar goed, het is maar een van de vele toepassingen van Java.
Absoluut, als Java weg zou vallen zou ik heel wat programmatuur op mijn werk moeten herschrijven :o

Al moet ik zeggen dat ook voor server-toepassingen ik er niet heel erg van gecharmeerd ben; de grootste reden dat we het gebruiken is de beschikbaarheid van veel voor ons relevante software en libraries.
Zonder verder commentaar te geven over hoe veilig de Java Plug-in is, heb je zeker wel een goed punt dat kleine Java applets vaak net zo goed als HTML5 geimplementeerd kunnen worden. Dat gaat echter niet op voor grotere / enterprise Java applets dewelke niet zomaar kunnen omgezet, maar die weldegelijk client side Java vereisen. Het migratie pad daarvoor is om te schakelen naar Java Web Start.

Daarbij komt nog dat web browsers zelf de Java plug-in niet meer (gaan) ondersteunen. De combinatie van deze factoren maakt dan ook dat Oracle besloten heeft om de Java Plug-in als deprecated te markeren vanaf Java 9 (ref. JEP 289).

Reference(s):Disclaimer: * Ravefiend werkt voor Oracle dus bovenstaande is mijn eigen mening. ;)

[Reactie gewijzigd door Ravefiend op 18 januari 2017 14:28]

Applets die niet met HTML5 ge´mplementeerd kunnen worden, zouden geen applet moeten zijn. Je noemt als Java Web Start, dat is inderdaad een goed alternatief om een volledige Java-applicatie te starten middels een link op een website. Hierbij is een website voornamelijk een distributieplatform en niet zo zeer een website met daarin een applet.

Alsnog is het al te eenvoudig starten van applicaties (bijvoorbeeld via Java Web Start) een veiligheidsrisico - deze applicaties genieten niet de sandboxing / bescherming die een HTML5-applicatie wel heeft. Voor enterprise-systemen is dat prima te managen, maar het zou wat mij betreft wel de voorkeur hebben om bij installatie van Java op een consumenten-PC standaard geen Java Web Start te installeren. Gelukkig blijkt in de praktijk dat heel veel consumenten tegenwoordig gewoon geen Java meer op hun PC hebben, waardoor een aanval via Java Web Start een vrij beperkt publiek zal hebben.
De JRE kan prima server(side) applicaties draaien. De JRE bevat alleen geen compiler toolset.
Vandaar de naam Java Runtime Environment.
Java SE is *niet* hetzelfde als de (onveilige) browser plugin, en ook niet hetzelfde als de JRE waarmee je desktop applicaties kunt draaien.
Behalve dan wanneer je Java SE download, je eigenlijk de JRE of JDK download...
Waarbij de JRE veelal weer de gehate browser plugin bevat.

Java SE is in die zin te omschrijven als 'Java for Workstations', Java ME als 'Embedded Java' (voor telefoons / set-top boxen) en Java EE als 'Java for Servers' (zelfde als Java SE, maar met meer support voor server environments).
In zou Java SE dus in die zin wel gelijk stellen aan de JRE, alleen bepaalt ME, SE of EE welke variant van de JRE.
Argument is ook om te draaien, als de Java community / Oracle echt iets aan het bashen van het hele 'merk' wilt doen, kunnen ze misschien ook beter het onderdeel dat ze de slechte naam geeft aanpakken. ;)

(En met jouw fipo start je nu juist het onderwerp muhaha)
Inderdaad, zoals hieronder te zien is. |:(
Die nummering is maar verwarrend. Ze kunnen beter een conservatieve Java 8.0 branch aanhouden en een wat minder conservatieve Java 8.1 branch.
Je maakt het ook niet echt duidelijker. De JRE bevat namelijk wel de browser plugin. En... de JRE runt (of draait) java SE programmatuur. De JRE kan overigens alle java programmatuur draaien. Als de benodigde libraries maar aanwezig zijn.
Het nadeel van html5/javascript t.o.v. java applets is soms wel dat (ook al zou je het omgekeerde verwachten) bij html5 het geheugengebruik behoorlijk kan oplopen. Helaas hebben niet alle gebruikers een dikke pc of laptop met 8..32GB Ram. Neemt niet weg dat de security problemen bij applets zwaar wegen.
Anders is er nog JavaRa,hier kun je mee kijken of je nog de nieuwste versie hebt.

Op dit item kan niet meer gereageerd worden.


Nintendo Switch Google Pixel XL 2 LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*