Sun geeft preview van Javafx vrij

Sun heeft donderdag een preview gepubliceerd van Javafx. Met deze programmeeromgeving hoopt Sun een gedeelte van de markt voor rich internetapplicaties voor zich op te eisen.

Als ontwikkelomgeving staat Java natuurlijk al jaren op de kaart. Voor de toenemend populaire ria's moet Sun echter Flash van Adobe en sinds kort Silverlight van Microsoft laten voorgaan. In een tijd waarin de grens tussen desktop- en internetapplicaties steeds verder vervaagt, kan Sun het zich echter niet veroorloven zijn concurrenten een te grote voorsprong te laten nemen.

Op het Javaone-evenement kondige Sun de komst van Javafx aan en inmiddels is er een preview van de sdk te downloaden. Deze sdk bestaat uit het framework, een compiler, versie 6.1 van de NetBeans-ide en uitgebreide documentatie en voorbeelden. Ook is er een versie van Project Nile bij de sdk ingesloten. Deze software omvat een aantal plugins voor Illustrator en Photoshop waarmee grafische ontwerpen eenvoudig geëxporteerd kunnen worden, zodat ze in Javafx kunnen worden gebruikt. De sdk is gedurende 60 dagen te gebruiken.

Het Javafx-platform beschikt over verschillende runtimes waaronder een voor de desktop, een voor mobiele applicaties en een voor tv-achtige apparaten. De desktopversie zal in het najaar van dit jaar beschikbaar zijn terwijl tot de lente van 2009 op de mobiele versie gewacht moet worden. De tv-versie is pas in de loop van 2010 te krijgen.

Reacties (58)

[klaafstra99]

Ligt het aan mij, of is JAVA op zich in vergelijking tot de andere alternatieven erg resource-intensief?

Als daar geen verbetering in is gekomen, laat ik het voor wat het is.

[bozotheclown]

Dat java in jouw beleving langzaam is zegt niks over javafx natuurlijk. Javascript en ajax zijn ook op java gebaseerd en retesnel.
Daar komt bij dat die zogenaamde slechte performance van java nogal relatief is want de torrent client vuze (azureus). Start bij mij toch echt gewoon heel snel op.

[pegox]

Javascript en ajax zijn helemaal niet java gebaseerd. Ze hebben helemaal niks met java gemeen, enkel de naam.

Javascript is een scripting taal ontworpen door netscape (als ik me niet vergis) in de tijd dat java populair werd. Netscape heeft zijn scripting taal dan javascript genoemd om van de aandacht die java kreeg gebruik te maken. Maar op technisch gebied hebben javascript en java helemaal niks met mekaar gemeen.

[Little Penguin]

Maar op technisch gebied hebben javascript en java helemaal niks met mekaar gemeen.

Nou ja, bijna niets - toen men (Brendan Eich) bezig was met de ontwikkeling van JavaScript heeft men de syntaxis van JS afgestemd op die van Java.

Maar dat is dan ook één van de weinige dingen die de talen gemeen hebben - behalve de naam natuurlijk.

[bozotheclown]

Je hebt gelijk, het was een verkeerde aanname van me: http://nl.wikipedia.org/wiki/Javascript

[Verwijderd]

Java is to JavaScript what Car is to Carpet

[masterpoi]

Javascript heeft buiten (een beetje) syntax niks met java gemeen.

[Reactie gewijzigd door masterpoi op 23 juli 2024 21:59]

[MarCreative]

Ajax en Javascript zijn de zelfde script-talen met één verschil dat jij in Ajax een server-side aanroep doet naar een ander script bijvoorbeeld Perl of PHP.

De syntax van Java en Javascript zijn min of meer het zelfde maar eigenlijk ook weer niet. Dit komt gewoon door de C familie, net als Visual Basic weer van Basic komt (logisch maar toch).

[DJ Henk]

Ajax is helemaal geen taal, maar een methode waarmee javascript op een webpagina kan communiceren met de webserver zonder de pagina te herladen.

[Reactie gewijzigd door DJ Henk op 23 juli 2024 21:59]

[tweakerbee]

