Oracle toont nieuwe versies Java-software

Oracle heeft op OpenWorld nieuwe versies van Java SE, EE en FX gepresenteerd. Java FX 2.0 is zelfs direct al te downloaden; Java SE 8 komt in 2013. Het is nog onbekend wanneer Java EE 7 wordt uitgegeven.

Oracle, dat Java na de overname van Sun in handen kreeg, toonde op OpenWorld onder andere Java FX 2.0, dat per direct beschikbaar is. De nieuwe versie van Java FX, dat een tegenhanger van Adobe Flash en Microsoft Silverlight zou moeten zijn, is beschikbaar voor Windows en OS X.

Java FX 2.0 voegt onder meer ondersteuning voor andere scriptingtalen toe, zoals Groovy, JRuby en Scala. De nieuwe web-renderengine van Java FX is gebaseerd op Webkit en ook is er ondersteuning voor de xml-opmaaktaal fxml.

Java Standard Edition 8 krijgt onder andere de beschikking over ondersteuning voor lambda-expressies en betere ondersteuning voor multicore-cpu's. Ook moet het makkelijker worden om applicaties te packagen. Bovendien biedt Java SE 8 waarschijnlijk ondersteuning voor multitouch-apparaten.

Ontwikkelaars moeten in 2013 met de nieuwe versie van Java SE aan de slag kunnen. In het tweede kwartaal van 2012 kunnen developers overigens aan de slag met de OS X-versie van Java SE 7. Java SE is vooral bedoeld voor lokale applicaties. Voor serversoftware is er nog Java Enterprise Edition, waarvan de eerstvolgende release versienummer 7 draagt. De nieuwe Java EE 7-versie wordt waarschijnlijk voorzien van een twintigtal nieuwe en bijgewerkte api's.

Reacties (44)

[Verwijderd]

Ik vraag me af hoelang JavaFX nog in de lucht blijft.

JavaFX moest destijds Java toegankelijker maken voor webdesigners e.d. door middel van een nieuwe scripting taal (kracht van de JVM simpel aan wenden). Volgens mij zorgde dit er meer voor dat de Java ontwikelaars het ontweken (ik zat in ieder geval niet te wachten om weer een nieuwe scripting taal te leren) en bij webdesigners e.d. is het ook nooit aangeslagen. Persoonlijk ken ik niemand die ermee werkt. Kan ook niet heel veel cijfers vinden over het gebruik van JavaFX.

De nieuwe web-renderengine van Java FX is gebaseerd op Webkit

Zou het "missing in action" JWebPane component in deze release zitten ? Dat zou mooi zijn.

Java SE is vooral bedoeld voor lokale applicaties.

Wieso ? Java SE is gewoon standaard Java. Als je Spring met bijvoorbeeld OSGi gebruikt gebruik je ook enkel Java SE. Er zijn legio server applicaties die geen Java EE gebruiken maar enkel Java SE.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 22:17]

[Verwijderd]

FX 1.x werd niet bijster veel gebruikt idd. Maar de scripttaal die daarvoor gebruikt werd is als een Google project door gegaan.
FX 2 kan iig als opvolger van Swing gebruikt worden dus in die zin heeft het zeker nut. Wat dat betreft is het een welkome verbetering op de 'antieke' GUI elementen van Java. Alleen jammer dat er nog geen Linux versie is.
Overigens is ontwerpen in FX2 nogal spartaans want zover ik weet is er nog geen WYSIWYG editor beschikbaar. Wellicht dat je met fxml (wat toch wel redelijk op adobe action script lijkt) wat makkelijker kan ontwikkelen. Want in vergelijk met Flash of Silverlight loopt het op dat vlak nog wel achter en is de ontwikkeltijd hoger dan je zou willen. Potentie heeft het wel zeker.

[Dreamvoid]

Potentie wel, maar ik ben bang dat het hele concept met platformonafhankelijke ontwikkeling met de opkomst van iOS, Android en WP7 een beetje voorbij is. Er is geen enkel crossplatform framework dat op al deze Ossen draait. Het ziet er naar uit dat de toekomst gewoon weer back-to-native is (en als fallback, websites).

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 22:17]

[SchizoDuckie]

Java wordt gewoon gecrushed door HTML5. Ik develop as we speak (onderdelen van) webapps die draaien in je browser, op je telefoon, op je tablet of op je tv. En nog een half jaartje en dan draaien mijn apps ook in als windows 8 app.

