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 , , 102 reacties

Oracle heeft Java Development Kit 8 uitgebracht. Een van de belangrijkste wijzigingen is de toevoeging van lambda expressies, anonieme functies. De release had eigenlijk al een half jaar geleden moeten plaatsvinden.

JavaDe door Oracle als download vrijgegeven JDK 8 is gebaseerd op de Java Platform Standard Edition 8-specificatie. Eigenlijk had de release al in september vorig jaar moeten plaatsvinden, maar met name extra werk aan Project Lambda zorgde voor uitstel. JDK 8 ondersteunt namelijk lambda expressies waarmee ontwikkelaars functioneel kunnen programmeren. Het werken met anonieme functies zou het gebruik van de objectgeoriënteerde taal efficiënter en eenvoudiger moeten maken.

Onder andere de nieuwe Stream-api van JDK 8 maakt veelvuldig gebruik van lambda expressies voor het parallel verwerken van grote datasets. Nieuw in Java 8 is verder de snellere JavaScript-engine Nashorn, die gebaseerd is op SUN's Da Vinci Machine en die de Rhino-engine aflost, terwijl ook Java Mission Control 5.3  aanwezig is. Tenslotte is er de Date-Time-api, zijn er Compact Profiles-subsets en heeft Oracle diverse beveiligingsverbeteringen doorgevoerd. Oracle zal de vernieuwingen op 25 maart in een webcast uitgebreid uit de doeken doen.

De release valt samen met die van NetBeans 8, die verbeterde analysetools en editors voor Java SE 8, Java SE Embedded 8 en Java ME Embedded 8 bevat. De ide verbetert onder andere de ondersteuning voor Maven, Java EE met PrimeFaces, php en C/C++ en er zijn nieuwe tools voor html5.

Moderatie-faq Wijzig weergave

Reacties (102)

Naast netbeans is ook Intellij IDE vandaag met een nieuwe versie gekomen.
Intellij 13.1 biedt nu ook support voor Java8:

http://www.jetbrains.com/idea/whatsnew/

Intellij > Netbeans in my opinion :)
Voor mij NetBeans > Intellij want ik heb geen zin om voor wat java knutselwerk een licentie a 179 euro neer te tellen. NetBeans is gratis.
Ik snap je keuze, maar gezien ik minimaal 40 uur per week in een IDE zit zou ik niks anders willen dan Intellij. Kosten zijn inderdaad (te) hoog voor een leuk hobby projectje.

Er is wel een free version van Intellij die misschien net genoeg door voor zo'n project, maar als je blij bent met NetBeans zou ik zeker niet switchen :)
Waarom kun je geen 40 uur per week in NetBeans IDE werken?

Redenen voor mij waarom ik NetBeans over iedere andere IDE verkies is dat het ten eerste een gratis IDE is. Ten tweede het werkt zoals het hoort te werken. Ik heb gratis IDE's geprobeerd die geen fatsoenlijke interface hadden of waarvan simpelweg de Git integratie continu crashte. Verder is NetBeans goed uitbreidbaar en populair. Voor mij geen betaalde of gekraakte licenties meer.

Bovendien zitten veel bedrijven ook niet te wachten om een andere IDE aan te moeten schaffen. Laat staan dat er met een gekraakte versie wordt gewerkt. Een gratis pakket wordt sneller toegestaan.
En niemand die Eclipse gebruikt als IDE? Vind die, eenmaal je er gewend aan bent, best wel ok werken :)
Het werkt ook ok, maar het is zo'n chaotisch platform van third parties dat je geen -zekerheid- hebt dat het ok werkt; als je een plugin update heb je al risico dat je IDE in elkaar stort of je workspace ineens vage errors heeft. Op dat gebied vind ik Netbeans en Intellij net iets fijner omdat er wat meer stroomlijning achter zit.

Maar Eclipse heeft verreweg het breedste scala aan plugins die aansluiten op mijn wensen, dus Eclipse blijft mijn vriend :)
Binnen het bedrijf waar ik werk wordt Intellij als standaard IDE gebruikt. Vandaar de overstap van gratis versies naar Intellij.

Sommige collega's gebruiken liever STS/Eclipse of NetBeans vanwege gewenning, maar merk dat als ik af en toe met hun meekijk ik juist veel sterke punten van Intellij tegenkom.