'Ajax' is een onzinterm die staat voor Asynchronous Javascript And XML.
In de browser zul je het nergens tegenkomen, die noemen het allemaal XHR (XML HTTP Request).

Ook die naam klopt eigenlijk niet helemaal, want je kunt ook prima stukken HTML of JSON terugsturen naar je script. Een betere naam zou AHR zijn (Asynchronous HTTP Request).

[Haan]

Buiten het feit dat wat je over javascript en ajax zegt grote onzin is, zegt 1 standalone Java applicatie die bij jou snel opstart natuurlijk absoluut niets over de performance van Java in het algemeen en nog minder over Java web applicaties

Java (net als .Net) maakt gebruikt van een tussenlaag (VM) en zal daarom minder performen dan bijvoorbeeld een C++ applicatie.

[Herko_ter_Horst]

Dit is een ouderwetse aanname die zeker niet zonder meer waar is. Door JIT (Just-in-Time) compilatie (in die VM laag) kan de applicatie namelijk runtime optimalisaties doorvoeren die in een statisch gecompileerde omgeving niet mogelijk zijn. Daardoor is het prima mogelijk met Java en .Net dezelfde, zo niet betere, performance te halen als in C++.

[bigbadbull]

Een precompiled applicatie zal altijd sneller zijn dan een JIT-applicatie.
Echter er is 1 grote eis: hij moet precompiled zijn voor dat systeem.
en we weten allemaal al lang dat er geen 1 windows systeem bestaat.

Dat is nu net de kracht van het JIT/VM systeem, de applicatie wordt voor jouw specifiek systeem gecompileerd en geoptimaliseerd.
Een klein nadeel hierbij is dat dit elke keer gebeurd, waardoor het wat langer duurt om op te starten, maar dat zou je moeten terug "verdienen" tijdens het werken.

Het verschil in snelheid hangt natuurlijk af van de complexiteit van de code en het gebruik van speciale commando's.

[masterpoi]

Om even te antwoorden met een quote:

The perception that managed applications are slow may be due to self-selection bias. That is, the programmers, most sensitive to performance and most adept at writing performant code, are also the least likeliest to migrate to managed code. The end result is that managed applications tend to be written by less performance-savvy programmers, who are more interested in the managed environment for other reasons like enhanced productivity.

http://wesnerm.blogs.com/...4/09/net_vs_native_p.html

[bozotheclown]

Natuurlijk zegt 1 applicatie niet bijster veel over de performance van java in het algemeen. Ik probeer aan te geven dat de algemene perceptie op de performance van java nogal achterhaald is.

Dat een browser een paar seconden hangt terwijl een java app aan het laden/just in time compilen? is, zegt meer over hoe er in het ontwerp van die browser en/of het os rekening gehouden is met threads en hoe het os die threads beheert cq. van een prioriteit voorziet. Right?

[ddofborg]

Ik weet het niet, hoor. Laten we als voorbeeld Eclipse nemen. Onder Windows draait Eclipse een stuk trager dan b.v. Visual Studio. Al is het het gevoel dat je hebt tijdens het gebruik van de applicaties.

Of bijvoorbeeld BitTorrent clients. Kun jij een Java client kan noemen die het even 'snel' doet als een native client. En dan heb ik het weer over het gevoel dat een applicatie aan jou geeft tijdens het gebruik.

[Reactie gewijzigd door ddofborg op 23 juli 2024 21:59]

[Verwijderd]

javascript is niet op java gebaseerd! De naam is destijds gekozen door netscape om mee te surfen op de java hype. De grootste concurrent voor flash silverscript en javafx zijn de open standaarden CSS, HTML, AJAX, XML en javascript. Deze werken op alle browsers en zonder plug-INS. Google maar eens op 'sproutcore'.

[Stephan Oudmaijer]

Is inmiddels al een stuk minder dan het voorheen was. Met de nieuwe Consumer JRE 6u10 zou het iig nog minder resources moeten opslurpen (initieel).

Een van de coolere features van deze nieuwe JRE vind ik nogwel dat je JavaFX enabled applets uit de webpagina naar je desktop kunt slepen. Zie hier een voorbeeldje: http://blogexpertease.alt...vafx-script-pour-lexemple

