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 , , 55 reacties
Submitter: terje7601

Oracle heeft Java SE 7 uitgebracht. Java SE 7 biedt onder andere ondersteuning voor dynamische scripttalen zoals Ruby. Ook is er een nieuwe api voor bestandsbewerkingen en is er betere ondersteuning voor multicores.

JavaZoals verwacht is Java Standard Edition 7 donderdag uitgebracht. Een bètaversie en een release candidate waren al langer beschikbaar. Java SE 7 introduceert onder andere ondersteuning voor dynamische scripttalen zoals Ruby. Deze talen konden weliswaar al langer worden gebruikt in de Java Virtual Machine, maar met Java SE 7 presteren deze niet-Java-talen beter.

Ook bevat Java SE 7 een nieuwe api voor bestandsbewerkingen, die snellere toegang tot het bestandssysteem mogelijk moet maken, evenals betere ondersteuning voor processors met meer dan één core. Java SE 7 kent daarnaast een aantal nieuwe features. Het is de eerste grote Java-update sinds eind 2006.

Expertpanellid Misja Alma noemt de nieuwe versie van Java een 'versie die vooral erg lang op zich heeft laten wachten en die maar een beperkt aantal verbeteringen meebrengt'. Collega-panellid en -ontwikkelaar Jan Willem Harmelink noemt de verbeteringen 'niet wereldschokkend, maar zeer welkom'. "Ik ga ze in de nabije toekomst veel gebruiken", aldus Harmelink. Wel tekent hij aan dat Oracle veel geplande features naar versie 8 heeft doorgeschoven.

Moderatie-faq Wijzig weergave

Reacties (55)

Uwe Schindler (bron)en Hossman (bron) waarschuwen voor enkele kritieke bugs in de default configuratie zitten en dat je daarom beter nog geen gebruik van Java 7 kunt maken....

Deze bugs hebben te maken met hoe omgegaan wordt met loops in de Java-code.
Iemand die hier meer vanaf weet?
Er zit een bug in de optimalisatie van bepaalde loops (dus niet alle!).
Vooral Lucene (of alleen?) heeft er last van. Dan wordt het gedeeltelijk uitgevoerd.

Zoals in het commentaar van jouw links ook staat:

Als je met Java6 de opstart parameters -XX:+OptimizeStringConcat of -XX:+AggressiveOpts meegeeft, dan krijg je hetzelfde effect.
Verschil is dat deze opties onder Java7 standaard "aan" staan ipv "uit" onder Java6.

Het schijnt in de volgende update opgelost te worden.
Misschien is het zelfs met opstart parameter -XX:-OptimizeStringConcat -XX:-AggressiveOpts op te lossen.


Daarbij is het meestal niet slim om direct over te stappen naar deze release voor je productie omgeving. Als je nu ermee begint te ontwikkelen zal het wel opgelost zijn als je eenmaal 'klaar' bent met je programma.
Misschien is het zelfs met opstart parameter -XX:-OptimizeStringConcat -XX:-AggressiveOpts op te lossen.
Het is met -XX:-UseLoopPredicate op te lossen.
Zoals vermeld in eerste bron van Mr. P lijkt het opgelost te worden voor u2 niet u1, dus 2 updates wachten voor oa mij en de mijnen.
Eindelijk kan je een switch gebruiken op basis van een string object :)
We hebben er maar 15 16 jaar op moeten wachten :D
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=1223179

[Reactie gewijzigd door IStealYourGun op 29 juli 2011 15:26]

De reden daarachter was dat de switch in Java een gegarandeerde snelheid had. Die snelheid kon niet gegarandeerd worden met het switchen op strings omdat dat door de compiler gewoon omgezet werd in een reeks if statements.

Of ze nu deze garantie hebben laten varen of een uitzondering voor het switchen op strings hebben toegevoegd of een andere manier hebben gevonden om het switchen op strings efficient genoeg te maken om deze garantie te kunnen behouden weet ik niet. :)