Uiteindelijk draait het er om waar je zelf het prettigst mee werkt, voor mij is dat Intellij en voor een ander is dat een andere IDE. Heb alleen het voordeel dat de prijs van Intellij voor mij geen probleem is, gezien het betaald wordt
De community versie van IntelliJ is gratis. Deze kan veel meer dan de meeste gebruikers gebruiken.
IntelliJ heeft al zeker een jaar support voor Java 8, ik geloof sinds IntelliJ 12. Maar in 13.1 hebben ze het nog verder verbeterd.

Hier een gedetailleerde beschrijving van wat er op het gebied van Java 8 support is verbeterd in IntelliJ 13.1.

[Reactie gewijzigd door jj71 op 19 maart 2014 11:36]

Betere omschrijving inderdaad.
Had ergens al gelezen dat er eerder support was, maar wist niet dat het er al zo lang in zat :)
Aww, er wordt niets gemeld over de nieuwe plaatsen waar annotaties mogelijk zijn zoals List<@Nullable String>

Wat tools zoals Checker Framework en FindBugs mooi kunnen gebruiken om tijdens compile time mogelijke bugs op te sporen.
Het lijkt erg op de Option type uit Scala, maar dan minder mooi geimplementeerd. Zie bijvoorbeeld deze blog voor een uitleg.
Options is iets compleet anders. The @Nullable annotatie (en soortgelijke) is meta informatie voor static code analysis.
De Option type uit Scale is Optional: http://download.java.net/...i/java/util/Optional.html (ook sinds 8)
Ook leuk om direct aan te geven of een functie overweg kan met null arguments of niet. Anders zou je dat in de documentatie moeten proppen.
Ook nuttig te vermelden dat in Java 8 er eindelijk een logische keystore/truststore is die uit meerdere fysieke stores kan bestaan. Dit gaat veel beheerwerk schelen!
Daar wordt ik inderdaad erg blij van! Bedankt voor de tip :)
Kan ook de Windows Certificates store als keystore en truststore gebruikt worden?
"Eigenlijk had de release al in september vorig jaar moeten plaatsvinden, maar met name extra werk aan Project Lambda zorgde voor uitstel."

Deels waar. Mark Reinhold (Chief Architect) verklaarde dat ze de deadline niet hadden gehaald doordat o.a. ontwikkelaars zich moesten richten op het verbeteren van security i.p.v. het ontwikkelen van nieuwe features. Zie: http://mreinhold.org/blog/secure-the-train
Je haalt de Java 8 JDK in de war met de Java 7 browserplugin...
Niet om te zeuren maar de verwarring is snel compleet:
java se
Java jdk
java jre
java server jre
javascript
javaXYZ?

Het zal allemaal wel, ik zie door de koffie bonen de koffie niet meer.
Which package do I need? (onder de downloads)
  • JDK: Development Kit, voor Java software developers
  • Server JRE: voor Systeembeheerders. Deze JRE bevat niet de browser integratie, auto-updater en installer en bevat monitoring tools vanuit de JDK.
  • JRE: Voor consumenten. Deze JRE bevat alles wat een consumenten applicatie nodig heeft, incl support voor applets.
Dus als ik geen browser integratie nodig heb installeer ik beter de Server JRE? Voor de andere dingen is dat (ongeveer) hetzelfde?
Tip aan de Marketing afdeling van Oracle: gebruik logische namen.

Dus gewoon

Java Developer
Java Business
Java Consumer
Je vergeet JavaFX :+
Dat is gewoon een API, je gaat Swing ook niet apart noemen ;)
Javascript is geen java, maar javascript - een volledig andere taal.
Net zoals C# geen C of C++ is.

jdk = java development kit
jre = java runtime environment
se = standard edition (bevat jdk, jre en java server jre)

Kortom echt moeilijk is het niet, java is gewoon java.
I know ;) maar het ging mij om de naam.

Ik bedoel python heeft toch ook geen:
Pythonscript (=compleet wat anders dan python heeft er niks mee te maken maar heet toch bijna hetzelfde)
Python SDK
Python HIJKLMNOP
Python HIJKLMNOP for Servers
Python BLRGT = Python SDK en Python HIJKLMNOP, Python HIJKLMNOP for Servers

Ah well, misschien is het mijn ongelovelijke afkeer van Java + bijbehorende stacktraces dat mij doet ranten hierop. ("Ja, dat ligt aan de programmeur, java is zelf super snel en schoon en blablabla" Ja nou, dan zijn er teveel java prutsprogrammeurs waarschijnlijk. Ik moet wel zeggen dat GUI's supermooi zijn van java. Vooral die karakterset en die uitklap boompjes e.d., prachtig...)

Aight, uitgerant ik ga stukje visualbasic doen..... :P
ps je vergeet java ee -> enterprise edition?;)
Dat gaat dan vooral om de browserplugin. Hieroverzou ik inderdaad zeggen; als het niet absoluut kritisch is voor de uitvoering van je werkzaamheden dan moet je daar zo ver mogelijk van uit de buurt blijven.