Ik vind het (als Java ontwikkelaar) persoonlijk wel spijtig dat het Sun tot op heden niet gelukt is om 100% goede integratie van de JVM met de browser te realiseren. Het komt nog veel te vaak voor dat bijvoorbeeld Firefox/IE gewoon helemaal hangt op het moment dat een Applet niet goed kan worden geladen. Dit zijn zaken waar je met een Flash/Silverlight plugin toch een stuk minder last van hebt.

[Reactie gewijzigd door Stephan Oudmaijer op 23 juli 2024 21:59]

[Brian]

Java wordt JIT, Just in Time, gecompileerd. Dit is natuurlijk meer resource intensief dan applicaties die al gecompileerd zijn.

[YopY]

Je reactie is niet helemaal compleet: Het wordt JIT gecompileerd, maar nadat een stukje naar native gecompileerd is draait het even snel, zo niet sneller dan een 'native' proces.

[Justice]

hoe kan iets sneller dan native draaien?

[Vaudtje]

Doordat de JIT compiler pas op het laatste moment compileert, kan hij daar runtime informatie bij gebruiken afkomstig uit het gedeelte dat al wel draait. Hiermee is theoretisch een betere optimalisatie mogelijk dan met compilatie van alleen broncode, bijvoorbeeld door code die vaker aangeroepen wordt aggressiever te optimaliseren.

[Madcat]

Sorry hoor maar wat je zegt is maar voor een klein deel waar, er is een handje vol functies die in java sneller zijn dan onder C/C++ maar de andere 99.9% wint C/C++ het echt wel hoor
pro Java: http://kano.net/javabench/data
pro C/C++: http://www.jelovic.com/articles/why_java_is_slow.htm

[Remus]

Beide artikelen zijn denk ik al zo'n 5-10 jaar oud, er is sindsdien al veel veranderd aan JIT optimalisatie en dergelijke. Ik denk niet dat die artikelen nog veel zeggen over de huidige stand van zaken.

[ACM]

Echter is de vergelijking met C en C++ in deze context totaal irrelevant.

Je moet het hier vergelijken met flash/actionscript en silverlight... En die worden beide ook in een vrij stevig afgeschermde sandbox uitgevoerd, en dan wijkt java op dat punt dus ineens niet meer af. Dan krijg je misschien zelfs een voordeel omdat de Java sandbox al veel verder doorontwikkeld is.

Maar zelfs in de server-wereld is het niet per se meer relevant. Sowieso kan en mag de server-versie van de JIT een stuk meer optimaliseren en verder zijn ontwikkeltijd en schaalbaarheid belangrijker dan absolute performance in die context.

[Verwijderd]

SWF9 wordt ook door een JIT compiler getrokken, vergelijkbaar met Java in dat geval.

[Remus]

Quote van http://msdn.microsoft.com/en-us/library/ms973838.aspx :

Myth: Garbage Collection Is Always Slower Than Doing It by Hand

Actually, until a collection is called, the GC is a lot faster than doing it by hand in C. This surprises a lot of people, so it's worth some explanation. First of all, notice that finding free space occurs in constant time. Since all free space is contiguous, the GC simply follows the pointer and checks to see if there's enough room. In C, a call to malloc() typically results in a search of a linked list of free blocks. This can be time consuming, especially if your heap is badly fragmented. To make matters worse, several implementations of the C run time lock the heap during this procedure. Once the memory is allocated or used, the list has to be updated. In a garbage-collected environment, allocation is free, and the memory is released during collection. More advanced programmers will reserve large blocks of memory, and handle allocation within that block themselves. The problem with this approach is that memory fragmentation becomes a huge problem for programmers, and it forces them to add a lot of memory-handling logic to their applications. In the end, a garbage collector doesn't add a lot of overhead. Allocation is as fast or faster, and compaction is handled automatically—freeing programmers to focus on their applications.

In the future, garbage collectors could perform other optimizations that make it even faster. Hot spot identification and better cache usage are possible, and can make enormous speed differences. A smarter GC could pack pages more efficiently, thereby minimizing the number of page fetches that occur during execution. All of these could make a garbage-collected environment faster than doing things by hand.

Een ander interessant (maar enigzins gedateerd) artikel is: http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

