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

Door , , 31 reacties
Bron: Oracle, submitter: sanderv

Java Oracle heeft versie 8.0 van zowel de developmentkit als de runtime-environment van Java Standard Edition uitgebracht. Nieuw in versie 8 is onder meer dat ontwikkelaars van lambda expressies gebruik kunnen maken, wat hun werk efficiënter en eenvoudiger moet maken. Meer informatie is op onze voorpagina te vinden, dit zijn de release notes:

Java SE 8 Features
  • Lambda Expressions (JSR 335) - a new language feature introduced in Java SE 8. Lambdas enable you to treat functions as method arguments or code as data.
  • Nashorn - a lightweight high-performance JavaScript runtime in 100% pure Java, native on the JVM, that enables Java developers to embed JavaScript in Java applications.
  • Compact Profiles - predefined subsets of the Java SE platform that enable applications that do not require the entire Platform to be deployed and run on small devices.
  • Stream API - Classes in the new java.util.stream package provide a Stream API to support functional-style (e.g. Filter/Map/Reduce) operations on streams of elements. The Stream API is integrated into the Collections API, which enables bulk operations on collections, such as sequential or parallel map-reduce transformations.
  • Date & Time API (JSR 310) - a new set of packages that provide a comprehensive date-time model.
  • Type Annotations (JSR 308) - provides the ability to apply an annotation anywhere a type is used, not just on a declaration. Used with a pluggable type system, this feature enables improved type checking of your code.
  • Java Mission Control 5.3 –usability improvements to allow Java administrators and developers to more easily gather detailed low level information about how the Java Virtual Machine (JVM) and the Java application are behaving; support for Java SE Embedded 8 (Full JRE Profile)
  • JavaFX – features and enhancements include an embedded specific graphics stack, new UI controls, a Modena theme, functionality to enable developers to embed Swing content into JavaFX applications, new 3D graphics features, and additional HTML 5 support.
  • Security Features and Enhancements
  • … and much more.

Oracle Java screenshot

Versienummer:8
Releasestatus:Final
Besturingssystemen:Windows 7, Java, Windows XP, Solaris, Windows Server 2003, Windows Vista, Windows Server 2008, Windows Server 2012, Windows 8
Website:Oracle
Download:http://www.oracle.com/technetwork/java/javase/downloads/index.html
Bestandsgroottes:1,53MB t/m 207,72MB
Licentietype:Freeware
Moderatie-faq Wijzig weergave

Reacties (31)

Ach wat is Java toch altijd maar slecht, bij elke update kunnen we het weer lezen.

JAVA staat al ruim 10 jaar in de top 3 van meest gebruikte programmeertalen ter wereld, daar zijn vast goede redenen voor.
Vergeet niet hoe meer programmeurs in een taal programmeren, hoe meer rotte appels er tussen zitten en hoe meer gekloot bij versie updates.

@justme256
Als de applicaties echt met elke Java security update omvallen, dan moet je eens goed met de programmeurs gaan praten, tenzij ze zeer goede redenen hebben om versie specifieke code te schrijven zou dit gewoon niet mogen voorkomen.
Praten met programmeurs mogen onze applicatiebeheerders doen. Ik heb het ze al vaak genoeg gezegd. Wat de reden van de leverancier is om de code zo te schrijven weet ik niet, maar het ging eerst mis met een update van Java 6 naar Java 7 (ok, dat is een version upgrade, dan kan het nog), maar er was op een bepaald moment een update van Java 7.45 naar Java 7.51 (even uit mijn hoofd, versienummers kunnen niet helemaal kloppen) en toen gingen de hard gecodeerde security settings van Java zelf bokken en het was niet meer te omzeilen. Het enige dat hielp was 7.51 eraf en 7.45 er weer op, aangezien anders een deel van onze productie niet verder kon werken, want de werkorders waren niet meer op te vragen. We zitten er ook niet op te wachten om elke 3 maanden weer opnieuw de leverancier een nieuwe build te laten opleveren en installeren.

[Reactie gewijzigd door justme256 op 19 maart 2014 14:24]

Zover ik weet kun je Java 6, Java 7 en dan nu ook Java 8 langs elkaar installeren. (Nog niet gesproken over 32 en 64bit versie!!) :?

Welke is nu het beste om te installeren?
Is java 8 downwards compatibele? (Dus wat geschreven is voor 6/7 32 en 64bit zal onder java 8 x64 draaien?)