--edit--
Link naar uitleg:
http://stackoverflow.com/...ngs-in-java/338230#338230

[Reactie gewijzigd door Daeron op 29 juli 2011 15:41]

Dat klopt niet helemaal volgens mij: een switch had al geen gegarandeerde snelheid. Hij wordt mogelijk al omgezet naar een binaire zoekoperatie door de compiler. Wat het artikel zegt, is dat een string switch in sommige gevallen niet sneller is dan een if operatie (of de snelheid is moeilijk te bepalen).
Gegarandeerde snelheid lijkt me ook een ongelukkig begrip voor een taal die op primitieve mobiele telefoons tot supercomputers gebruikt wordt. Een garantie op het maximale aantal operaties (processorinstructies) is natuurlijk wel te geven, ook in het geval van binair zoeken. Stel dat je n cases hebt, dan heb je hooguit k log n operaties nodig wanneer je binair zoeken gebruikt, waarbij k één of andere (kleine) constante is. Als je op de naieve manier door alles heenwalst, zul je hooguit kn operaties nodig hebben. En als je een lookup table gebruikt kun je het in hooguit k operaties doen. Volgens de link van Daeron gebruikt Java zowel binair zoeken als lookups, afhankelijk van de density van de cases (een case-list als [6,7,9,10,11,12] wordt met een lookup-table gedaan, terwijl iets als [5,100,534,1064] met binair zoeken wordt gedaan).

Strings zullen de boel voornamelijk in het geval van lookups compliceren, omdat je een string niet zomaar voor lookups kunt gebruiken - je zult hem dan eerst tot een integer moeten hashen en dan met buckets of iets dergelijks werken in het geval van collisions, waardoor je garantie inderdaad behoorlijk verwatert en je misschien performance problemen krijgt in het geval van kleine case-lists. De binary search zal overigens wel een vergelijkbare garantie houden (hoewel je de lengte van de langste case-string mee zult moeten nemen).
Waarschijnlijk is het gewoon syntactic sugar voor wat if else met jumps voor de fall throughs.
Ik vind het echt een onzin-feature in een taal die enums kent. Als je een gelimiteerde set Strings hebt waar je op wilt reageren, heb je per definitie een enum. Gebruik die dan ook, in plaats van Strings (ongetwijfeld weer geprogrammeerd als lelijke static finals -- hoop ik dan maar, want "losse" String-literals gebruik is sowieso vragen om problemen door type-fouten).

[Reactie gewijzigd door Herko_ter_Horst op 29 juli 2011 17:13]

En als je nou een een text file loopt te parsen waarbij je bij een aantal waarden een andere actie wil verrichten, wat leest dan makkelijker.

if(value.equals("aa")) {
//
} else if(value.equals("bb")) (etc etc)


of gewoon
switch(value)
{
case "aa":
//
break;
case "bb":
//
break; //etc etc
}

Smaken verschillen maar ik vind een switch over het algemeen makkelijker te lezen dan een reeks if/else if/else, en het ontbreken van een break ook leesbaarder dan telkens herhalen of je value toevallig .equal is tot waarde 1 of 2.. dan moet je de elke .equals afgaan om te kijken of er toevallig niet 1 keer een andere waarde voor de punt staat, bij de switch weet je dat om een enkele waarde gaat.
Ik vind het in ieder geval een nuttige toevoeging, kan komen omdat ik talen gewend ben die het wel ondersteunen en dus ook automatisch geneigd ben er gebruik van te maken.
Daarom zeg ik ook: gebruik een enum: daar kun je op switchen. En je hebt gelijk type-checking, alle mogelijkheden van classes etc.