[johnbetonschaar]

En zo kan je ook wel weer 10 situaties verzinnen waarvoor bovenstaand stukje geen hout snijdt, bijvoorbeeld bij het gebruik van C++ pool allocators (die ruimschoots voorhanden zijn, bijvoorbeeld in Boost, en dus niet door de programmeur zelf gemaakt oeven te worden).

Feit is dat de allocatiestrategie en run-time karakteristieken van je software bepalend zijn voor de meest efficiente oplossing. Voor extreem multithreaded systemen met een hoge allocatiefrequentie kan garbage collection _veel_ sneller zijn dan handmatig (allocatie/de-allocatie overhead) of pool allocators (overmatige locking), voor laag-parallele applicaties met een hoge allocatiefrequentie zal een pool allocator sneller zijn, terwijl voor typische applicaties de 'ouderwetse' malloc/free/new/delete en RAII allocatiestrategie de beste performance zal geven. As memory allocation strategies go, there (also) is no silver bullet...

Zelfde geldt trouwens voor de discussie hierboven over native compilatie vs. JIT. Een goede JIT compiler zal hotspots kunnen ontdekken in je code en daar runtime allerlei fancy trucs op kunnen loslaten die een normale compiler niet kan doen. Maar als je code daar geen baat bij (bijvoorbeeld code die vrijwel alle tijd in tight inner loops spendeert en dus een bijna perfect voorspelbaar branching patroon heeft) dan verliest de JIT het heel dik van een statisch optimaliserende compiler. Ik zou in ieder geval geen codec willen schrijven in Java, maar wel een multithreaded server.

[Reactie gewijzigd door johnbetonschaar op 23 juli 2024 21:59]

[RayNbow]

Hier is een citaat uit een talk van Steve Yegge:

Here's one example. C is really fast, because among other things, the compiler can inline function calls. It's gonna use some heuristics, so it doesn't get too much code bloat, but if it sees a function call, it can inline it: it patches it right in, ok, because it knows the address at link time.

C++ — you've got your virtual method dispatch, which is what C++ you know, sort of evangelists, that's the first thing they go after, like in an interview, "tell me how a virtual method table works!" Right? Out of all the features in C++, they care a lot about that one, because it's the one they have to pay for at run time, and it drives them nuts! It drives them nuts because the compiler doesn't know, at run time, the receiver's type.

If you call foo.bar(), foo could be some class that C++ knows about, or it could be some class that got loaded in afterwards. And so it winds up — this polymorphism winds up meaning the compiler can compile both the caller and the callee, but it can't compile them together. So you get all the overhead of a function call. Plus, you know, the method lookup. Which is more than just the instructions involved. You're also blowing your instruction cache, and you're messing with all these, potentially, code optimizations that could be happening if it were one basic-block fall-through.

[...]

In particular, let me come back to my inlining example. Java inlines polymorphic methods! Now the simplest way to do it was actually invented here at Stanford by Googler Urs Hoelzle, who's, you know, like VP and Fellow there, and it's called, it's now called Polymorphic Inline Caching. He called it, uh, type-feedback compilation, I believe is what he called it. Great paper. And it scared everybody, apparently. The rumors on the mailing lists were that people were terrified of it, I mean it seems too hard. And if you look at it now, you're like, dang, that was a good idea.

All it is, I mean, I told you the compiler doesn't know the receiver type, right? But the thing is, in computing, I mean, heuristics work pretty well. The whole 80/20 rule and the Power Law apply pretty much unilaterally across the board. So you can make assumptions like: the first time through a loop, if a particular variable is a specific instance of a type, then it's probably going to be [the same type] on the remaining iterations of the loop. OK?

So what he [Urs] does, is he has these counters at hot spots in the code, in the VM. And they come in and they check the types of the arguments [or operands]. And they say, all right, it looks like a bunch of them appear to be class B, where we thought it might be class A.

So what we're gonna do is generate this fall-through code that says, all right, if it's a B – so they have to put the guard instruction in there; it has to be correct: it has to handle the case where they're wrong, OK? But they can make the guard instruction very, very fast, effectively one instruction, depending on how you do it. You can compare the address of the intended method, or you can maybe do a type-tag comparison. There are different ways to do it, but it's fast, and more importantly, if it's right, which it is 80-90% of the time, it falls through \[i.e., inlines the method for that type - Ed.], which means you maintain your processor pipeline and all that stuff.