Het installeren van de developer kit zal echter niet erg veel beveiligingsrisico's met zich meebrengen :P De normale Desktop installatie zou ook geen probleem moeten zijn, zolang je de verdomde browserplugins maar uitschakelt (en het vinkje voor de spyware uitzet tijdens installatie)
Als je het echt niet nodig hebt, installeer dit dan niet. Java heeft nogal een slechte reputatie met betrekking tot beveiligingsgaten.
Hoeveel mensen die het niet nodig hebben installeren de JDK? :? Het gaat hier om een nieuwe versie van de taal als geheel. Dit is als zeggen "Als je het niet nodig hebt, installeer de C++ compiler dan niet."
Je vergelijking is inderdaad erg scheef. Het is net als "Tank niet bij Shell, want Opel heeft slechte brandstoftanken!".

Zoals hierboven reeds vermeld gaat het om een nieuwe release van de JDK en Java als taal. Volgens mij doel je eerder op Java-plugins in browsers.
En wat heb je aan Lambda Expressies zonder Delegates?
Lambda expressions zijn gebaseerd op single method interfaces. Die vervullen dezelfde rol in Java als delegates in C#.

Zie State of the Lambda voor een uitleg over hoe 't werkt.

[Reactie gewijzigd door jj71 op 19 maart 2014 11:04]

Delegates in C# zijn (overwegend) multicast delegates. Het grote verschil is dat één delegate instantie meerdere functies/lambda's bevat. Of dat goed/slecht is hangt ervanaf, en je gebruikt het opzich bijna nooit behalve met events. Maar het blijft een groot verschil met java-lambda's, waar het standaard 1 functie representeert.

[Reactie gewijzigd door Dykam op 19 maart 2014 11:59]

Jammer dat er zoveel mensen -1'tjes krijgen omdat ze aanhalen wat ze de afgelopen maanden hebben gehoord over Java, ja dit gaat dan wel over de JDK, maar het zou toch een slimme zet van Oracle geweest zijn om deze release aan te pakken als kans om even lekker te boasten over de verbeterde veiligheid etc.

Ik was tot voor kort Flash developer, feit is dat ik dit niet meer ben omdat Adobe de bal zo hard heeft laten vallen toen Flash het predicaat 'slecht' kreeg, opeens (oke 1,5 jaar later) wil niemand meer flash, of flash developers. M'n punt is, er zijn veel meer Java developers, en als Oracle (net als Adobe) blijft doen alsof hun neus bloed staat in een jaar of 2 iedereen op straat. Feit is dat het process al ontketend is door de slechte berichtgeving over Java de afgelopen maanden, en Oracle lijkt er niets tegen te doen.
Oracle doet er juist wel van alles tegen. Zoals ik eerder vermelde is dit een van de redenen waarom JDK 8 vertraagd was. Om meer developers/testers aan security te laten werken.

Het "lijkt" of hier niks tegen gedaan wordt omdat dit niet door de media opgepakt wordt. Het nieuws dat er weer een veiligheidslek gevonden is, is natuurlijk veel sappiger dan vertellen wat Oracle intern aan security doet.

De negatieve sfeer rond Java wordt versterkt door mis-geïnformeerde mensen. Veel mensen weten niet eens het verschil tussen Java het platform en Java de taal. Ze schrijven Java bijvoorbeeld af als server-side taal omdat er fouten in de sandbox zaten, dat terwijl Java server-side bijna nooit in een sandbox draait. Dit is (bijna) alleen relevant voor client side applicaties zoals applets.
Mogen ze eens met hun andere producten gaan doen, Oracle 11 dumpt gewoon een Java 5 in je server. Idem Oracle Access Manager... En dat alleen voor de installer nota bene.
Verschil is wel dat, itt Flash, bijna niemand die met Java bezig is, iets doet met web applets via de browser plugin - Java (het framework) is anno 2014 een serverside platform. De andere grote groep Java devs zitten op Android.