De kracht imo is niet het willen maken van 1 allesomvattend plat form wat alles doet, maar het combineren van native en HTML5.

[Reactie gewijzigd door SchizoDuckie op 23 juli 2024 22:17]

[Remus]

Aangezien Java voornamelijk serverside gebruikt wordt en je daar dus bar weinig hebt aan HTML5 zie ik niet helemaal in hoe Java daardoor gecrushed zou kunnen worden.

[BugBoy]

WPF/Silverlight kent wel een WYSIWYG editor (Blend of VS2010), maar als het allemaal complexer wordt, dan zit je toch al gauw te kijken naar de rauwe XAML code. Ik werk ruim 4 jaar met Silverlight/WPF en onderhand heb ik Blend vaarwel gezegd en in VS2010 staat de WYSIWYG editor default uit. Leuk voor eenvoudige templates, maar voor een complexere applicatie niet echt bruikbaar...

[Cobalt]

JavaFX 1.x was best wel relax. Nu met JavaFX 2.x zijn ze terug gegaan naar normale Java syntax. Met Java SE 8 is het de bedoeling dat JavaFX geintergreerd wordt met Java SE.

JavaFX is qua engine niet gebaseerd op Webkit hooguit wellicht het format van fxml.

[Reactie gewijzigd door Cobalt op 23 juli 2024 22:17]

[YopY]

Ikzelf zie weinig toekomst meer in Java zelf (als programmeertaal); misschien leuk als je een 100% Java-tent bent en je legacy software moet updaten oid, maar als je een beetje hip bent ga je al gauw kijken naar andere programmeertalen.

Op de JVM heb je bijvoorbeeld talen als Clojure, Groovy en Scala, die elk hun eigen aanpak hebben. Ikzelf heb weinig ervaring met Clojure en Groovy, maar Scala is eigenlijk het antwoord op de langzame ontwikkeling van Java. Het is ontwikkeld door de persoon die verantwoordelijk is voor generics in Java, en combineert OO met functionele paradigma's om zo een krachtige combinatie te vormen. (Mogelijk zelfs té krachtig, de syntax en de vele opties zullen veel mensen intimideren. Het heeft zeker een veel hogere leercurve dan Java zelf).

[erikdenv]

Hip? Welk groot bedrijf wil er nu hip zijn?

Als bank, verzekeraar of overheidsinstelling zoek je naar proven technology.
Betrouwbaarheid, robuustheid, veiligheid en beschikbaarheid van personeel zijn veel belangrijker dan hip.

De hippe talen leunen trouwens op de VM van Java. Die moet ook onderhouden worden.

[iain]

ik denk dat @YopY zich ongelukkig uitdrukt met het woord 'hip'. Het grote voordelen van de nieuwere talen, al dan niet op de JVM, is dat ze bepaalde problemen beter en sneller kunnen oplossen dan Java. En hoewel zaken als betrouwbaarheid, en beschikbaarheid van personeel erg belangrijk zijn, zijn productiviteit en performance ook erg belangrijk.

Zelfs voor banken, verzekeraars en overheid, want die leven ook in een snel veranderende maatschappij waarin er liever gisteren dan vandaag uitgerold moet worden.

En als het niveau van programmeurs voor bijv. Clojure hoger is dan voor Java, maakt het dan nog uit dat er meer Java programmeurs zijn? Beter goed dan veel toch?

Het is geen probleem als Java de kant van Assembly en C op gaat: De taal waarin andere talen gemaakt worden.

[Verwijderd]

Ikzelf zie weinig toekomst meer in Java zelf (als programmeertaal); misschien leuk als je een 100% Java-tent bent en je legacy software moet updaten oid,

Wat denk je dat alle 'hippe' web 2.0 tenten zoals Hyves, Twitter, LinkedIn, Facebook, etc. in de backend allemaal draaien ? Ruby ? Groovy ? Nee natuurlijk niet; Java. Kijk even naar dit lijstje van partijen die Apache Hadoop gebruiken: http://wiki.apache.org/hadoop/PoweredBy en denk nog even na over je eerdere statement.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 22:17]

[SlasZ]