So it means they have predicted the type of the receiver. They've successfully inlined that. I mean, you can do a whole bunch of branching, and they actually found out through some experimentation that you only need to do 2 to 4 of these, right, before the gain completely tails off. So you don't have to generate too much of this. And they've expanded on this idea now, for the last ten years.

Dit citaat geeft een specifiek voorbeeld hoe een JIT aan de hand van runtime informatie een methode-aanroep beter kan compileren.

[Reactie gewijzigd door RayNbow op 23 juli 2024 21:59]

[StiGMaTa]

Onmdat de JIT compiler optimalisaties kan doorvoeren die de native versie niet heeft (bv. single-core/multi-core , 32bit/64bit, ....)

[Verwijderd]

Java applicaties zijn niet langszamer dan applicaties die voor .net geschreven zijn. Omdat .net ook JIT gebruikt.
Java is (evenals .net) overigens wel langszamer dan gecompileerde programmas. Soms merkbaar, soms ook niet.

Azureus is dacht ik gecompileerd en wordt dus niet meer JIT uitgevoerd (maar dit weet ik niet 100% zeker).

Ik werk al een tijd met zware java applicaties en vind de snelheid over het algemeen erg goed. Het is alleen zeker geen taal om games in te bouwen. Maar dat is .net ook niet.

[Remus]

Dat valt allemaal heel erg mee. Het grootste probleem met Java is eigenlijk dat het voor een programmeur erg makkelijk is om het verkeerd te doen (langdurige handelingen op de eventthread uitvoeren ipv op een workerthread, waardoor de interface 'bevriest' ed).

Het is overigen Java, geen JAVA.

[Verwijderd]

En dat langdurige zaken uitvoeren op de event thread heb je met C/C++ niet? Wat je eigenlijk wil zeggen is dat de traagheid in Java niet aan de taal ligt, maar aan de programmeur en de eventuele bibliotheken die deze gebruikt.

Java wordt voornamenlijk gebruikt in server business applicaties met een web-front-end. Dit performed qua user experience in 99% van de gevallen niet, men heeft meestal een enorme lading geheugen nodig en de programmeurs die het programmeren gebruiken meestal meer dan 100 verschillende bibliotheken door elkaar die met zijn alleen aardig wat resources er door stoken. Het zijn allemaal negatieve effecten van de wens van bedrijven/managers om software snel/goedkoop te kunnen bouwen. Meestal zijn vergelijkbare applicaties kwa kostprijs niet compleet van de grond af aan op te bouwen en vertraagd een taal als C/C++ het hele traject ook nog eens. Zelf vind ik het jammer dat Java altijd op deze mannier naar voren is gebracht. Het eclipse project heeft hier enigszins veranderingen in gebracht. Hierdoor heeft Sun opeens meer moeten investeren in Swing en heeft deze ook een behoorlijke boost gekregen in performance. De Azureus GUI is bijvoorbeeld gebaseerd op de SWT library die onderdeel is van het eclipse project.

[Verwijderd]

Het grote probleem met de gebruikers beleving van Java als internet applet is nog altijd de enorme traagheid waarmee de applet geladen wordt. De gemiddelde browser blijft vaak 2 tot 3 seconden fors hangen voordat deze weer reageert. Is dat met Javafx opgelost?

[Het.Draakje]

Volgens mij is het grootste probleem van Java dat mensen het blijven verwarren met Java-script.

Java is niet traag (tenzij de applicatie door een beroerde programmeur in elkaar is geflanst).

[YopY]

Java is niet traag nee, maar Java applets hebben wel een tijdje nodig om op te starten. Het Java splash screen helpt daar overigens ook niet bij.

Een volgende versie van Java zou dit probleem gedeeltelijk op proberen te lossen, door alleen datgene dat ook daadwerkelijk gebruikt wordt in te laden, ipv alles.

[kluyze]