(Ik heb enkele programma's die java nodig hebben!)

[Reactie gewijzigd door cruysen op 19 maart 2014 13:18]

Java is altijd downwards compatible (enkele bytecode utility libraries daargelaten, maar die kom je als gewone gebruiker niet veel tegen). En het is altijd beter om de laatste te hebben, i.v.m. beveiliging.

Overigens zit ondersteuning voor 32bit ingebakken bij de 64bit installer, dus daar hoef je je in principe ook geen zorgen over te maken.

[Reactie gewijzigd door gpgekko op 19 maart 2014 13:26]

Java claimt altijd min of meer backwards-compatible te zijn, en toch zie ik in de praktijk overal programma's die een specifieke versie vereisen.
In de regel werkt het prima, en als je een specifieke versie nodig hebt, weet je dat meestal wel. Zo ken ik systemen met 3-4-5 verschillende versies van Java naast elkaar... (en het is een wonder dat iedere applicatie vervolgens de juiste files weet te vinden).

Geeft je software geen specifieke versie aan (lees de documentatie!), en zegt het je allemaal niets, kan je het beste de auto-updater gebruiken, dan heb je altijd de (aldus oracle) beste versie, die waarschijnlijk het minste problemen oplevert. Of gooi java van je systeem af, want misschien heb je het wel helemaal niet nodig.

[Reactie gewijzigd door Luxx op 19 maart 2014 13:28]

hier heb je gelijk in, vendors van producten zijn meestal alleen compatible met de versie waar ze op ontwikkeld hebben of updates voor uitgebracht hebben (ook al werkt het prima als je zelf met wat gehack de laatste versie erin zet) dat is vaak een kwestie van disclaimer, en wordt soms ook hard afgedwongen vanuit de sourcecode.
Zelde zijn er echt depricated functies in gebruik waardoor de code echt niet meer zou werken, en meestal gaat het in die gevallen om low-maintenance producten die bij de leverantier op een laag pitje staan.
Toegeven er zijn talloze van zulke producten, misschien zelfs het merendeel. Maar wederom is dit toch echt een fout van de programmeur/leverancier en niet de taal an-sich.

[Reactie gewijzigd door Artimunor op 19 maart 2014 13:37]

Hopelijk is dit de laatste versie van Java waarin applets ondersteund worden. Dan ben ik, als server-side Java developer, eens van dit soort onzin commentaar af, en ook van al die negatieve verhalen over de security problemen in applets. :)
Je zou eens moeten weten hoeveel middleware op Java draait. Traag is het zeker niet in de juiste context (op UI gebied vind ik het ook niet heel goed)

Niemand maakt tegenwoordig nog website obv jsp tech of browser java plugins
Java Applets zijn "deprecated". Oracle adviseert om geen Applets meer te schrijven, maar HTML5 te gebruiken voor rich client apps. Laten we de Applets daarom snel vergeten :-)
Lekker beargumenteerd weer, anyway, om op je "vraag" in te gaan...

Oracle is nu al bezig met Java 9 en ook Java 10 staat nu op de planning.
Wat een goed verhaal! Gefundeerd ook, vertel, wat is je probleem?

Je bent overigens niet verplicht om het te downloaden/gebruiken he :)
Java 8 heeft zich juist gericht op veiligheid vanwege al die nieuwsberichten vorig jaar. Het is in ieder gevaal secuurder dan 7
Dat betekend ook meestal al de "applicaties" niet meer werken met deze nieuwe versie. En je dus de security moet verlagen......
er is backwards compatibility met Java 7, alleen heb je dan de toegevoegde security niet (helemaal)
Een goeie Java applicatie is enorm goed backwards compatible. Alleen als je een pannekoek bent en Java modules niet gebruikt zoals ze gebruikt moeten worden in je applicatie krijg je dit soort compatibaliteits problemen.
Minecraft werkt gewoon lekker op Java 8 :) (Die gebruikt de java 6 compiler)

[Reactie gewijzigd door BJ_Berg op 20 maart 2014 01:56]

Hoewel Samplex het wat grof brengt, ben ik het wel een beetje met hem eens. We gebruiken hier Java applicaties en bij zo'n beetje elke update van Java (ja, zelfs de security updates) is het weer prijs dat ze niet werken :( . Er is voor de leveranciers van de pakketten bijna niet op te programmeren tegen het tempo waarin Java steeds weer nieuwe gaten moet dichten. Ik hoop dat ze nu eindelijk eens een keer de gaten goed gedicht hebben en dat er wat rust komt. Het is namelijk nogal link als je steeds moet blijven hangen op oude versies die vervolgens vrolijk misbruikt worden in het wild (en nee, helaas kunnen we de systemen die Java nodig hebben niet van het web afhouden).
dit lijkt weer een gevalletje "de taal de schuld geven van slechte code"
ik ben persoonlijk ook geen fan van de java-browser-plugins, java zou gewoon html5 moeten genereren (wat het kan, keuze van de programmeur)
je zou hogescholen kunnen beschuldigen dat ze aanzetten tot foutief gebruik van de taal.
er zijn talloze voorbeelden te verzinnen waar .net dezelfde mankementen vertoond.(I.E. 6 only websites iemand? ok dat is wel erg lang geleden)
Het is niet zozeer slechte code, maar meer het probleem dat de code erg gevoelig is voor (security)wijzigingen in de software. Wat ik vooral jammer vind is het feit dat als een gebruiker een update aangeboden krijgt en die uitvoert, de applicatie het vervolgens niet meer doet. Het is blijkbaar voor degenen die de code maken erg moeilijk om te anticiperen op updates van Java. Ik ben geen fan van Java en blijf er op mijn privé systemen ver vanaf, maar het werkt wel goed voor de applicatie waarvoor het gebruikt wordt.

