Oracle stelt Java 8-release uit tot begin 2014

Oracle heeft besloten om de release van Java 8 door te schuiven naar 2014. Het bedrijf is hiertoe genoodzaakt doordat het ontwikkelaars heeft moeten vrijmaken om de beveiligingsproblemen in bestaande Java-versies te verhelpen.

Java 8 zou oorspronkelijk in september uitkomen. In deze versie moet Java via het zogeheten Project Lambda uitbreidingen krijgen om moderne multicore-processors beter te benutten. Mark Reinhold, chief architect van Oracle's Java Platform Group, heeft echter op zijn weblog laten weten dat de release van Java 8 is uitgesteld naar begin 2014. Daarmee is tevens de geplande release van Java 9 doorgeschoven naar begin 2016.

Oracle zegt dit besluit te hebben genomen omdat een aanzienlijk deel van het ontwikkelteam is ingezet om acute beveiligingsproblemen in bestaande Java-versies te verhelpen. Hierdoor zijn er tijdelijk onvoldoende developers beschikbaar om de oorspronkelijke deadline van Java 8 te behalen. Daarnaast zegt Oracle dat het niet wil snijden in de testperiode van Java 8, mede om het probleem van steeds nieuwe beveiligingsgaten in Java 6 en 7 te voorkomen. Ook het laten vallen van Project Lambda zou ongewenst zijn, omdat de featurelijst wel erg beperkt zou zijn als dit onderdeel ontbreekt in Java 8.

Reacties (95)

wat weer een reacties hier van vele nono's. Sorry hoor maar dat gezeur van ik gebruik java nooit bla bla..
Je gebruikt java enorm veel, velen van hier, Tweakers gebruikt java...

Vele vele sites die je bezoekt zijn gebaseerd op java, Android is java, (runtime is dan niet van oralce maar van google, maar waar alles in ontwikkeld wordt welke ide je dan gebruikt bv eclipse wordt allemaal gedaan in java)

Maar dat java 8 is uitgesteld is erg jammer.. Want het is wel een prachtige release aan het worden..

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

Daarmee heeft java in 1 klap vele features die we al jaren graag zien er in, ook is alles toch echt mooi clean gehouden en goed over na gedacht zo ver ik alles heb kunnen zien.

Java 8 is echt 1 van de belangrijkste en grootste releases die java heeft gehad in jaren (java 5 is te vergelijken maar ik vind deze nog groter)

Ik kan niet wachten om het te gebruiken, en dit maakt het allemaal dat het flink langer weer gewacht moet worden tot je het echt kunt gebruiken, zeer zeker als je niet puur voor je zelf ontwikkeld maar moet voldoen aan 3de partijen, dan duurt het nog veel langer..

Wat een onzin. Dat t.net toevallig Java gebruikt voor hun zoekdingetje, betekent niet dat IK Java gebruik. t.net had net zo goed Solr of Whoosh kunnen gebruiken voor hun search, daar heb ik toch niets mee te maken?

Feit is dat de Java browser-plugin gewoon ontzettend onveilig is en niet meer verstandig is om te gebruiken. Eigenlijk zouden ze die gewoon moeten stopzetten....

[Reactie gewijzigd door Ramon op 20 april 2013 15:36]

Stopzetten en meteen aardig wat applicaties werken niet meer. PostNL, ING, DNB, allemaal bedrijven die deel van hun website met een java-applicatie laten draaien.

Elke update is het ook weer raak, werkt het niet, verkeerde versie, begint het weer opnieuw.

Ik heb liever ook niet, maar je moet wel als je gebruik wil maken van hun diensten.

[Reactie gewijzigd door SinergyX op 20 april 2013 15:51]

Het zou wel schelen als de plugin niet meer standaard geinstalleerd zou zijn.
Nu werk ik zelf veel in JAVA, maar de plugin heb ik al jaren niet meer nodig gehad. mocht die een keer keer nodig zijn installeer ik die wel.

jij gebruikt dus omdat t.net het gebruikt of welke andere site dus ook

Wat een idiote veronderstelling dat t.net dat niet heeft hoeven gebruiken, het gaat er om dat ze het wel gebruiken en vele andere sites ook.

Ik programmeer in java, voor de server maar ook voor java desktop app. maar die hebben geen van al die plugin nodig. En daar gaat het nu altijd hier om
Met alle artikelen die hier weer op tweakers komen hebben we weer een enorme sloot aan mensen die weer beginnen te zeuren over de browser plugin.. Dat heeft weinig te maken met java als platform en taal, het is toevallig dat die vm die het meest gebruikt is die net heeft en daar zitten wat lekken in. Net als in verschillende browsers of andere dingen

Dan heb ik het niet eens over dat de meeste mensen gewoon van alles downloaden en uit voeren.... Dus het is allemaal altijd zwaar overdreven

Haha en waar is Solr mee geschreven dan?

Ja en Whoosh is met Python geschreven, punt was dat het voor mij niet uitmaakt welke server-side tech ergens gebruikt wordt.

Ik heb voor exact 1 website Java nodig: Intel. Dat is voor mijn videodriver update controle. Maar die driver werkt goed, dus van alle machines is Java verdwenen.

Juist, en weet je ook waar op alle andere sites die je bezoekt wellicht iets van Java draait in de backend?

Ik draai persoonlijk al heel wat jaren geen Java meer op mijn eigen PC's. Zelf heb ik het niet nodig en tot op heden geen website of iets anders tegengekomen dat ik het nodig heb. Java is tegenwoordig meer veiligheidsrisico door de gaten in de plugin dan handig.

Overigens de machines waarop ik (helaas) Java nodig heb draai ik de Enhanced Mitigation Experience Toolkit om te proberen de exploit mogelijkheden van Java zo veel mogelijk te beperken. Overigens is EMET ook handig om andere mogelijke exploits als in Adobe Reader en Flash in te dammen.

Het is sowieso verstandig om je browser van zo min mogelijk plugins te voorzien. Elke plugin kan een risico vormen.

Jij hebt het misschien niet lokaal nodig, maar wat als Tweakers nu alles opsloeg in een MongoDB instance/cluster, aangesproken via een Java driver. Dan was je toch echt afhankelijk van Java om Tweakers te bezoeken

Java is prima in de backend van websites en in mindere mate, het schrijven van desktop applicaties, maar voor de frontend van webapplicaties absoluut niet meer van deze tijd. Niet alleen onveilig, maar in veel gevallen ook overbodig. Gelukkig hebben een hoop bedrijven dat door en zie ik steeds minder java op websites voorbij komen (ik heb het dus niet over javascript!). Die java browserplugin mogen ze van mijn part zo snel mogelijk de nek omdraaien!

Jij hebt het misschien niet lokaal nodig, maar wat als Tweakers nu alles opsloeg in een MongoDB instance/cluster, aangesproken via een Java driver. Dan was je toch echt afhankelijk van Java om Tweakers te bezoeken