Je hebt gedeeltelijk gelijk.:
Een java programma moet meestal eerst ge-interpret of gecompileerd worden, wat een extra stap is tov andere talen. Dus in wezen zal het nooit even snel zijn als een stukje software dat even goed geschreven is in een andere taal. De verschillen zijn met de huidige computers misschien wat kleiner maar die extra stap bij het starten van het programma zal altijd aanwezig zijn.

Dit afgezien dat je waarschijnlijk ook java programma's volledig kan compileren maar dan is de grootste troef van de taal, de platform independancy, weg

Een taal is trouwens ook niet traag of snel, want wat geeft het verschil tussen 2 programma's die hetzelfde doen maar in een andere taal geschreven zijn? De snelheid van de programma's ligt in mijn ogen aan de compilers en in welke mate die een optimalisatie (kunnen) doen. In theorie kan een binaire file van de ene taal er identiek uitzien als die file uit een andere taal. Maar dat is maar mijn mening.

[Reactie gewijzigd door kluyze op 23 juli 2024 21:59]

[Cameleon73]

Dit probleem is opgelost in de 1.6.0_10 (nog te releasen) versie van Java. Daar hebben ze (eindelijk!) de applet gerelateerde zaken opnieuw opgezet. Hierdoor draait de applet niet meer in dezelfde thread als de browser (en zal de browser dus ook niet meer blijven hangen tijdens het laden).

[Verwijderd]

vergt deze technologie een extra plugin of kan gewoon de standaard jre gebruikt worden?
hoe zit het met de programmeertaal: is dat puur java of is het iets anders?

[Ansur]

Java-ish. Ze willen het wat toegankelijker om snel een GUI op te zetten.

Het eerste vorbeeldje dat ik tegenkwam is dit:

import javafx.ui.*;

Frame {
title: "Hello World JavaFX"
width: 200
height: 50
content: Label {
text: "Hello World"
}
visible: true
}

Als je dat naar java vertaalt zou het zoiets zijn:

import java.awt.Frame;
import java.awt.Label;

public class Test() {

public Test() {
final Frame frame = new Frame("Hello World Java");
frame.setSize(200, 50);

final Label l = new Label("Hello World");
frame.add(l);
frame.setVisible(true)
}

public static final void main(final String...args) {
new Test();
}

}

Dus het is wel iets beknopter

[Verwijderd]

hoe zo beknopter ?

import java.awt.*;
public class Test extends Frame {
public Test(String title) {
super(title);
setSize(200, 50);
add(new Label("Hello World"));
setVisible(true);
}
public static final void main(final String...args) {
new Test("Hello World Java");
}
}

[Donderwolk]

Adobe Flex, Microsoft Silverlight en JavaFX. Ben benieuwd of het javafx gebeuren gaat aanslaan. Feitelijk zijn het gewoon Java Applets die met behulp van javafx gemakkelijker in elkaar kunnen worden gezet. Voordeel van Java is dan weer dat het gratiz iz.

[Reactie gewijzigd door Donderwolk op 23 juli 2024 21:59]

[masterpoi]

De Silverlight en Flex sdks zijn ook gratis. Voor de design programma's (FlexBuilder en Blend) moet je betalen.

Is er al een designer voor JavaFX?

Ook is er een versie van Project Nile bij de sdk ingesloten. Deze software omvat een aantal plugins voor Illustrator en Photoshop waarmee grafische ontwerpen eenvoudig geëxporteerd kunnen worden, zodat ze in Javafx kunnen worden gebruikt.

En Adobe doet zover ik weet nog niet aan liefdadigheid door hun producten weg te schenken...

[Moraelyn]

Met dit design programma is Sun bezig en zal gratis worden:

A JavaFX Designer tool is planned for release in the future. The JavaFX Designer tool will provide a comprehensive visual design environment to allow designers to author rich, Internet-enabled content and applications without necessarily knowing the underlying JavaFX Script language or the specifics of the Java platform.

http://java.sun.com/javafx/faqs.jsp

[P_de_B]

Wat bedoel je met designer? Een tool om de grafische schil te ontwerpen (gebruik Project Nile icm Photoshop) of een omgeving om je code in te kloppen (gebruik de meegeleverde ide NetBeans)

[masterpoi]