Waarom zouden bedrijven willen in investeren in die nieuwe talen zoals scala waar de leercurve en complexiteit hoger ligt dan Java? De kosten zullen veel hoger zijn zowel door hogere salarissen, moeilijker te onderhouden etc. Java is perfect voor veel bedrijfssoftware en ik zie dit niet veranderen in de komende 5-10 jaar. Bestaande Java bedrifssoftware zal al helemaal niet veranderen naar andere talen tenzij Java ondersteuning plots verdwijnt.

[CT]

hip? zoals android?

[Verwijderd]

nee, zoals iphone!

*zet helm op, duikt schuilkelder in*

[BugBoy]

De iPhone is een leuke telefoon en was zeer vernieuwend toen die op de markt kwam. Helaas kan voor de ontwikkelomgeving en het onderliggende raamwerk niet hetzelfde gezegd worden. Objective C stamt echt uit het stenen tijdperk... Android ken ik niet, maar dat heeft Windows Phone 7 in ieder geval voor op de iPhone. Helaas maakt het de eindgebruiker alleen niets uit...

[Dreamvoid]

Het heeft zeker een veel hogere leercurve dan Java zelf

Misschien, maar de trend is eerder de andere kant op: van Java weg naar makkelijkere talen als Javascript.

[-=bas=-]

*Proest*
Als je denkt dat Javascript makkelijker is dan Java dan heb je nog een hoop te leren....

[Leejjon]

Voor simpele dingen zoals ajax calls, dingen in de dom aanpassen (waar volgens mij javascript voor bedoelt is) is javascript heel makkelijk.

Voor ingewikkelde dingen zoals games wordt het moeilijker omdat javascript minder kan, niet zo zeer omdat de taal zelf moeilijk is.

[Verwijderd]

o.O Ik denk dat je beter even naleest wat de toepassingen zijn van zowel java als javascript

[Tjeerd]

Even op zitten zoeken, maar een lambda expression klonk interessanter voor mij dan het is eigenlijk; het is niets anders dan een closure. Dat laatste gebruikte ik al een tijdje in Groovy. Sowieso heb ik wel eens gelezen dat een van de Sun-ontwikkelaars een hoop eigenschappen die in Groovy zitten, graag veel eerder al in Java had willen zien zitten.

[Dreamvoid]

Een hoop dingen hadden eerder gemoeten, maar in de laatste jaren van Sun was er niet zoveel geld meer. Nu onder Oracle kan het gaspedaal weer worden ingetrapt.

[Remus]

Correcter is om te zeggen dat een closure niets anders is dan een lambda expression. Deze term bestaat namelijk al langer dan de term closure.

[boner]

En nu hopen dat het beter gesteld is met de compatibiliteit met oudere versies dan vroeger.

[Spockz]

Pardon? Dat is juist waarom ze zo'n lange tijd achter hebben gelopen en er nog steeds bugs in zitten. Ik zou zeggen, breek die backwards compatibilteit van de VM maar gewoon lekker en ga met een schone lei verder.

[Verwijderd]

Ik zou zeggen, breek die backwards compatibilteit van de VM maar gewoon lekker en ga met een schone lei verder.

Amen ! Generics zou zoveel beter kunnen in Java als ze niet vast gehouden hadden aan backwards compatibility. Wellicht dat dit in de toekomst nog een keer gebeurt maar ik betwijfel het.

Moet ook wel bijgezegd worden dat een hoop dingen ook wel gefixed kunnen worden zonder backwards compatability te breken. java.util.Date bijvoorbeeld is opzich goed gefixed in JSR-310.

[latka]

En zo backwards compatible is het ook weer niet: je kunt code met generics nooit draaien op een 1.4 JDK ondanks dat het hele generics via type-erasure uit de code verwijderd wordt. Moet je of met retro-weaver aan de slag om het werkend te krijgen.

[erikdenv]

Hoe kom je daar nu bij? Het hele Generics gebeuren is een compileraangelegenheid.
de bytecode is niet anders onder 1.5 dan onder 1.4.
Dat is ook de zwakte van het backwards compatible willen blijven.
Je kunt nu een externe module (jar) aanroepen die jouw meegeven ArrayList<String> als een normale ArrayList ziet met alleen objecten van het type Object. De externe module voegt zonder problemen een Integer toe aan jouw ArrayList en geeft deze terug. Weg is je type safety.

[tibi]

bovendien is backwards compatible niet dat 1.5 code op een 1.4 jdk maar net andersom.