Iets zegt me dat Tweakers een scherpe daling in zijn bezoekersaantallen zou gaan zien en er ergens anders iemand blij zou worden van het extra bezoek.

Tweakers is nou niet bepaald een essentiële dienst of zo...

[Reactie gewijzigd door R4gnax op 20 april 2013 18:06]

Op een laptop heb ik OpenOffice draaien en die is ook behoorlijk crippled zonder Java.

offtopic:
Ik draai OpenOffice omdat de exe-installer wel installeerde en de MSI van LibreOffice niet.

Verder draait onze vpn clientside op Java, zonder dat kan ik dus niet vanaf thuis inloggen.

[Reactie gewijzigd door BeosBeing op 24 april 2013 11:00]

Voor een web back-end lijkt Java me compleet overbodig en onhandig. De performance is opzich vast beter dan vroeger, maar dan nog rijst de vraag: "waarom zou je". Voor cliënt side is het gebruik ervan vaak maar niet altijd te vermijden (bijvoorbeeld handig als je "vrij geavanceerde" applicatie-achtige functionaliteit in een website wilt hangen, bijvoorbeeld bij online-virusscanners). Voor portable software (applicaties die op computers, laptops, tabletten en telefoons met meerdere OS'sen moeten kunnen draaien) is het nog steeds een goed bruikbare oplossing. Dat was ook het sterke punt waar het al vanaf het ontstaan veel voor werd ge-promote.

[Reactie gewijzigd door mae-t.net op 21 april 2013 04:24]

maar dan nog rijst de vraag: "waarom zou je".

Performance en schaalbaarheid grappig genoeg... Kijk hier even naar: http://www.theregister.co...ic_traffic_saved_by_java/

Hotspot (de defacto JVM) is in basis gewoon een virtual machine en een damn goeie ook. De taal die er voornamelijk op gebruikt word is Java maar er zijn ook aanpassingen zodat je Ruby en Scala als taal kunt gebruiken.

Als je denkt dat het compleet overbodig is moet je misschien is kijken naar dit lijstje: http://wiki.apache.org/hadoop/PoweredBy Iedereen die Apache Hadoop gebruikt heeft automatisch meteen Java in zijn backend (bol.com staat niet in de lijst maar gebruikt het overigens ook).

[Reactie gewijzigd door 34749 op 21 april 2013 11:32]

Voor een web back-end lijkt Java me compleet overbodig en onhandig. De performance is opzich vast beter dan vroeger, maar dan nog rijst de vraag: "waarom zou je"

Omdat er voor Java meer programmeurs beschikbaar zijn dan in welke andere taal dan ook?

Omdat er voor Java meer libraries voorhanden zijn dan voor zo'n beetje elke taal?

Omdat de diverse Java frameworks (b.v. Java EE) bekend staan als enorm krachtig en tegelijkertijd erg eenvoudig?

Omdat Java van alle high-level talen zo'n beetje de beste performance heeft? Het komt vrij dicht in de buurt van C en C++, en verslaat deze zelfs af en toe (vanwege handig gebruik van runtime optimalisaties).

De vraag is precies andersom, waarom zou je NIET Java gebruiken voor de back-end?

Zo'n beetje het halve web of meer draait Java in de back-end (waaronder Facebook, Twitter, maar ook Tweakers), en meer dan je denkt gebruiken het ook in de front-end, met name JSF, Spring MVC, Wicket en wat oudere websites nog steeds Struts (b.v. de websites van KLM, NS en Nuon).

[Reactie gewijzigd door flowerp op 20 april 2013 21:08]

Omdat er voor Java meer programmeurs beschikbaar zijn dan in welke andere taal dan ook?
Dit is een cirkelredenering. Als je dit aanhoudt zal niemand ooit in een nieuwere (betere) taal gaan programmeren omdat de rest allemaal al Java doet. Daarnaast is een goede programmeur over het algemeen geen "Java-programmeur", maar kan zich nieuwe talen snel eigen maken.

Omdat er voor Java meer libraries voorhanden zijn dan voor zo'n beetje elke taal?
Hoe kom je hierbij? Heb je ze geteld?

Omdat de diverse Java frameworks (b.v. Java EE) bekend staan als enorm krachtig en tegelijkertijd erg eenvoudig?
Dit zegt niets over Java maar meer over de mensen die libraries schrijven. Voor andere talen zijn er net zo goed krachtige libraries en frameworks aanwezig, zelfs voor een gedrocht als bijv PHP.

Omdat Java van alle high-level talen zo'n beetje de beste performance heeft? Het komt vrij dicht in de buurt van C en C++, en verslaat deze zelfs af en toe (vanwege handig gebruik van runtime optimalisaties).
Onzin. Dit soort uitspraken komen vaak van benchmarks waarbij super-geoptimaliseerde Java-software wordt vergeleken met niet-geoptimaliseerde C code. C wordt direct gecompileerd naar assembly en dan nog eens geoptimaliseerd door de compiler terwijl Java in een VM draait, waardoor Java simpelweg trager is.

De vraag is precies andersom, waarom zou je NIET Java gebruiken voor de back-end?
Omdat Java totaal onnodig in een resource vretende VM draait. Dit is leuk voor platform-onafhankelijkheid maar over een backend heb je over het algemeen volledige controle, dus ook over het platform. Daarnaast is het naar mijn mening een vreselijke taal om in te programmeren, 50 regels in Java zijn 20 regels in een willekeurige ander high-level taal zoals bijv. Python. Hier is een interessant artikel over Python vs Java waarin dit wordt uitgelicht.

Dit is een cirkelredenering. Als je dit aanhoudt zal niemand ooit in een nieuwere (betere) taal gaan programmeren omdat de rest allemaal al Java doet.

Maar welke taal is dan echt beter?

Er zijn zo'n 15 talen die momenteel allemaal pretenderen de "next Java" te zijn, waarvan het grote (nja, relatief grote) publiek er misschien 3 of 4 van kent.

Allemaal hebben ze zelf ook weer nadelen.

Ik ben persoonlijk wel gecharmeerd van C#, maar die heeft het grote nadeel van MS-only. Ja, er is Mono, en nee dat is niet waar de kern van de ontwikkeling zit.

Scala lijkt leuk, maar idomatisch Scala (whatever dat is, want daar is niemand het over eens, maar laten we zeggen met lekker veel functionele constructies erin) heeft een nogal slechte performance. Irononisch genoeg moet je Java-style Scala schrijven voor een beetje goede performance. Zie http://java.dzone.com/articles/benchmarking-scala-against

Er is ook een universitaire studie geweest waaruit bleek dat je in Scala niet sneller leert te programmeren, niet productiever bent en niet beter gebruik maakt van concurrency (zie https://cdn.anonfiles.com/1346131830146.pdf).

Daarnaast kent Scala geen binary compatibility en is het na 10 jaar nog steeds niet duidelijk wat nou idiomatic Scala zou moeten zijn.

Voor de meeste andere talen die pretenderen die next java, java killer, etc te zijn gelden vergelijkbare dingen. Er zijn leuke hello worlds die laten zien in dat je met NOG minder code die hello world kan bouwen, maar zodra je er -echt- mee gaat werken blijkt dat ook die taal dan weer geen silver bullet is.

Hoe kom je hierbij? Heb je ze geteld?

Ja, eigenlijk wel. Bij voorstudies voor een project kijken we dikwijls wat er al beschikbaar is aan functionaliteit, en 9 van de 10 keer blijkt dat er voor Java meer beschikbaar is dan in welke andere taal dan ook in het segment voor web/serverside/back-end. Natuurlijk zijn bepaalde domains soms dominant in andere talen. A+ gaming is C++, embedded is C, AI is veel Prolog (misschien niet echt dominant, maar het komt er tenminste voor).

Dit zegt niets over Java maar meer over de mensen die libraries schrijven

Gedeeltelijk, en het doet niets af aan het feit. Niemand zegt dat Engels of Duits "betere" talen zijn dan Nederlands, maar er is wel degelijk meer materiaal beschikbaar in die talen.

Daarnaast is de standaard library wel degelijk een direct onderdeel van het Java eco-systeem. Sun, nu Oracle en de JCP partners hebben de beperkte resources die ze hadden voornamelijk in de libraries (zowel Java SE als Java EE) en VM gestopt. Die hadden ze ook in de taal kunnen stoppen, maar men heeft bewust een keuze gemaakt. De standaard libraries worden wel degelijk als belangrijk onderdeel van de taal gezien, dat is bij C++ b.v. niet anders.

Dit soort uitspraken komen vaak van benchmarks waarbij super-geoptimaliseerde Java-software wordt vergeleken met niet-geoptimaliseerde C code. C wordt direct gecompileerd naar assembly en dan nog eens geoptimaliseerd door de compiler terwijl Java in een VM draait, waardoor Java simpelweg trager is.

Jammer dat er niet een -1 DOM!, moderatie bestaat. Maar sorry, dat is gewoon een DOMME opmerking.

Waarom denk je dat er onderzoek is naar runtime optimizers voor binare code? Google eens op Dynamo.

Met runtime informatie weet de JIT of een bepaalde method wel of niet wordt aangeroepen, of een branch wel of niet in de meeste gevallen wordt genomen, en kan daar heel gericht op optimaliseren tijdens het draaien van de applicatie.

Bepaalde algortimes met bepaalde datasets presteren wel degelijk veel beter met een runtime optimizer dan met een een statische optimizer. En dan hebben we het NIET over slechte C code vs optimized Java code, maar over beiden die highly optimized zijn.

Gemiddeld zit Java ongeveer in de legeau van C++, met een aantal benchmarks waar het even snel is, en sommige waar het een factor 2 langzamer is. Vergelijk dit met Ruby dat makkelijk 80x of zelfs meer dan 200x langzamer is dan C++. Wat in C++ dus op z'n snelst 1 seconde is, is dan in java ook 1 seconde of uiterlijk 2 seconde, maar in Ruby meer dan een minuut of zelfs ruim meer dan 3 minuten.

Zie b.v. http://benchmarksgame.ali...-programs-are-fastest.php

Omdat Java totaal onnodig in een resource vretende VM draait.

Right, waarom ga ik hier nog op in...

Daarnaast is het naar mijn mening een vreselijke taal om in te programmeren, 50 regels in Java zijn 20 regels in een willekeurige ander high-level taal zoals bijv. Python

Python is een vreselijk taal, met die nare 1 regelige closures omdat Guido er geen standaard formatting voor kon bedenken en het toppunt van alles is de GIL.

Dat kun je anno 2013 toch niet serieus nemen?

[Reactie gewijzigd door flowerp op 21 april 2013 00:02]

Vooral voor server toepassingen is Google Go interessant. Qua benchmarking zit het ongeveer in de range van Java. Qua libraries (packages) loopt het nog achter in vergelijking met C/C++ en Java omdat de taal nog jong is. Hier een overzicht van de externe packages en de "standard library".

[Reactie gewijzigd door Anoniem: 505261 op 21 april 2013 11:48]

Toch hoor je ook nagenoeg niets van Go meer na een grote initiële hype.

Ik ben het tenminste nog bij geen enkel project in het wild tegengekomen.

Zie de "succes stories" oftewel de users.
Hier de link naar de golang-nuts user groups. Werkelijk iedere vraag is al eens gesteld. Het is zeer leerzaam, ook als je kijkt naar hoe mensen reageren zo nu en dan

Momenteel wordt bv ook gekeken hoe het in Debian toe te passen. De open source community ziet echt potentieel in Go.

Maar het is niet een commercieel product zoals C# waar geld mee verdient gaat worden. De marketing zal dus vooral komen omdat Google het project sponsort en door de gebruikers. Net zoals met vele open source projecten zal het dus iets langer duren voordat het echt toegepast gaat worden.

Trouwens, toevallig is a.s. vrijdag (26-4) een golang meeting in Amsterdam. Be there!

Edit: Sorry, het is de 26e ipv de 25e

[Reactie gewijzigd door Anoniem: 505261 op 21 april 2013 13:12]

Gebruikt Marktplaats dan Go tegenwoordig???

Waar heb je ergens Marktplaats gezien?

Als je op je eigen link clicked zie je dat de meeting bij Marktplaats office is en Marktplaats de sponsor is.

Tenzij Marktplaats tegenwoordig meetups voor random programming languages support, vroeg ik me af of ze er dan een belang in hebben en zo ja of ze het dan gebruiken voor hun fameuze rewrite van de PHP codebase.

Ach, dat zou zo maar kunnen...
Als ze mensen zoeken, tja dan is een meetup natuurlijk de uitgekozen plek denk ik zo. Neem maar vast je visitekaartjes mee.

[Reactie gewijzigd door Anoniem: 505261 op 21 april 2013 17:15]

Toch komt het wel een beetje wispelturig over. De rewrite van hun PHP code base zou eerst naar Java toe zijn (dat is ook een belangrijk taal binnen ebay).

Maar de keuze van het framework was ook om de havenklap weer anders. Als ik me niet vergis zijn JSF, Wicket en Spring MVC de revue gepasseerd, en toen ook Play! en Scala.

Als het nu weer Go is moet misschien iemand eens zich achter de oren gaan krabben.

Het probleem met alternatieve talen is dat er telkens weer iets anders cooler is. Vandaag is het Scala, morgen Go, en overmorgen toch maar Clojure. Dat maar geen keuze kunnen maken en telkens weer naar iets anders overswitchen is heel typerend.

Onzin. Dit soort uitspraken komen vaak van benchmarks waarbij super-geoptimaliseerde Java-software wordt vergeleken met niet-geoptimaliseerde C code. C wordt direct gecompileerd naar assembly en dan nog eens geoptimaliseerd door de compiler terwijl Java in een VM draait, waardoor Java simpelweg trager is.

Dit is inderdaad een punt dat je vaak hoort, maar het is niet echt een lekker argument. Het "lompste" wat de VM kan doen is als jij je programma opstart, alle bytecode compilen naar assembly, dan jouw geliefde optimalisaties van de assembler uitvoeren en dan het programma opstarten. In die situatie verlies je ten opzichte van C dus alleen maar tijd bij het opstarten van je programma en zou het daarna in theorie even efficient moeten kunnen draaien. En doorgaans zijn we toch geinteresseerd in de tijd die het programma nodig heeft voor operaties die je doet nadat het programma is opgestart.

Het belangrijke verschil met C/C++ is natuurlijk het feit dat na compilatie de VM runtime kan profilen wat het programma met zijn input doet en eventueel de opgedane "kennis" gebruiken om bepaalde stukken opnieuw te compileren met bepaalde optimalisaties die alleen nuttig zijn in bepaalde situaties. In principe zou je dat soort technieken ook wel in C/C++ kunnen implementeren, maar daar kost het je bloed, zweed en tranen om dat er zelf in te programmeren, terwijl je het bij Java dus cadeau krijgt van de VM-technologie. Dit is de runtime optimalisatie waar flowerp het in haar verder uitstekende post ook al over had.

Kortom, je hebt wel gelijk dat de vergelijking misschien niet helemaal eerlijk is, omdat C/C++ alleen aan statische optimalisatie kunnen doen, terwijl Java aan statische én dynamische optimalisatie doet (en de JVM door de jaren heen in beide dingen heel goed geworden is). Maar de opmerking dat het geoptimaliseerde Java tegen standaard C++ is, is niet waar - je hebt hevig geoptimaliseerde C++ nodig (die namelijk de runtime optimalisaties zelf implementeert) om een standaard Java programma te verslaan in de situaties waar het over gaat.

[Reactie gewijzigd door sirdupre op 21 april 2013 13:19]

Zelfs Tweakers gebruikt een Java backend als ik me niet vergis..

Java is niet alleen op het web hè, er zijn ook voldoende desktopapplicaties die in Java geschreven zijn.

Java is best een mooie programmeertaal, gestructureerd en strict, maar het mist gewoon features die andere talen wel hebben. Ik hoop dat er anytime soon een nieuwe crossplatform taal komt, die de fouten in java fixt, en ook gemakkelijk op linux/OSX draait.

@windwarriror
Iets als C++ of Vala?

C# vind ikzelf een pracht taal, alleen jammer dat hier niet (echt) cross platform is.

En Mono? Werkt dat niet goed dan?

En Mono? Werkt dat niet goed dan?

Werkt niet overal war Java wel werkt. Geen vergelijk dus.

houdt je an de standaards (gebruik dus geen extensies) en het is praktisch platform onafhankelijk.

Vala is een mooie taal inderdaad, maar leunt misschien te hard op Gnome libraries, plus dat het weer een gecompileerde taal is, dus binaries niet crossplatform zijn zoals ze dat bij Java wel zijn. C++ heeft dezelfde problemen, en is nog een stuk meer low level dan Vala.

Welke "features" mis je dan in de programmeertaal java? En heeft een nieuwe programmeertaal niet nog veel meer risico's op fouten dan een platform als java dat al een tijd bestaat en veel gebruikt wordt?

Volgens mij verwar je de java-plugin met de programmeertaal java. Er is vanaf dag 1 iets serieus mis gegaan met betrekking tot java applets in de browser, maar voor de rest is Java een prima programmeertaal, die ik weet niet voor hoeveel serverapplicaties wordt gebruikt.

In java geschreven programma's draaien prima onder Windows, Linux, OS/X, de standaardbibliotheek is ongelooflijk uitgebreid, en daarnaast zijn er ongelooflijk veel goede, robuuste frameworks en bibliotheken om volwaardige applicaties te schrijven.

Nee, ik doelde in deze niet specifiek op de java plugin. Wat ik mis in Java zijn syntactische suiker om snel lijsten te manipuleren, en tuples, dictionairy's zoals ze in bijvoorbeeld Python zitten. Java voelt heel omslachtig aan wat dat betreft, veel code om weinig voor elkaar te krijgen. Java is een solide taal, maar voelt niet vernieuwend aan, en ik krijg het gevoel daardoor dat het een uitstervende taal is.

Tja, java is geen scripttaal, en zal dat ook nooit worden. Java blijft een programmeertaal waarbij je relatief veel regels code nodig hebt in vergelijking met Python, Perl, Ruby, Tcl/Tk, etc.

Daarom zijn er ook diverse andere scripttalen gemaakt die op de JVM draaien, met, zoals jij het noemt, syntactische suiker. Zoals groovy, rexx, JRuby (port van Ruby naar de JVM) of JPython (port van Python naar de JVM).

Persoonlijk heb ik het nooit als een dealbreaker ervaren dat Java geen snelle notaties heeft voor dictionairy;s, tuples en lijsten. Met de interfaces van de Collection classes heb je ook niet heel veel code nodig om een lijst te bewerken, om tuples te implementeren of om iets in een hashtable op te zoeken.

Met Java 8 (Lambda) zou er al een groot deel opgelost worden.

Java is een solide taal, maar voelt niet vernieuwend aan

Maar zoals elder opgemerkt, er is lange tijd (en nog steeds eigenlijk) de filosofie geweest dat je dingen beter in de library kan oplossen dan direct in de taal.

B.v. de @Asynchronous annotation had ook een language keyword kunnen worden, maar is als library feature geïmplementeerd.

Java is niet de enigste die dit doet. Ook Objective-C heeft een vrij minimale taal, maar juist een krachtige "standaard" library voor desktop en mobile development. (das dus Apple's library, strikt genomen niet Objective-C's standaard library, maar tegelijkertijd eigenlijk ook weer wel)

Smalltalk ging nog een stap verder. Die had nagenoeg GEEN language features en een absolute minimalistische syntax. Zelfs while loops waren een library feature!

Google Go. Speel ermee en je zal zien dat het heel fijn werkt.
Go is een combinatie van C en Pascal en heeft OO eigenschappen.
Het is cross platform (maar anders dan Java genereert het platform specifieke code). Het is vooral geörienteerd op server side ontwikkeling, maar je kan er in feite alles mee programmeren, net zoals in C++, alleen dan een heel stuk simpeler. Het ondersteund tevens concurrency, een soort van threading, maar dan ook weer een heel stuk simpeler. Het is nog maar een paar jaar oud, maar heeft heel veel potentieel.

Ik probeer op deze site heel vaak uit te leggen dat complexiteit in software een van de grootste problemen is. Met Go wordt dit een heel stuk weggenomen. Je bent bezig met programmeren, met het oplossen van problemen, niet met organiseren.

[Reactie gewijzigd door Anoniem: 505261 op 20 april 2013 13:12]

Het idee achter Java is/was dat je niet voor elk platform apart hoeft te compileren. Alhoewel de C/C++ source redelijk platform onafhankelijk is is er door diverse leverqncies weer veel aan toegevoegd. Als je dat gebruikt ben je de sigaar.

Ik heb zelf identieke source code gebruikt op Unix/Linux en windows systemen. De enige problemen waren dat de standaard (?!) libraries niet altijd dezelfde naam hebben. Dat moet je dus eenmalig dmv ifdefs voor de precompiler oplossen.

De precompiler macro's zijn natuurlijk heel krachtig. Maar in Go lossen ze processor / platform-specifieke code op een andere manier op, die ik eleganter vind (met losse files).

Een ander voordeel van Go is dat het statisch compileert. Dwz het compiled naar een executable met alle libraries erbij. Zaken als dll-hell zijn dan dus niet meer van toepassing en er is ook geen run-time liberary nodig.

HTML5/Javascript draait overal waar je een browser hebt. Je kan er zelfs crossplatform desktop applicaties mee maken met een Framework als Node-Webkit of TideSDK, zeker de moeite waard om eens te checken!

HTML5/Javascript draait overal waar je een browser hebt.

Ik snap je opmerkingen niet helemaal. Java draait voornamelijk op de server en genereert dus HTML5 en Javascript.

Sterker nog, de komende Java EE release (Java EE 7, die op het punt staat om uitgebracht te worden) heeft op heel erg veel punten expliciet support gekregen voor HTML 5.

Scala.

Draait gewoon op de JVM dus cross-platform, target ook gewoon 1.5 bytecode dus je hoeft niet 12 jaar te wachten voordat je het ook op WebSphere mag gebruiken.

Hoe C# zich verhoudt tot Java, zo verhoudt Scala zich weer tot C#, vind ik, qua language features. De Collections API is subliem. Goede type inference, het typt bijna als een scripttaal maar is volledig type-safe.

En voordat iedereen gaat roepen dat het "ingewikkeld" is: onzin. Echt onzin. Niet te vergelijken met C++ wat betreft ingewikkeldheid (heb ik ook voldoende ervaring mee).
Je hoeft niet voor elke scheet weer een class op te tuigen, danzij closures/lambdas, case classes en tuples.
Scala is wat mij betreft net zo geschikt voor de beginnende programmeur als bijvoorbeeld Python, maar dan type safe.
Scala wordt als functionele taal gezien ("moeilijk"), feit is dat de taal je weliswaar helpt als je daadwerkelijk functioneel wilt schrijven, maar op geen enkele manier dit verplicht.

[edit] oh ja en is volledig compatible met Java dus de overdaad aan libraries en frameworks blijft gewoon beschikbaar, en software gemaakt in Scala is eenvoudig bruikbaar te maken vanuit Java.

[Reactie gewijzigd door jtwalters op 20 april 2013 20:40]

Toch is ook Scala niet perfect. Verre van dat zelfs. Het toestaan van nagenoeg elk symbol voor names i.c.m. nagenoeg ongelimiteerde operator overloading kan enorm slecht leesbare "symbol heavy" code opleveren.

Gebrek aan tutorials, documentatie en goede tooling blijft ook een issue. Compiler support is eindelijk wat beter geworden laatste jaar (mag ook wel na (^(^@ 10 jaar), maar haalt het nog niet bij wat er voor Java is. Denk ook aan static code analyzers, profilers, etc.

Ook de focus van Typesafe op Scala als een coole taal maakt dat Odersky compleet lak heeft aan backwards compatibilteit. Leuk voor hem, en leuk voor hen die pronken met mooie stukjes code, maar iets minder leuk voor teams die een code base van velen 100k locs moeten beheren.

Juist omdat die Oderksy maar dingen blijft toevoegen en deprecaten kunnen tools en tutorials het gewoon niet bijhouden.

Zelfs mensen die wat vaker Scala gebruiken klagen dikwijls over de diverse implicit conversions. Op een gegeven moment worden dingen te magisch en is wat meer expliciete code veel beter voor de leesbaarheid.

Wil niet zeggen dat Scala geen interesante taal is, dat is het zeker wel, maar het heeft ook een boel nadelen die je op de koop toe moet nemen of manieren voor moet zoeken om omheen te werken, die je met Java wellicht niet had.

>Java is best een mooie programmeertaal, gestructureerd en strict, maar het mist gewoon features die andere talen wel hebben.

Java heeft ook features die andere talen niet hebben, en t.o.v. sommige talen die overloaded zijn met "language feature" heeft Java de killer feature van een goede performance.

Ooit wel eens een benchmark gezien van gedrochten als Python, Perl, Rubv en PHP t.o.v. Java? Daar zakt je broek van af. Das gewoon geen competitie meer. Dingen die Java in 2 seconden doet, duren rustig een minuut of meer in Python

Java was in den beginne een prima cross platform taal.
Tot men machine specifieke code er in ging stoppen. Weg cross platform.

Sinds wanneer? Java is in de loop der jaren echt niet minder cross platform geworden. Wat bedoel je met "machine specifieke code", de JNI API soms? Het is daarmee inderdaad mogelijk om native code direct aan te roepen en dus een applicatie te schrijven die niet cross-platform is, maar JNI zit al erg lang in Java en wordt relatief weinig gebruikt buiten de standaard libraries. Voor de meeste applicaties is het ook volkomen overbodig om JNI te gebruiken. Er zijn wel een klein aantal libraries die JNI gebruiken, maar die worden vaak geleverd met native binaries voor meerder platformen zodat juist het cross-platform voordeel behouden blijft(denk bijvoorbeeld aan Java libraries voor OpenGL die o.a. door het cross-platform Minecraft gebruikt worden).

Zonder JNI is het wel mogelijk om niet cross-platform Java te schrijven, maar dan moet je denken aan code die hardcoded references heeft naar paden op je filesystem (bijvoorbeeld "C:\Program Files", "/home/" of "/Library"), maar dat is met iedere cross-platform omgeving mogelijk. In Java zijn dat soort problemen vaak ook te omzeilen door gebruik van de standaard libraries, dus vaak zullen dit soort problemen eerder aan de programmeur liggen dan dat Java niet cross-platform zou zijn.

[Reactie gewijzigd door MetroidPrime op 20 april 2013 22:18]

Zonder JNI is het wel mogelijk om niet cross-platform Java te schrijven, maar dan moet je denken aan code die hardcoded references heeft naar paden op je filesystem (bijvoorbeeld "C:\Program Files", "/home/" of "/Library"), maar dat is met iedere cross-platform omgeving mogelijk. In Java zijn dat soort problemen vaak ook te omzeilen door gebruik van de standaard libraries

Behalve wanneer de standaard libraries het zelf verprutsen, natuurlijk.

Ik zie persoonlijk nog steeds heel veel voordelen in Java. Het is een handige programmeertaal en het is ondersteund op meerdere platformen. Ik ben nu bijvoorbeeld bezig met een applicatie voor Android en voor de desktop. Dankzij Java werkt een groot gedeelte van de code op Windows, Mac OS X, Linux en Android. Terwijl ik nog steeds gebruik kan maken van veel native UI elements bijvoorbeeld. Het scheelt mij dus heel erg veel werk. Buiten dat vind ik Java veel makkelijker dan iets als C++.

Ontopic: Ik zal zelf waarschijnlijk niet zon last hebben aangezien ik in ieder geval right op JRE 6. Daarvan ben ik tenminste zeker dat tenminste die versie wordt gedraaid op computers. De meeste computers die ik komen lopen zwaar achter op Java updates.

[Reactie gewijzigd door Marlinc op 20 april 2013 12:23]

Java is een prima taal alleen de ontwikkeling gaat te langzaam. Java 1.7 bracht nauwelijks vernieuwingen. Java 1.8 laat al tijden op zich wachten en nu de lijst met vernieuwingen is vrij gegeven is het alleen maar een grotere teleurstelling. Als je dan even naar de grote concurrent kijkt (.NET/C#) loopt deze toch erg uit. Ok, Java draait op dit moment op meer platformen maar met Mono, wat steeds minder op gewoon .NET achter loopt kom Java steeds meer in het gedrang. Nieuwe technieken in Java, zoals bijvoorbeeld een 'Parallel' equivalent zou Java een mooie boost geven!

.NET en C# worden enkel en volledig ondersteund door Microsoft onder WIndows, Mono is daarentegen wel crossplatform, maar loopt achter qua features op .NET en C#. Kortom, niet echt een crossplatform alternatief.

teleurstelling???

lees toch echt even dit door:


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

het is nu net precies waar ik wel op zat te wachten, mis niet echt veel meer.

Java is een prima taal alleen de ontwikkeling gaat te langzaam.

De ontwikkelingen voor Java-the-language gaan misschien niet zo snel, maar de Java Library en de Java Virtual Machine ontwikkelen zich sneller en beter dan de meeste andere platformen.

Je moet je ook afvragen of je ook inderdaad een sh*tload aan language features will. Des te meer van deze features, des te complexer de taal kan worden en des te meer wisselwerkingen je kunt hebben tussen diverse van dergelijke features.

Precies. Denk maar aan C++. Meer is lang niet altijd beter.

If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one?
— Tom Cargill

Och, en jij gebruikt liever een non-crossplatform systeem zoals .NET zeker... Om alleen maar mee te werken met het monopolie huis van Microsoft !!!

Nee, Crossplatform moeten we motiveren. Is goed voor concurrentie en breed bereikbaarheid van programma's op verschillende platformen. Want dan wint gewoon de beste.... en niet die met een monopolie (microsoft dus).

Als je puur naar de taal kijkt, dan is denk ik C# toch de betere taal. Generics, parallel en asynchrone processing, LINQ, ... zijn features die de taal echt vooruit helpen. Het kan een keuze zijn om niet een taal te willen die voornamelijk gebruikt wordt op Microsoft, maar als de beste taal wint, dan verwacht ik dat het C# zal zijn.

Overigens is het prima mogelijk om C# te programmeren voor iOS, Mac, Linux of Android door middel van Xamarin of Mono.

Ik ben blij dat Java bedacht is, want anders had C# er ook heel anders uitgezien. De enige die echt achterblijft is Apple met zijn antieke Objective-C.

De enige die echt achterblijft is Apple met zijn antieke Objective-C

De Objective-C(++) ontwikkeling staat zeker niet stil!

Een aantal nieuwe features die de laatste jaren zijn geintroduceerd:

Properties
Fast enumeration
Lambda's
Closures (blocks)
Garbage Collection (deprecated in OSX 10.8, opgevolgd door ARC )
ARC (Automatic Reference Counting)
Synthesized property accessors.
Dot syntax voor properties.
Literal syntax voor NSNumber, NSArray en NSDictionary
Subscripting syntax voor NSArray en NSDictionary.
C++11 ondersteuning in Objective-C++

Wat de ontwikkeling van programmeertalen betreft, ik denk dat we de komende jaren steeds meer zullen horen van functionele programeertalen als Scala en Erlang.

[Reactie gewijzigd door Carbon op 20 april 2013 17:19]

Wat de ontwikkeling van programmeertalen betreft, ik denk dat we de komende jaren steeds meer zullen horen van functionele programeertalen als Scala en Erlang

Scala is GEEN functionele programmeer taal, maar een hybride taal met een aantal functionele elementen (net zoals C# dat nu al heeft, en Java met JDK 8 gaat krijgen).

Vergeet niet dat Scala al 10 jaar bestaat, en in al die tijd nog steeds weinig meer is dan wat ruis in de statistieken.

Hoeveel Scala vragen zijn er gesteld op Stackoverflow? Ga maar eens kijken. Hoeveel zijn dat voor Java, C# of Objective-C?

Oei! Dat is schrikken he?

Hoeveel jobs zijn er beschikbaar in Scala bij indeed.com? Ga maar eens kijken. Hoeveel zijn dat voor Java, C# of Objective-C?

Oei! Dat is weer schrikken he?

Hoeveel open source projecten zijn er beschikbaar in Scala op Github? Ga maar eens kijken. Hoeveel zijn dat voor Java, C# of Objective-C?

Oei! Dat is nogmaals schrikken he?

Op welke plaats staat Scala op Tiobe? Ga maar eens kijken. En welke plaats is dat voor Java, C# of Objective-C?

Oei! Het blijft maar schrikken he?

[Reactie gewijzigd door flowerp op 20 april 2013 21:02]

Scala is GEEN functionele programmeer taal, maar een hybride taal met een aantal functionele elementen

Klopt, maar het moge duidelijk zijn dat ik doelde op de functional programming features van Scala.

met een aantal functionele elementen (net zoals C# dat nu al heeft, en Java met JDK 8 gaat krijgen).

Scala gaat wel wat verder dan een aantal functionele elementen en is in dat opzicht niet vergelijkbaar met C# en Java 8.
Het hybride karakter maakt Scala alleen maar toegangelijker voor m.n. Java ontwikkelaars, maar het is ook een zwakte want het dwingt functional programming niet af.

Vergeet niet dat Scala al 10 jaar bestaat, en in al die tijd nog steeds weinig meer is dan wat ruis in de statistieken.

De leeftijd zegt helemaal niets, praktijk voorbeeld is wel Objective-C (30 jaar oud) waarvan bijna 20 jaar niets meer dan ruis in de statistieken, en nu staat het op de 4e plaats.

Hoeveel jobs zijn er beschikbaar in Scala bij indeed.com?

Indeed.com is een slecht voorbeeld.

Vacatures genoeg maar voornamelijk in het buitenland.

Voorbeeld de UK: Scala Jobs
Je ziet daar meteen nog een voordeel van een minder populaire programmeertaal, het betaalt beter

Maar er zijn ook bedrijven in Nederlands die Scala gebruiken en regelmatig vacatures hebben.

Oei! Dat is schrikken he?

Waarom? Ik doe een voorspelling, nergens beweer ik dat Scala (of Erlang) NU populair is.
Feit is dat talen als Scala en Erlang de laatste 2 jaar in polulariteit zijn gestegen.

btw Tiobe is maar één van de vele Language Popularity Index sites.

RedMonk Programming Language Rankings

The Rise and Fall of Languages in 2012

Oei! Dat is schrikken he?

[Reactie gewijzigd door Carbon op 20 april 2013 23:32]

De leeftijd zegt helemaal niets, praktijk voorbeeld is wel Objective-C (30 jaar oud) waarvan bijna 20 jaar niets meer dan ruis in de statistieken, en nu staat het op de 4e plaats.

Klopt, maar dit voorbeeld is niet zo super handig voor degene die beweren dat Java ingehaald zal worden door talen met meer en meer moderne language features, want Objective-C is kariger en ouderwetser dan Java. Zie ook b.v. de mening van John Siracusa op dit punt.

Objective-C ligt ook veel dichter bij Java dan veel mensen denken, en dus ook een argument VOOR de blijvende populariteit van Java.

De enige reden dat Objective-C 20 jaar ruis was en opeens als een raket naar boven schoot is natuurlijk de iPhone en het gesloten systeem van Apple. Ik ben zeker ook een fan van Objective-C, maar iedereen weet dat Objective-C NIET omhoog schoot omdat men zomaar opeens ontdekte wat voor heerlijke en productieve taal het was.

Maar er zijn ook bedrijven in Nederlands die Scala gebruiken en regelmatig vacatures hebben.

Ze schijnen te bestaan, en ik ken er zelfs eentje van, maar om met je eigen woorden te spreken; het is weinig meer dan ruis in de statistieken.

Feit is dat talen als Scala en Erlang de laatste 2 jaar in polulariteit zijn gestegen.

Het is relatief makkelijker om van 8000 naar 16000 gebruikers te gaan dan van 8 miljoen naar 16 miljoen gebruikers.

The Rise and Fall of Languages in 2012

Oei! Dat is schrikken he?

Ik snap hem niet helemaal. Wat moet die link bewijzen dan? Het article, steunt juist het standpunt dat Java een hoge positie blijft innemen:

Java, year over year, is effectively unchanged during the last three years. It is holds either the #1 or #2 (behind C) spot in all major language surveys.

De huidige top van de talen is C, Java, C++, Objective C en C#. Er zijn zoals gezegd tal van alternatieve talen, maar behalve veel geblaat is er nog geen enkele andere taal dominant geworden.

In 2006 zou b.v. Ruby het helemaal gaan worden. Waar is Ruby nu? In 2011 zou opeens Scala het helemaal gaan worden, maar was dat vanwege Scala zelf waar al 8 jaar bijna geen hond naar keek, of omdat er opeens een bedrijf kwam genaamd Typesafe dat nogal hard ging lopen schreeuwen?

Scala, Clojure, Python, F#, Xtend, Ceylon, Kotlin, ze beweren allemaal -de- Next Thing te zijn, maar jaar naar jaar gebeurd er bar weinig.

Er bestaat niet zoiets als de beste programmeertaal. De zwakste schakel is altijd de programmeur. C# is echt niet geschikter als programmeertaal dan Java voor het schrijven van kwalitatief hoogwaardige software. C# is gestart als Microsoft's eigen min-of-meer kopie van Java, en voegt als taal echt niet veel toe.

Bovendien zijn er nog een ziljoen andere programmeertalen dan Java en C#. Groovy is bijvoorbeeld een prima programmeertaal waarin veel taalfeatures aanwezig zijn die nu voor Java worden aangekondigd, en is ook crossplatform omdat het gebruik maakt van de JVM.

Tenslotte, als Objective-C daadwerkelijk zo antiek is als je beweerd, dan vind ik het toch wel opmerkelijk dat heel veel programmeurs weinig moeite hebben met het programmeren van bijzonder leuke en goede applicaties voor iOS en Mac OS X.

Er zijn genoeg websites en applicaties die aan de serverkant met Java werken. Daarnaast wordt Java maar al te vaak gebruikt op mobiele platforms (bijv. Android of het wat oudere Symbian). Sommige mediaspelers werken ook m.b.v. Java.

Op een standaard desktop (beetje browsen en zo nu en dan een documentje typen of een spelletje spelen) zal Java ook niet gemist worden. Ook OpenOffice / LibreOffice kunnen draaien zonder jre.

Naar mijn mening dan ook wat kort door de bocht om alleen naar de browser plug-in te kijken.

Volgens mij hebben die ook een JRE nodig, alleen wordt die gebundeld...

"Ik heb voor exact 1 website Java nodig"

Java != Java Applets.

[Reactie gewijzigd door nlinzweden op 20 april 2013 17:37]

Aan de server kant wordt heel veel met Java gedaan. Oracle's eigen SOA (service oriented architecture) bv is volledig Java gebaseerd. Voor de Ora dabased heb je ook eenn JVM nodig!

Er zijn ook tools die Java genereren om gebruik te maken van de platform onafhankelijkheid.

Dat je Jave op je PC niet veel gebruikt doet daar niets aan af.

Java wordt voor meer gebruikt dan enkel applets hoor.. In welke taal denk je dat bv Android apps geprogrammeerd worden?

Wist je dat veel websites op Java draaien? Bijvoorbeeld V&D, Praxis en Gamma. Ze hebben geen Java applet ge-embed op de site, maar op de achtergrond is de website in Java geschreven en spuugt de webserver HTML uit.

Nou, dan kan Oracle wel stoppen met Java, want dat is natuurlijk de enige reden waarom Java bestaat.

Java wordt op meer gebruikt dan enkel op TV's, vele spelers (Blu ray en dergelijke) draaien eveneens op Java.

Dus als ze stoppen ermee, dan zouden ze moeten uitkijken naar een andere taal

Java wordt op meer gebruikt dan enkel op TV's, vele spelers (Blu ray en dergelijke) draaien eveneens op Java.

Ik heb het gevoel dat johnkeates' opmerking enigszins sarcastisch bedoeld was.

Applets zijn nog maar een heel erg klein toepassingsgebied voor Java.

Het overgrote gedeelte van Java draait op de server en wordt daar enorm veel gebruikt. ZO veel zelfs dat Java tot op de dag van vandaag nog steeds als -de- of tenminste 1 van de meest gebruikte programmeer talen is.

Bij mij op stage is het ook de meest gebruikte taal en de core business is software leveren. Verder is Java best wel een fijne programmeer taal! Veel open source API's maken het ook aantrekkelijk(er).

Ontopic:
Ik hoop dat het uitstellen daadwerkelijk ook zorgt voor het vinden van beveiliginslekken. Gezien alle meldingen van de afgelopen tijd heeft het Java niet bepaald een goed imago gegeven. Dus dat mag/kan/moet Oracle beter doen.

Op m'n werk gebruiken we de Oracle ERP suite, en die doet het echt niet zonder Java. Dus voorlopig kan ik nog niet zonder...

Daarnaast gebruik ik JAlbum om een foto-album op m'n website bij te houden, en dat programma is ook Java-gebaseerd.

Waar draait je smartphone dan op?

Java wordt vooral gebruikt aan de serverkant. Er zijn heel veel applicaties die als achterkant java hebben. Bovendien zijn een aantal grote open source search projecten in Java geschreven, zoals Lucene, Hadoop etc.

Java wordt vooral gebruikt aan de serverkant.

Java wordt ook veel gebruikt voor embedded toepassingen

Ik vind de gang van zaken gewoon erg sneu. De hele vertraging is opgelopen omdat dat deel van Java wat 15 jaar geleden al verwijderd had moeten worden uit het platform onder vuur genomen werd door een hele grote groep mensen die er weinig tot niets van begrijpen. Ik wil als correcte gebruiker van Java (enterprise developer) vooruit verdikke, en dat wordt nu steeds verder naar achteren geduwd op deze manier.

Dat deel van Java werd niet onder vuur genomen, het was een Zwitserse gatenkaas. Gewoon door het bezoeken van websites kon je al geïnfecteerd raken. M'n pc werd een keer zelfs geïnfecteerd met een bootsector virus ondanks dat Kasperski draaide.

[Reactie gewijzigd door Anoniem: 505261 op 21 april 2013 11:23]

Tja, je kunt nu eenmaal geen risico lopen met iets wat client-side draait vanaf een website, ik vind het dus goed dat ze de boel uitstellen om de nodige fixes aan te brengen.

Het is wel weer in de trant van: Vanwege eerdere foute beslissingen moet er nu een hoop worden aangepast, maar dat blijf je houden met grootschalige projecten met een aardige looptijd.

Er worden ook een heleboel gaten gevonden waarvan je aan de ene kant kunt denken: Zie je, er klopt niks van! Maar aan de andere kant wordt er dan ook weer een hoop gefixt.

Het nadeel is dat ondanks de irritante Java Update Scheduler Jantje en Pietje toch vaak met oudere versies zitten.

Volgens mij staat er een foutje in het bericht met betrekking tot Project Lambda. Dit project is bedoeld om Java te voorzien van lambda expressies, zodat functies zelf objecten zijn en meegegeven kunnen worden aan methodes. Veel andere talen hebben dit al, maar Java zal het nu dus ook krijgen.

Volgens mij staat er nergens een fout hoor?

" Lambda expressions (and closures) are a popular feature of many modern programming languages. Amongst the different reasons for this, the most pressing one for the Java platform is that they make it easier to distribute processing of collections over multiple threads. Currently, lists and sets are typically processed by client code obtaining an iterator from the collection, then using that to iterate over its elements and process each in turn. If the processing of different elements is to proceed in parallel, it is the responsibility of the client code, not the collection, to organise this. "

bron: http://www.lambdafaq.org/...ions-being-added-to-java/

Ik ben het met rainmaker2k eens; de beschrijving in het artikel is behoorlijk misleidend. Closures zijn anonieme functies die toegang hebben tot de locale variabelen van de methode waarin ze worden gedefinieerd. De functionaliteit van closures biedt Java al lang, in de vorm van "anonymous inner classes". Die zijn echter behoorlijk veel typwerk en daarom onhandig. Maar die multicore-aanpassingen aan Java's Collections Framework zou je in principe ook daarmee kunnen doen; met closures wordt het echter eleganter.

In ieder geval jammer dat het uitgesteld is, want Java mist op het moment wel een mooie high-level multithreading-bibliotheek, zoals Threading Building Blocks voor C++ of Grand Central Dispatch voor Objective C.

Grand Central Dispatch voor Objective C.

GCD heeft een C API en is bruikbaar in C,C++,Objective C en Objective C++.

Vooral de combinatie GCD en closures vereenvoudigd de implementatie van multithreaded code enorm, en de leesbaarheid gaat er met sprongen op vooruit.

[Reactie gewijzigd door Carbon op 20 april 2013 17:19]

In ieder geval jammer dat het uitgesteld is, want Java mist op het moment wel een mooie high-level multithreading-bibliotheek, zoals Threading Building Blocks voor C++ of Grand Central Dispatch voor Objective C.

Java heeft Fork/Join wat vrij high level is, en erg veel en uitgebreide(high-level) concurrency primitives heeft.

Met lambdas zullen deze wel enorm veel makkelijker in het gebruik worden, en daarom is concurrency ook aangeduid als de main driver van Project Lambda.

Beide toevoegingen zijn interessant. Maar in de praktijk kun je daar wel omheen werken ook al kost het wat meer tijd om zelf te implementeren of dat de code iets makkelijker leest.

Maar voor Java zelf lijkt het me toch wel wat belangrijker op het moment dat ze zoveel mogelijk aan hun reputatie mvt veiligheid gaan werken. Want een taal met extra features die minder gebruikt wordt lijkt me niet handig.
Java mag dan opgekocht zijn door Oracle maar heel veel van hun produkten gebruikt Java onder de motorkap dus ze hebben er alle belang bij dat het zo veilig mogelijk wordt gemaakt.
En al die duizende software produkten die gemaakt zijn met Java of er op leunen hebben op dit moment waarschijnlijk ook wel meer belang bij een consolidatie ronde. (Dus ook de Pricewatch?)
Ook voor .Net/C# platform is Java ook belangrijk omdat het elkaars concurrent is en elkaar aanwakkert om te blijven innoveren.

Voor een spel zoals Minecraft zouden de nieuwe features juist weer meer helpen waar daar zijn performance blocks voor Minecraft servers waar betere multicore/multithreading ondersteuning juist handig is.

tja, lamba expressies, leuke feature, maar maakt code vaak wel een heel stuk onduidelijker helaas...

Hangt een beetje van het gebied af. Alles met alleen maar lambdas gaan doen schiet niet op nee, maar voor wat simpele expressies in map/reduce pipelines kan het erg handig zijn.

Ben zelf niet zo'n fan van Java, maar gebruik het stiekem toch nog vaak. Ik gebruik veel applets en als ik 's ga klooien met programmeren doe ik het altijd met Java.

Helaas zit ik nog aan Java 1.6 vast tot Google Android een keer Java 7 compatible maakt.