Ik bedoel het programma gebruikt door de designer (een doorgaans minder technisch persoon die zich niet/minder met programmering bezig houdt.)

Wat ik dus wou zeggen is dat de tool om de meer professionele looks/designs te creëren ook in het geval van Sun niet gratis is.

Ttz. tot de JavaFX Designer uitkomt zoals Moraelyn al zegt.

[Verwijderd]

"En Adobe doet zover ik weet nog niet aan liefdadigheid door hun producten weg te schenken..."

De Flash Player is altijd al gratis geweest... De Flex SDK is bijv. gewoon gratis te downloaden (www.flex.org). Verder heeft Adobe tal van open source projecten (opensource.adobe.com) en hebben ze de Tamerin VM toch echt aan de Mozilla foundation geschonken.

Ja, het is een commerciele onderneming dus willen ze ook graag geld verdienen (niets mis mee). Daarom verkopen ze producten als Photoshop, Flex Builder, ColdFusion, Flash etc. Met de winst kunnen ze de andere (open source) projecten weer draaiende houden.

[Floort]

En Java is een open standaard inclusief goed werkende open source implementatie(s).

[Verwijderd]

Eigenlijk mis ik die grafische mogelijkheden bij java al vanaf het begin. Ik denk dat java er fors van had kunnen profiteren als er iets meer grafische functionaliteit aanwezig was geweest.

Maakt JavaFX ook gebruik van directx / opengl ?

[Ansur]

Denk het wel.

Vanaf de Java 6u10 update de deur uit is zal sowieso DirectX by default enabled zijn voor swing components (in windows anyway). Ze hebben daar best wel hard aan gewerkt, dus het lijkt me onlogisch om die effort niet te gebruiken voor JavaFX

[Verwijderd]

Wat in het artikel onderbelicht blijft is dat JavaFX naast concurrentie van Silverlight en Flex ook uit eigen hoek nog directere concurrentie heeft in de vorm van GWT (Google Web Toolkit) en Echo II. Beide toch echt Java-based RIA toolkits. Sun heeft (weer eens een keer) lopen slapen. Ben benieuwd of het nog gaat aanslaan, wat ik er tot nu toe van gezien heb lijkt verdacht veel op Flex3...

[Verwijderd]

Zeker een goed punt, maar niet echt een probleem. GWT en Echo zijn beide frameworks die op JavaScript gebaseerd zijn en niet in een runtime omgeving binnen de browser draaien (zoals JavaFX en Flex). Ondanks dat het programeermodel hierdoor een stuk eenvoudiger is dan wanneer je zelf aan de gang gaat met JavaScript / AJAX blijven de rendering mogelijkheden beperkt tot wat er met JavaScript mogelijk is. Daarnaast hebben beide frameworks ook als nadeel dat het lastig is om zelf componenten te maken, of heel erg af te wijken van de standaard look & feel. Dit betekend dat met een technologie die wel binnen een runtime omgeving draait, de mogelijkheden veel groter zijn.

Overigens is JavaFX niet alleen bedoelt om web applicaties te ontwikkelen, maar ook desktop applicaties en later ook (lente 2009) applicaties voor de mobiele telefoon. Het JavaFX platform is dus veel breder dan JavaScript/AJAX.

[Verwijderd]

Ik weet niet of je GWT een concurent van JavaFX kan noemen.

GWT is meer de tegenhanger van JSF (Java Server Faces).

[Verwijderd]

Alleen voor OSX en Windows? Hopelijk gaat een Linux SDK toch deel uitmaken van de uiteindelijke versie...

Wat ik ook niet echt begrijp is dat die lui van Sun nog steeds met dat NetBeans lopen rond te zeulen. Zo'n beetje elke Java programmeur gebruikt Eclipse. Als ze daar nou hun energie en resources in zouden stoppen in plaats van NetBeans...

[Verwijderd]

zo'n beetje elke java programmeur die ik ken gebruikt netbeans

[Verwijderd]

Das grappig. Ik ken een grote groep java programeurs en ik ken er niet een die Netbeans gebruikt (professioneel)...

[alienfruit]

Ach, mobiele toestellen worden voorlopig nog niet ondersteunt. Niet interessant dus