als je weet dat je app ook onder oude code moet kunnen draaien moet je het ook in die versie bouwen.

[Cobalt]

Java SE 1.4 en 5.0 EOL.

[Robtimus]

Het probleem daarmee is dat je dan meteen elke library of applicatie die je gebruikt opnieuw zult moeten compilen omdat ze niet meer werken met je nieuwe JRE.

[acemoo]

Ik verwacht niet dat ze dat gaan doen bij Java.
Bij python hebben ze tussen versie 2 en 3 ook geen backwards compatibiliteit gemaakt en dit is de reden ook dat er nog heel weinig python3 library's zijn.
en dat is dan weer de reden dat er weinig python3 programma's zijn.

Arch linux draait standaart python3 maar als je ook maar iets wil moet je python2 al weer installeren.

[Titan_Fox]

Compatibiliteit is nooit een echt probleem geweest in mijn ervaring. Waar ik me meer zorgen om maak is het risico van deze software. JAVA is altijd erg gevoelig geweest voor security-issues net als vrijwel alle software van Adobe (Reader, Flash, Shockwave, AIR etc.).

[Bigs]

Ik denk niet dat boner het heeft over Java applets in websites, maar over Java SE of EE applicaties. Java als taal is niet bijzonder gevoelig voor security issues.

[Remus]

Kan je dat onderbouwen? Als je je als ontwikkelaar aan de API hield (en dus niet classes uit de interne sun.* of com.sun.* packages direct gebruikte aangezien die *niet* tot de API behoren) heb je bijna nooit problemen om je software op nieuwere versies van Java te draaien. Een van de weinige uitzonderingen daarop die ik ken, is als met implementaties van interfaces of abstract classes die worden uitgebreid met extra methodes (wat bijvoorbeeld met bijvoorbeeld JDBC nog weleens wil gebeuren).

[Verwijderd]

zolang men aan Java 1.x werkt zal deze backward compatible blijven - mogelijk zal dit wijzigen eens men aan 2.0 begint.. maar daar is nog geen woord over gerept dus

[BugBoy]

Humor... Voor een omschrijving lambda expressies wordt naar de website van .NET gelinked

Het verbaasd me dat Java toch in veel aspecten enorm achterloopt op C#. Generics is in C# net wat eleganter uitgevoerd (typesafe over assemblies heen) en lambda expressies bestaan ook al een hele tijd in .NET. Vooral in combinatie met LINQ een geweldige uitbreiding. De enige pré van Java vind ik eigenlijk alleen nog dat het minder platform gebonden is (Mono vind ik eigenlijk een beetje een doodlopend verhaal). Ook de exceptie handling vind ik net wat sjieker in Java.

Voor generics moest MS de binary compatibility met .NET v1.x assemblies breken i.t.t. Java, maar dat was het wel waard.

[jj71]

Het verbaasd me dat Java toch in veel aspecten enorm achterloopt op C#.

Er heeft inderdaad een groot gat gezeten tussen Java 6 (december 2006) en Java 7 (eind juli 2011). Dat komt onder andere doordat het slecht ging met Sun, waardoor ze geen risico's durfden te nemen door veel tijd en geld in de ontwikkeling van de volgende versie van Java te steken. Nu Oracle, een financieel enorm sterk en gezond bedrijf, het heeft overgenomen zit er gelukkig weer beweging in de ontwikkeling van Java.

Maar allerlei spectaculaire nieuwe features toevoegen in een programmeertaal gaat niet zomaar, zeker als er al miljarden regels code zijn geschreven in die taal en alles compatible moet blijven met al die bestaande code. Daarom is men heel zorgvuldig met het bedenken van hoe nieuwe features zoals lambda expressions moeten worden ingepast, en dat kost gewoon veel tijd.

Bovendien is de focus voor de programmeertaal Java om een stabiele, goed werkende basis te zijn, en juist niet om heel innovatief te zijn met allerlei experimentele nieuwe features. Als je dat wilt, dan zijn er tegenwoordig heel veel alternatieve programmeertalen voor de JVM om eens naar te kijken: Scala, Clojure, Groovy, JRuby enz.

[Reactie gewijzigd door jj71 op 23 juli 2024 22:17]

[jj71]

Java FX, dat een tegenhanger van Adobe Flash en Microsoft Silverlight zou moeten zijn,