Waar ik eigenlijk op hoop is dat Oracle eens het besluit neemt om de hele browserplugin af te schieten, dan maar pech voor backwards compatibility enzo. Hoe onterecht het misschien ook is (een Javascript exploit wordt als een onschuldige Chrome/IE/Mozilla bug gezien, een Java exploit in Apple's (!!) JVM als de schuld van evil Oracle), je kan de publieke opinie niet meer veranderen IMO.

[Reactie gewijzigd door Dreamvoid op 19 maart 2014 16:13]

Geweldig! Het is goed om te zien dat lambda expressies eindelijk naar Java komen. Tegenhanger (qua high-level programmeertaal) C# heeft dit al langere tijd en het maakt compact en leesbaarder programmeren mogelijk.
Absoluut!

Nou moet ik zeggen dat Lamda notatie niet overal in elke versie/namespace/class support wordt in C#
(bijvoorbeeld ADO.NET Entity Framework 4.0 heeft niet overal ondersteuning voor lambda als arguments voor een methode)

Dit is natuurlijk in nieuwere versies wél geïmplementeerd, hoe moet ik dat zien bij Java? Is dat dan allround automatisch overal beschikbaar?
Bij Java krijg je als argument een object binnen dat een interface implementeert met een enkele methode. Dus als er een functie was die Runnables accepteerde, dan zijn die Runnables nu met lambdas door te geven.

[Reactie gewijzigd door Cilph op 19 maart 2014 10:50]

ah ja precies. Flinke improvement dus!
Java heeft idd degelijk wat in te halen met functies die C# al langer heeft. Hopelijk zien we Properties en Delegates ooit verschijnen.

[Reactie gewijzigd door Cilph op 19 maart 2014 10:34]

Een delegate kan je toch gewoon zelf al doen icm Interfaces?

Edit: mogelijk dat ik over Objective-C delegates praat, en hier iets anders bedoelt wordt.

[Reactie gewijzigd door ZpAz op 19 maart 2014 14:20]

Een delegate in C# is een funtion pointer.
In Objective C is een delegate een callback instance.

Als een lambda functie in Java niets anders doet dan een methode aanroepen:
(Object o) -> { return o.toString()}
kan er ook worden geschreven:
Object::toString

[Reactie gewijzigd door DrBreakalot op 19 maart 2014 15:02]

Kleine verbetering:

C# delegate is een verzameling van function pointers. Met een delegate beschrijf je hoe een bepaalde functie of methode er uit moet zien. Soort van interface, alleen dan voor functies en methodes dus. Vervolgens kan men zich abonneren op een instantie van een delegate, hierbij worden de functies (de call-backs) die in de invocation list aanwezig zijn aangeroepen op een gekozen moment (delegate.Invoke())

Binnen c# bestaat dan ook nog een event, waarbij je een delegate instantie hebt waarbij o.a. de invocation list beschermd is van buiten. Alleen het object waarin het event staat mag deze beheren. Hierdoor kan een extern object alleen zijn eigen abonnement annuleren, en niet heel de lijst weg gooien :)

Verder heeft C# ook nog Action en Func. Daarbij kun je in-line een soort delegate definitie maken. Een delegate moet je namelijk los specificeren. Met een Action of Func typt dat wat sneller weg :)

[Reactie gewijzigd door wootah op 19 maart 2014 20:57]

De klassieke Java taal heb je het hier nu over, niet het Java platform. Er zijn meer talen op het platform he, wellicht dat er eentje tussen zit die beter aansluit bij je wensen. Het is al tijden geen verplichting meer om de Java taal toe te passen.
Er is natuurlijk al heel lang Scala die dit aanbiedt.
Het zou mooi zijn als Java ook ooit nog eens iets krijgt waarbij automatisch getters/setters worden aangemaakt voor een klasse met variabelen (lees: 'verborgen aanwezig'). Grote delen code bestaan in de praktijk uit steeds maar weer hele pagina's getter-/settermethoden en dat is 9/10 keer overbodig.

Verder blij dat er nu ook Lambda-uitdrukkingen mogelijk zijn, dit gebruikte ik al een aantal jaren terug in Groovy (closure? al begrijp ik dat het niet 1:1 hetzelfde is) en werkt handiger en is ook leesbaarder.

[Reactie gewijzigd door Tjeerd op 19 maart 2014 14:19]

Hoe zie je dit voor je dan? Wie beheert dan welke properties wel en niet getters en setters krijgen? Wanneer kan ik deze verborgen getters en setters dan wel/niet aanroepen?

Ik kan me wellicht een soort variant voorstellen met annotaties oid, maar zie dit een beetje als een non-issue. Ik wil graag zelf in de hand houden wat er wel en niet mag worden opgevraagd of aangepast per object.
Hier is het C# systeem met automatische properties erg handig.
class Persoon
{
public string Naam { get; set; }

public DateTime GeboorteDatum { get; private set; }
}

[Reactie gewijzigd door sanderev66 op 19 maart 2014 11:25]

Ik ken het dus inderdaad ook van C#, vandaar dat ik het eigenlijk 'mis' in Java.
Hmm, ja dat is een ietwat andere notatie als wat ik had bedacht met annotaties. Dat zou dan iets worden als:

class Persoon {
@GET
@SET
private String m_naam;
}

Waarbij een 'verborgen' public getter en setter impliciet gaan bestaan.
Maar nogmaals, ik vind die getters en setters niet echt een probleem. Ik heb er ook nooit echt hele pagina's van vol. En ik wil zeker geen automatische getters en setters. Sommige dingen zijn gewoon private omdat ze private moeten zijn.
[...]Sommige dingen zijn gewoon private omdat ze private moeten zijn.
Mja, het mooie van de C# properties is natuurlijk dat je de getters en setters nog steeds access modifiers kan meegeven zonder af te doen van de eenvoudigere notatie. Je kan de getters en setters zelfs alsnog uitbreiden als je dat wilt, zie bijv. het voorbeeld hier: http://msdn.microsoft.com/en-us/library/x9fsa0sw.aspx
Je kan dus eenvoudig wisselen tussen auto-implemented en 'gewone' getters en setters, zonder dat code hoeft te worden omgebouwd.

[Reactie gewijzigd door Caelorum op 19 maart 2014 11:56]

Met de Lombok plugin ben je van alle getters en setters af: http://projectlombok.org/
Dat is precies wat ik bedoelde, dank, ga dit gelijk aan een collega voorleggen :)