Losse String-waardes zijn zowel semantisch als functioneel arm. Enums rule :)
Bij het parsen krijg je nu eenmaal vaak strings binnen. Denk bijvoorbeeld aan het parsen van argumenten of kijken welke XML tag je voor je kiezen hebt gekregen. Switchen op strings is soms handig, maar zoals zoveel dingen moet je het niet misbruiken voor de verkeerde dingen...
Helemaal mee eens, was in mijn geval ook het parsen van (comma seperated) text files.
Als je de strings zelf genereerd is het inderdaad vrij nutteloos. Als je echter strings aangeleverd krijgt zou je die volgens jouw redenering eerst moeten omzetten in een enum wat nogal omslachtig is imo (met een stel if statements kijken naar welke enum je hem moet omzetten? :+ ) Er zijn genoeg situaties waar dit best wel handig kan zijn hoor.
Je moet toch weten hoe je waarop gaat reageren?

Stringwaardes die je binnen krijgt kun je prima omzetten naar een enum via Enum.valueOf(). Vervolgens kun je switchen op de enum-waardes.

Java kan prima zonder dit soort meuk.
Dan ben ik heel benieuwd hoe jij een argument als 'ignore-case' zou willen parsen. Lijkt me niet dat die voldoet aan de regels van een identifier.

In het enum geval krijg je ook dubbele definities. Eerst enum definieren en daarna in een ander stuk code vergelijken met die enum. Je moet ook nog de exceptie afvangen als de 'Enum.valueOf()' mislukt.

Een eenvoudige if-regel met een string is dan toch wel een stukje onderhoudbaarder. Denk niet dat we samen aan een project moeten gaan werken. :)
Je begrijpt me verkeerd: iedereen doet nu lyrisch over switchen op Strings. Daarvoor zou ik een enum gebruiken (wat al sinds Java 5 bestaat).

Ik zeg helemaal niet dat een enum een vervanging is voor if/then statements op het moment dat je Strings niet uit een vaste set komen.
Als je met een switch wilt gaan checken op een paar strings, heb je blijkbaar al te maken met een vaste collectie Strings. Er zullen vast uitzonderingen zijn die de code leesbaarder maken oid, maar over het algemeen ben je dan naar mijn mening automatisch al verplicht een enum te gebruiken in een geval als dit, als je tenminste de java-regels volgt (coding standards). Als je die beperkte collectie Strings op deze plek gebruikt is de kans ook nog eens groot dat je diezelfde waardes ook nog ergens anders gebruikt of in de toekomst zal gaan gebruiken. Je wilt toch graag dat zo'n vaste collectie waardes waarop gecheckt wordt consistent blijft.

[Reactie gewijzigd door ravenamp op 30 juli 2011 12:08]

Functioneel gezien voegt het uiteraard niks toe (met een if/else if/else kom je er ook) maar voor de leesbaarheid van code toch wel een kleine overwinning. Nu nog maar eens zien wanneer we het ook daadwerkelijk kunnen gebruiken want het zal wel even duren voordat iedereen weer up to date.

* Xthemes.us was met een C# achtergrond toch wel stom verbaasd toen m'n string switch in java niet werkte ;)
Yeey *bouwt feesie!!* Ik hoor me leraar nog zeggen: "Dat is een verborgen functionaliteit in Java".
hehe.. herinner me nog les met leerkracht die het voor de eerste keer gaf..

Hoe?? dat gaat niet :D
Enum gemaakt en aan de hand van dat dan gebruikt..

:p
Ik zag de volgende problemen voorbij komen met betrekking tot loop "optimization". Early adopters wees gewaarschuwd!
http://markmail.org/thread/kulrw4sm2nsshrta

[Reactie gewijzigd door Stubby op 29 juli 2011 15:29]

Ik denk dat het verstandig is geweest van Oracle om niet te wachten tot alle features klaar zijn, maar gewoon te releasen wat af is, en door te schuiven wat nog niet af is. Release often, release early.
Daar zijn bedrijven over het algemeen niet zo happig op. Elke update wordt meestal uitgebreid getest voordat die uitgerold wordt richting de werkstations in het bedrijf. Als je vaak updates doet moeten bedrijven ook vaker gaan testen, kost meer geld en dan zijn ze eerder geneigd om naar een alternatief over te stappen wat niet zo vaak geupdate wordt en daardoor minder kost. :)