Volgens mij is dat idee allang weer losgelaten. Met de eerste versie van JavaFX werd het inderdaad gepresenteerd als een alternatief voor Flash en Silverlight, maar inmiddels is de scriptingtaal (JavaFX Script) in de prullenbak verdwenen en is het "gewoon" een grafische library met een Java API, meer bedoeld om de oude GUI toolkits AWT en Swing te vervangen.

[Jazco2nd]

Dus we hebben Java FX 2.0, Adobe AIR3, Sliverlight 4, Flash 11 en HTML5. Samen is dat 20!

Voor developers dus genoeg te kiezen!

[BugBoy]

Dat is nu juist het probleem. Vooral op het MS platform weet je niet meer wat je moet doen. Bij de introductie van .NET was het duidelijk. Winforms voor desktop applicaties en ASP.NET voor webapplicaties.

Het gerommel kwam pas echt toen WPF/Silverlight werden geïntroduceerd als the "next big thing". Voor desktop applicaties was WPF geweldig en in vrijwel alles superieur aan Winforms. Het is een prachtig framework, maar de leercurve is redelijk stijl. Maar MS laat WPF ook een beetje links liggen, want echte grote verbeteringen zijn er vrijwel niet meer geweest sinds de introductie. De enige grote WPF applicaties van MS zijn de ontwikkeltools Visual Studio en de Expression suite. Voor Windows 8 wordt er weer meer gehamerd op HTML5 en Silverlight. Gaat WPF verdwijnen? Niemand die het zeker weet...

Gelijk met WPF kwam ook Silverlight en daar zijn de ontwikkelingen harder gegaan en dat groeit steeds dichter naar WPF toe (maar nog steeds niet source-code compatible). Maar ook daar begint het te rommelen vanwege het hele HTML5 gebeuren. Allemaal leuk en aardig, maar HTML5 is eigenlijk nog niet volwassen genoeg om daar grootschalig applicaties in te bouwen.

Als je nu als bedrijf een raamwerk moet kiezen, dan is het verdomd lastig. Voor desktop applicaties lijkt WPF voorlopig de beste keuze, maar voor webapplicaties vind ik het een lastige keuze.

[Niemand_Anders]

Microsoft probeert jouw gewoon opties te bieden: Schrijf je je applicatie in Silverlight of HTML(5). In dat laatste wil je dan gebruik maken van webforms of MVC. Desktop development? Kun je kiezen uit WinForms of WPF. En de opties welke Microsoft in 1999 bood, kun je in VS2010 nog steeds gebruiken. Je toolkit is alleen een stuk groter geworden. Dat noem ik geen probleem, maar vooruitgang..

WPF is gewoon direct zeer goed neergezet als platform. In .NET 4.0 zijn nog wel een aantal namespaces toegevoegd voor interactiviteit, maar frameworks als Caliburn boden deze functionaliteit al eerder.

Silverlight is daarin tegen een heel ander verhaal. Als we even SL1 vergeten want die had eigenlijk niets met .NET te maken. SL2 is bewust door Microsoft klein in mogelijkheden gehouden zoals ze dat ook met Windows Phone hebben gedaan. Je kunt niet direct alles, maar de basis welke je wel hebt zit redelijk goed in elkaar. SL3 en SL4 hebben hetzelfde gegdaan als wat Mango voor WP deed, namelijk extra functionaliteit toevoegen.

Als bedrijf hoor je geen standaard raamwerk te kiezen. Je hoort als bedrijf de beste tools voor je project te kiezen! Frameworks als Caliburn Micro maken de brug tussen WPF, Silverlight en WP7 wel een stuk kleiner ondanks dat SL en WP een beperktere CLR kennen. Maar als je de meeste business code in WebServices of WCF services weet te stoppen, dan hoef je eigenlijk alleen maar je views aan te passen.

[jurgen67]

Samen is dat 25!

[The Eagle]

Net even wat voorbeelden gekeken op cloud.oracle.com
Eerste reactie

Sure, ziet er best gelikt uit, maar de interface is identiek aan die van Oracle Support zo op het eerste gezicht. En da's 1 brok flash
Dat betekent dat je als Enterprise organisatie Flash moet gaan toestaan op al je webbrowsers inclusief beveiliging en andere ellende. Plus up to date houden. Om nog maar te zwijgen van de dramatische performance.

Het initiatief juich ik zeker toe, maar komop, Oracle heeft wel mooiere technieken in huis dan dit.