Als ik de beschrijving lees is er alleen wel iets om op te letten: Project Lombok maakt gebruik van non-publieke Java-API's om tijdens het compileren getters/setters aan te maken en er is geen garantie dat met nieuwe JDK's altijd zal blijven werken, al was er begin deze maand nog een nieuwe versie waarin JDK8 ook wordt ondersteund. Hopelijk komt er bij een nieuwe Java-versie ondersteuning voor Lombok-achtige annotaties.

[Reactie gewijzigd door Tjeerd op 19 maart 2014 14:20]

Er zijn momenteel al verschillende frameworks waarin je dat niet expliciet hoeft te doen, zoals Grails.

Maar als je puur in Java bezig bent, dan vind ik dit ook niet zo'n groot probleem aangezien je (hopelijk) toch in een IDE werkt die al deze getters/setters met 2 klikken voor je genereren..
Ik ken het inderdaad van Grails, waarbij je bijv. de domeinen definieert met de velden en vervolgens is dit allemaal automatisch beschikbaar, zonder dat de domeinen allemaal getters/setters bevat. Houdt de code een stuk overzichtelijker.
Met het oog op security (en slechte developers) heb ik liever dat ik expliciet moet aangeven dat een getter / setter public is.

Overigens genereer ik dat spul gewoon met mijn idee, letterlijk 3 toetsen i.c.m. codefolding.
De access modifier heeft niets met security te maken. Alle access modifiers kunnen worden aangepast met reflection.
Ze zijn enkel om ervoor te zorgen dat een ontwikkelaar niet per ongeluk een variabele aanpast als dat niet de bedoeling is.
Dat komt volgens mij meer door het feit dat programmeurs niet goed afschermen en teveel getters en setters beschikbaar stellen. Beetje verkeerd begrip van encapsulation.
Je weet dat je attributen ipv private ook public kan gebruiken?
Niet dat het programma en vooral onderhoud technisch altijd even slim is, maar niemand houd je tegen.
Ik mis in het artikel dat dit ook de eerste Java versie is die niet wordt ondersteund voor Windows XP. XP gebruikers moeten dus op 7 blijven hangen. Anyway, Oracle heeft al enkele mooie stappen gemaakt en Java 8 is er zeker eentje van, maar er is nog een lange weg te gaan, dat ze eerst de reputatie maar eens terug opgepoetst krijgen.
Tja, Windows XP heeft nog tot 8 april en dan wordt het niet meer ondersteund door Microsoft. Dus waarom zou Oracle (of welke software-maker dan ook) het dan nog moeten ondersteunen? Het is ook niet zo dat het niet bekend was dat Windows XP ondersteuning zou stoppen...
Totaal niet meer relevant!

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