Kijk maar bv naar de klaagzang op het feit dat Mozilla overstapt op dit principe. Een hoop bedrijven zijn nu aan het kijken naar de opties om terug te gaan naar MSIE.
Tsja, Linux is met dat principe wel groot geworden, dus er valt wel wat voor te zeggen. En gezien de lange, lange tijd tussen Java 6 en 7 zit er denk ik wel genoeg tijd tussen major releases bij Sun/Oracle. Al had dat ongetwijfeld wel te maken met de financiele problemen van Sun, voor de overname.
Kijk eens naar de relese cycles van de grote commerciële distributies zoals Red Hat of Suse, die houden helemaal dat principe niet aan net omdat bedrijven dat niet wensen. En als er beveiligingsporblemen zijn dan zullen deze distributies de patches daarvoor vaak backporten in plaats van de nieuwste versie van een pakket op te nemen.
Mwah zoveel kernel updates heb je toch ook weer niet? (of zie ik dat helemaal verkeerd?)

Mjaah het grote verschil is natuurlijk dat Linux vrij modulair is waardoor je de kernel kan updaten terwijl de rest niet veranderd hoeft te worden. (schat ik zo in)
Deze vergelijking gaat wat mij betreft een beetje mank. Het grote probleem bij firefox is dat oude versies geen security updates e.d. meer krijgen. Om de 3 maanden komt er ook een nieuwe linux kernel uit, maar zelfs de 2.4.x lijn wordt nog ondersteund. Het gaat meer om de ondersteuning van oude versies dan over het tempo van het uitkomen van nieuwe. Bij firefox is het vooral de ondersteuning van oude versies die nu op de schop is gegooid.
Bij iets als een programmeertaal kun je dat niet zomaar doen ... 1 kleine bug, kan al snel grote gevolgen hebben voor veel applicaties die in Java geschreven worden. Vooral zaken die te maken hebben met de syntax van Java moeten goed doordacht worden. 1 kleine denk fout en je zit er voor eeuwig mee. Een programmeertaal kan niet zomaar een feature gaan aanpassen omdat de uitwerking slecht was.
Meer omdat de vorige versie uit 2006 is!
Het lijkt hierdoor wel of alle andere talen sneller gaan (incl. .NET)

Als jij een release in de 5 jaar "often" vindt ;)
Ik dacht dat Microsoft vreemde specificaties eisen had maar Oracle spant hier de kroon!

Lees de systeem specificaties een van Java 7.. http://jdk7.java.net/JDK7SupportedSystemConfigurations.html

En wat schetst mij verbazing:
- SuSE Enterprise Linux (with Java 7): Not Supported on Oracle VM
- Ubuntu (with Java 7): Not Supported on Oracle VM
Kennelijk wat problemen onder hun motorkap..

Maar het beste komt nog:
- VMware and Microsoft Hypervisor are not supported.

Kijken of Citrix boos word omdat ze ook niet op de lijst staan met Xenserver.

Soms is het gewoon weer even genieten om te zien wat Oracle weer probeert.. :+ .

[Reactie gewijzigd door rorydeleur op 29 juli 2011 15:54]