I.E. 6... 8)7 breek me de bek niet open over die troep en vooral sites (sommige banken...) die dat nog steeds vereisen. Maar goed, dat is een andere discussie ;)
dit lijkt weer een gevalletje "de taal de schuld geven van slechte code"
Daar ben ik het niet mee eens. .NET heeft tig security updates gehad en 0 keer software (die ik gebruik) gebroken. Compatibility is iets wat Microsoft als geen ander snapt en waar het bij andere bedrijven vaak aan ontbreekt.

Het verhaal van IE6 only websites heeft niets met .NET te maken, maar met luie programmeurs, net als de 'moderne' webkit-only sites waar je tegenwoordig mee loopt te klooien.
Ik kom bij veel klanten en het is altijd die webapplicaties met Java welke problemen veroorzaken, Centric met hun **4All Key2** applicaties is daar een goed voorbeeld van.
Als een beheerder word je echt niet vrolijk van Java, de ene applicatie moet Java verie X gebruiken de andere Java versie Y.

Als er een security update komt vanuit oracle kan je niet gelijk updaten naar de laatste versie want dan werken er applicaties weer niet en draai je lekker met een Java versies welke makkelijk vatbaar is voor exploits.
je kan meerdere versies van java naast elkaar installen, als je daar niet blij van wordt vind ik het raar dat beheerders wel blij worden van heel veel versies .net naast elkaar geinstalled.
Er zijn slecht 3 versies van .NET 1.x, 2.x (3.x was een aanvulling op 2.x) en 4.x.

Ik denk wel dat de nieuwe lambda support binnen Java een enorme vlucht gaat nemen. In .NET zijn lambda's niet meer weg te denken en uiteraard leunt LINQ zeer zwaar op de lambda's.

Maar na alle negatieve verhalen rondom de veiligheid van Java, kan Java wel weer wat positief nieuws gebruiken, want de 'concurrentie' van andere programmeertalen (c#, ruby en php) is sterk en ik vind het mooi om te zien dat deze programmeertalen features van elkaar overnemen om zo de development community van nog betere tools te voorzien.
Jij bent niet wijs, als je eens wist hoeveel applicaties wij ontwikkelen in Java voor de banking en insurance
Dat er veel applicaties mee ontwikkeld worden wil niet zeggen dat het ook goed is ;)

In mijn ervaring (voornamelijk Android icm werken in Eclipse en werken in Matlab, welke beiden Java zijn) is Java inderdaad vrij traag. Eclipse UI crashed om de zoveel tijd of doet andere rare dingen. Matlab loopt soepel totdat er een java error optreed en er echt hele vage dingen gebeuren.

Ook het hele Java gebeuren op Android is allemaal vrij traag. Persoonlijk ben ik echt een C++ man maar recentelijk ook met C# veel gewerkt. C# is eignelijk net als java ook een geinterpreteerde taal, maar ik zie hier toch niet zozeer de performance en vooral stability issues die ik met java tegenkom. Dit is een bewijs dat ook een geinterpreteerde taal vrij soepel kan draaien (gegeven het zal nooit sneller zijn, hoogstens net zo snel, als een native gecompileerde taal).

Verder vind ik zelf een aantal design princiepes achter Java wat achterhaald, wellicht zeer goed voor de tijd waarin java is ontwikkeld , maar tegenwoordig zijn er betere alternatieven. Een voorbeeld is het werken met Properties wat development in C# echt een stuk makkelijker maakt, dit mist in Java of je moet het simuleren met function calls (Getters en Setters) maar daarmee heb je ook weer niet de kracht die C# kan leveren met Bindings bijvoorbeeld.
Je zou Android Studio moeten proberen, een verademing mijns inziens.

De taal de schuld geven van errors die uit specifieke programma's komen vind ik nogal boud, hoe weet je dat dit echt de taal is en niet de manier waarop het programma dat jij gebruikt geprogrammeerd is?
Inderdaad, anders zouden we ook wel eens kunnen beginnen over al die nikszeggende segmentation faults in C/C++ programma's...

Dan liever duidelijke foutmeldingen van .NET of de JVM wat er precies fout is gegaan!
fouten zelf gaan wel goed in java(stacktraces) maar het optimaliseren ervan is een lastige zaak, zeker met grote programma's. En vanwege de kracht van de Java programmeer taal(je kan echt alles) is het ook wel iets langzamer, maar dat mag je wel verwachten zeker als het niet native support heeft in je OS

[Reactie gewijzigd door BJ_Berg op 20 maart 2014 01:59]

Vanavond dan maar eens updaten.
Lambdas enable you to treat functions as method arguments or code as data.
Hoe veilig is dat dan? Dat 'code as data' klinkt als een sql injection risen from the grave.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True