Lezen is ook een kunst. Het gaat erom dat er geen officiele support is voor het draaien van een Oracle Virtual Machine (niet te verwarren met de Java Virtual Machine) die Ubuntu (en sommige andere distro's) virtualiseert die op zijn beurt de Java Virtual Machine draait. Het is dus niet zo dat je Java 7 niet kunt draaien op Ubuntu.
De soep zal wel niet zo heet gegeten worden.

Voor een eerste release snap ik nog wel dat ze ipv allerlei Linuxen half te testen, 1 Linux distro (Red Hat) goed hebben getest en ook supporten, en de rest later nog komt. Idem met de hypervisors, ze hebben blijkbaar eerst de native implementaties robuust gemaakt en als extra Oracle's eigen hypervisor, en breiden later de support pas uit naar de grote jongens in de virtualisatie wereld.

[Reactie gewijzigd door Dreamvoid op 29 juli 2011 17:02]

Blijft toch behelpen zonder Linq, Lambda's, TPL en async.

Ik vind het raar dat een Java zo ver achterop raakt vergeleken met .Net. Zou het dan echt zo moeilijk zijn om dit soort features uit te rollen? MS schijnt er een stuk minder moeite mee te hebben.

Paar keer dingen in Java moeten doen dan was ik toch erg blij dat ik weer terug mocht naar .Net.
Ik zie het probleem niet echt. Voor alle dingen die je noemt zijn prima community backed alternatieven te vinden voor Java.
MS schijnt er een stuk minder moeite mee te hebben.
Geen kwestie van moeite; Het ecosysteem van dergelijke API's bij Java is totaal onvergelijkbaar met dat van MS.

Java drijft veel meer op community projecten om de taal/base platform heen. Zo zou je bijvoorbeeld als je Linq achtige functionaliteit in Java wilt een project als LambdaJ kunnen gebruiken: http://code.google.com/p/lambdaj/ . Dit is geen onderdeel van het base Java platform en kan daardoor op zijn eigen tempo (meestal veel sneller) evalueren dan de rest van het platform. Daarnaast zullen er ongetwijfeld nog een hele sloot aan alternatieven voor LambdaJ zijn.

Bij .net is er een partij in Redmond welke het totale ecosysteem bepaalt van API's en dit in het platform stopt.

Als je niet zit te wachten op keuze moet je zeker niet voor Java gaan.

[Reactie gewijzigd door JUDGExKTF op 29 juli 2011 18:25]

Ik vind het raar dat een Java zo ver achterop raakt vergeleken met .Net. Zou het dan echt zo moeilijk zijn om dit soort features uit te rollen?
Is het echt zo moeilijk te bedenken dat de switch van Sun naar Oracle de oorzaak is van het gat in vooruitgang? Niets raars aan, heel begrijpelijk zelfs. Vervelend, maar begrijpelijk.

Op gebied van architectuur loopt het Java platform nog prima mee overigens, het is enkel de taal wat ondergeschikt is nu en daar zijn de jongere JVM talen voor om dat gat op te vangen. Zoek bijvoorbeeld naar de taal "Ceylon" in ontwikkeling bij JBoss / Red Hat.

Iig, nu gaat de bal weer rollen en dat is mooi.
Volgens mij is dit 1 van de weinig dingen waar Oracle het juist niet 'verprutst'. Ook onder SUN lag de java vooruitgang al jaren op zijn gat. JavaFX zou het helemaal worden.. ze doen er alleen zolang over dat een groot deel van de mensen ondertussen al niet eens meer de moeite neemt om de JVM te installeren, welke veelgebruikte pakketten gebruiken het immers?
Azureus(nu Vuze)? uTorrent is toch iets populairder tegenwoordig.
Applets? Die kom ik helemaal nooit tegen, zowel javascript (en in het verlengde daarvan HTML5) en flash vervullen deze rol al tijden.
OpenOffice? nou niet echt super veel gebruikt (en trouwens ook optioneel, OpenOffice draait ook zonder Java en start dan zelfs sneller op maar moet dan wel enkele functies missen.
Eclipse/Netbeans? Enkel developers die het gebruiken.
de switch van Sun naar Oracle de oorzaak is van het gat in vooruitgang
De ontwikkeling lag al veel eerder op zijn gat, juist na de overname door Oracle zit er weer een beetje schot in omdat er weer geld in gestoken kan worden en Oracle de knoop doorgehakt heeft om te releasen wat werkt en uit te stellen wat nog niet werkt - Sun heeft de boel eindeloos laten uitlopen, mede door geldgebrek. Je kan niet alles oplossen door er veel geld tegenaan te gooien, maar het houdt wel de vaart erin (zie .NET en Obj-C/Cocoa).

[Reactie gewijzigd door Dreamvoid op 29 juli 2011 23:09]

Java werkt overal. .Net werkt alleen bij MS. Daar zit al 1 probleem, en ook een 2e probleem: MS zegt wat je wel of niet mag, bij Java kan je kiezen. (Maar het hoef niet perse).

Al die language-specifics zijn leuk voor mensen die in die taal zitten, maar zijn echt niet totaal afwezig in andere talen hoor. Zoals hier vaker gepost kan je van die oplossingen als Linkq en Lambda prima in andere talen als bibliotheken terugvinden en gebruiken.

Als je een programmeur bent die alleen maar kan werken in een taal en niet in wat er verder op de wereld bestaat is er iets met oogkleppen ofzo ;)
Java werkt overal. .Net werkt alleen bij MS.
En OS X, de Silverlight client op OS X is erg goed. En Mono mag je porten waarheen je wilt, daar heeft MS in principe niks over te zeggen, of je bouwt je eigen VM. Microsoft publiceert de specs, en wat mensen aan implementaties bouwen mogen ze zelf weten. Daarin is het niet anders dan Java.

[Reactie gewijzigd door Dreamvoid op 30 juli 2011 13:07]

En Mono mag je porten waarheen je wilt, daar heeft MS in principe niks over te zeggen, of je bouwt je eigen VM.
In de praktijk is mono niet compatible genoeg met de Microsoft .net implementatie. Het feit dat er een porting guide is zegt genoeg: http://www.mono-project.c...ing_Winforms_Applications . Feitelijk zou je als je iets in VS gecompiled hebt gewoon het op een andere implementatie moeten kunnen draaien.
Microsoft publiceert de spec
Van de taal ja (C#), maar niet van alles van het platform zoals bij Java het geval is. Ik kan bijvoorbeeld de specificatie van Linq nergens vinden.
Blijft toch behelpen zonder Linq, Lambda's, TPL en async.
async - in Java EE 6 zit de @Asynchronous annotation.
Waar komt die onzin over 'betere ondersteuning voor multicore' vandaan? Java beschikt al jaren over goed werkende en goed schalende multithreading dat prima werkt op multicore en multiprocessor systemen.
Java 7 brengt een nieuw fork/join framework waar mee sommige oplossingen voor parallelisatieproblemen makkelijker geïmplementeerd kunnen worden.

@gimbal: grapjas :+

[Reactie gewijzigd door Remus op 29 juli 2011 19:54]

Mooi man, een framework waar je problemen mee implementeert in plaats van oplost ;)
Gezien de hoeveelheid bugs die je vaak ziet in multithreaded/concurrent/parallele code klopt mijn opmerking ook; ik heb hem toch maar even aangepast :P
Bijna schaamteloos letterlijk een copy van dit bericht (aankondiging hiervan) ?

Da's makkelijk "nieuws maken".... }:O

[Reactie gewijzigd door IoorLTD op 29 juli 2011 15:38]

Dat is ook door de auteur van dit bericht, Joost Schellevis, geschreven. Eigen werk hergebruiken lijkt me niet zo kwalijk :)
Jullie kunnen het wegmodden maar het viel mij ook op.
Citeren uit eigen werk is normaal geen probleem maar of het dan nog in de nieuws sectie past? Ik zou toch hopen dat er in de tussentijd wel wat meer over te zeggen zou zijn...
Heeft JAVA al een fatsoenlijk systeem als LINQ?
Binnenkort maar eens testen of de Java applicaties op het werk hier mee te draaien zijn.

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