Nieuwe versie Java richt zich op Web 2.0-eigenschappen

Java Platform Standard Edition 6 (Java SE 6), codenaam Mustang, zal de beschikking krijgen over 'Web 2.0'-eigenschappen in de vorm van een sterk verbeterde ondersteuning van scriptingtalen, aldus Bill Curci, product­marketing­manager van Java SE. Volgens Curci vormt binnen de Web 2.0-visie het internet de basis voor het ontwikkelen van nieuwe webapplicaties en hebben met name scriptingtalen (zoals PHP, Perl, Python, JavaScript en Ruby) ervoor gezorgd dat webapplicaties groot zijn geworden. In het verleden was het moeilijk om applicaties in deze talen te laten communiceren met Java-programma's en -objecten, vanwege allerlei code die handmatig moest worden toegevoegd, maar het nieuwe framework van Mustang moet dit gaan vereenvoudigen. Verder zal Java SE 6 verbeterde ondersteuning bieden voor de ontwikkeling en het uitrollen van webservices. Ook zal in Java Platform Standard Edition 6 waarschijnlijk gewerkt worden aan de stabiliteit van en de compatibiliteit met oudere Java-code, en daarnaast zal Mustang mogelijk verbeterde support aan boord krijgen voor het diagnosticeren, monitoren en beheren van Java-applicaties.

Reacties (45)

[Boudewijn]

een keer wat leuke java upgrades zoals case-switches op string zou ook wel leuk zijn

puur syntactisch gezien... dit kan allang in C namelijk . Puur web-based gezien zal Java trouwens hiermee alleen maar zijn positie versterken trouwens.

[flowerp]

een keer wat leuke java upgrades zoals case-switches op string zou ook wel leuk zijn

uhmmm????

Dat kan al vrij lang hoor!?

[code]
enum Woorden { aap, noot, mies };

public String doSwitchTest ( String testString ) {

switch ( Woorden.valueOf(testString) ) {

case aap:
System.out.println ( "De aap is aangeroepen" );
break;
default:
System.out.println ( "Onbekende string" );
}
}
[/code]

Werkt gewoon perfect hoor. Ik gebruik dit zelf vaak om op String te switchen die uit een sax parser komen.

[Verwijderd]

Dit zijn niet echt strings he... de switch werkt hier gewoon met een index alleen valt het minder op omdat je er omheen werkt

[flowerp]

Dit zijn niet echt strings he... de switch werkt hier gewoon met een index alleen valt het minder op omdat je er omheen werkt

Ben ik niet 100% met je eens. Je zou er omheen werken als je zelf een stringToIndex oid zou schrijven. Echter, in het enum type zit direct support om een string te matchen met je enum constanten. De gegeven constanten: Woorden.aap, Woorden.mies en Woorden.noot kun je direct omzetten in "aap", "mies", en "noot" en andersom. Alleen vanwege deze support kun je dus, met alleen gebruikmaking van de het enum type en het switch statement, switchen op een String.

Dit is dus NIET eromheen werken, maar gewoon gebruik maken van de language/platform faciliteiten.

Als je dit bijvoorbeeld vergelijkt met de C/C++ enum dan is dit niet mogelijk. enum Woord { a, b, c } is in C/C++ op geen enkele manier via de taal/platform te linken aan "a", "b", "c".

Waar jij mee in de war bent is een constructie als:

switch ( "een string" ) {
case "een string":
// hier matched "een string"
}

In Java doe je dit expliciet niet, omdat je dan type problemen krijgt. Vergeet niet dat Java strong-typed is. Een enum heeft een type, en met deze constructie krijg je problemen als je 2 enums met dezelfde constanten namen in scope hebt.

Vandaar dat je dus bij Java aangeeft bij welke enum je String hoort. Stel namelijk:

enum Enum1 { a, b, c };
enum Enum2 { java, php, c };

switch ( "c" ) {
case c:
// tsja, code voor enum1 of enum2 bedoeld?
}

Dit geeft grote onderhouds problemen, voornamelijk op de grotere projecten. Vandaar dus dat je in Java aangeeft op welke enum type je switched.

Dus

switch ( Enum1.c ) {
case c:
// code hoort dus bij Enum1
}

of

switch ( Enum1.valueOf( "c" ) ) {
case c:
// code hoort dus bij Enum1
}

Om de voordelen hiervan in te zien moet je eigenlijk eens aan een app ontwikkeld hebben van >50.000 regels. Als je alleen kleine projectjes doet van 4 PHP pagina's met 100 regels per pagina, dan zie je waarschijnlijk niet helemaal in waarom type safeness zo'n groot issue is.

[BugBoy]

Dat is natuurlijk wel een gehackte oplossing. Moet je altijd weer een enumerated type gaan definieren en da's ook weer niet handig. In C# is het native mogelijk en da's een stuk handiger. Alleen hoe 'boudewijnTux' erbij komt dat je in C een switch-case constructie op strings kan toepassen weet ik niet, want dat is in C en C++ niet mogelijk.

[Verwijderd]

In C is een string een pointer naar een char array. Die kijkt dus niet naar inhoud.

[flowerp]

In C is een string een pointer naar een char array. Die kijkt dus niet naar inhoud.

klopt, en pointer converteert impliciet naar int waarop je dus kunt switchen. Helaas is het switchen op memory address in 99.99999% van de gevallen niet zo nuttig, en wil je toch echt op value switchen.

[flowerp]

in Java kan je ook prima op referentie switchen

Nee dat kan niet. Er kan alleen op integers en enum constants geswitched worden.

[Verwijderd]

in Java kan je ook prima op referentie switchen

[maxjuh]

hehehe... dat zou idd wel erg handig zijn

[sonix666]

Wauw, knap dat C dat kan, want C++ kan dat absoluut niet. Oftewel, ik denk dat je fout geinformeerd bent. C en C++ kunnen alleen case-switches maken op basis van integers.

[Wolfboy]

Mwah, niet helemaal hoor.
Iets als dit zou mogelijk moeten zijn toch?
switch(the_string){
case strcmp("testje", the_string): printf("it matches");
}

[hansg]

Sorry, maar sonix666 heeft gelijk: het kan niet. De waarden achter een case label moeten constanten zijn. De output van een functie mag daar dus niet gebruikt worden.

Wat je wel zou kunnen klussen is iets zoals flowerp (een paar reacties naar beneden) doet, i.e. met een enum van waarden. Omdat C++ geen mechanisme kent om de waarde van een enum als string op te vragen moet je er zelf nog even een lookup table bij maken, maar het opzoeken van de enum-waarde bij de string kan dmv. een template functie gebeuren dus daar hoef je maar een keer code voor te schrijven. Ik gebruik dat zelf veel (ook voor XML strings, toevallig) en het werkt uitstekend.

[flowerp]

Wel een klein beetje vreemd om WEB 2.0 eigenschappen aan de Standard Edition toe te dichten. De versie van Java die zich helemaal op het web richt is namelijk Java EE en niet in eerste instantie Java SE.

Java EE 5.0 kan ook welk moment uitkomen, en deze zal WEL echt dingen bieden die rich web apps veel makkelijker maakt en het programmeren vereenvoudigt. Zo zit je nu op een JSP pagina zelf met HTML te rommelen met daartussen scriptlets (java). In de nieuwe Java EE 5.0 versie zul je gewoon web componenten hier op plaatsen. Aan deze componenten kun je validators hangen en event listeners. Daarbij zijn ze echt herbruikbaar. Het hele idee is een beetje afgekeken van ASP.NET, maar hey, beter goed gejat dan slecht bedacht.

Ook kwa SQL zal Java EE 5.0 veel makkelijker worden. Het komt er op neer dat je bijna geen SQL meer schrijft! 99% van de SQL queries in web apps zijn eigenlijk toch om gewoon objecten (bv bezoeker, klant, posting, verhaal, etc) in de DB op te slaan. In Java EE 5.0 heb je een zogenaamde entity manager die je alleen het object mee geeft en het ding staat in de DB! Als je object 1:1 of 1:many relaties heeft geef je dat met een simpele annotation aan in je class zelf en Java regelt de rest!

Wat Mustang (waar dit bericht over gaat) vooral zal bieden is performance. Eindelijk zal het al lang over gediscuseerde "Escape analysis" eens in de praktijk gebracht worden (in een notedop: de JVM bepaald of iets stack of heap gealloceerd kan worden).

Dat PHP naar bytecode gecompileerd kan worden zie ik niet zo snel als een WEB 2.0 feature. Web 2.0 gaat over rijkere interfaces. Hoe gaat PHP serverside hier mee helpen?

Als Javascript naar de JVM compiled kan worden, dan zou de client dus dat in haar lokale JVM moeten gaan draaien? Dat lijkt me ook niet echt helpen, daar Javascript juist goed tot z'n recht komt in de browser. Met Javascript in de JVM heb je alleen een andere syntax om je 'java' code in te progammeren. Handig hoor..

[nxt]

Zo zit je nu op een JSP pagina zelf met HTML te rommelen met daartussen scriptlets (java). In de nieuwe Java EE 5.0 versie zul je gewoon web componenten hier op plaatsen. Aan deze componenten kun je validators hangen en event listeners.

Daarvoor hoef je niet op J2EE 5 te wachten, dat kan nu ook al met Java Server Faces of Apache MyFaces.

[flowerp]

Daarvoor hoef je niet op J2EE 5 te wachten, dat kan nu ook al met Java Server Faces of Apache MyFaces.

Je haalt nu enkele dingen door elkaar Apache MyFaces is geen apart produkt maar een implementatie van JSF. In de Java wereld is bijna alles een spec. Andere bedrijven of organisaties (ook open source dus), kunnen dus een (alternatieve) implementatie maken.

Sterker nog, Sun zelf maakt voor veel dingen niet eens meer echte implementaties, maar alleen reference implementations. Met "Java Server Faces" hierboven bedoel je waarschijnlijk de RI. Deze zijn meestal niet primair bedoeld om echt te gebruiken, maar alleen om te controleren wat het gedrag zou moeten zijn. M.a.w. de RI concentreert zich op correct gedrag, niet op robuustheid, scalibility en performance. Voor de hele SUN 1.4 App server (SUN AS) geldt dat ook; ook deze heeft de status van RI.

Ten tweede, de huidige JSF RI en Apache MyFaces zijn en preview van JSF. Het is een standalone lib die opzich prima te gebruiken is, maar logischer wijs niet 100% correct integreerd met de AS (logisch, want de AS weet dus niks van JSF, het zijn gewoon 1 of meerdere jar files die je in je path zet).

Je kunt de huidige status van JSF een beetje vergelijken met Swing vroeger. Ten tijde van Java 1.1 was dit ook een aparte add-on lib die als preview beschikbaar werd gesteld. Pas met java 1.2 was Swing (eigenlijk JFC) een standaard onderdeel van Java SE.

Pas met Java EE 5 zal JSF standaard in Java zitten. Het versie nummer van JSF zal dan 1.2 worden, hoewel het niet 'echt' een nieuwe versie is. Het verschil zit hem voornamelijk in de integratie. Zo zijn momenteel de JSP EL en de JSF EL 2 heel verschillende dingen. Ook heeft de JSPWriter (de writer die aan de response hangt) een hele andere buffer dan de response writer van JSF. Gevolg is een content interweaving probleem: JSP tekst komt op hele andere plekken in de ouput dan JSF tekst.

Op de keper beschouwt zijn het betrekkelijk eenvoudige fixes, maar in de praktijk toch wel redelijk belangrijk. Omdat JSF nog steeds deze preview status heeft wordt het ook nog niet zo veel gebruikt. Je hebt gelijk dat je het KAN gebruiken, maar de meeste mensen wachten toch op de versie die standaard in Java zal zitten.

[Verwijderd]

Het hele idee is een beetje afgekeken van ASP.NET, maar hey, beter goed gejat dan slecht bedacht.

Ach, wat is gepikt. Kijk eens naar wat Tapestry kan en Tapestry heeft dan weer enkele ideetjes geleend van WebObjects (HLS geeft dat vlot toe).
Dus wie was eerst... mogelijks heeft .NET dat afgekeken maar is het de eerste bekende implementatie geworden...

Laten we die hele 'wie pikt van wie' discussie er dus even uitlaten, iedereen speelt wel eens leentjebuur...

[Verwijderd]

Java staat gelijk aan traag.

Als ik eindgebruikers hoor dan is dit de meest gehoorde klacht. (nr 2. stabiliteit).

Ik snap dat het helemaal platform onafhankelijk moet zijn maar waarom moet het allemaal zo slecht draaien? Menu's laggen, schermen nemen letterlijk seconden om op te bouwen., etc.

Ik verwacht niet reacties als "ligt aan de product" of "slecht ontwikkeld".

Bij een klant draait het "inhouse" ontwikkelde programma's traag. Daarna kom ik bij het reisbureau (d-reisen) om mijn vlucht (traag) te zien crashen. Op het tweakers forum wordt azureus de hemel in geprezen.
2 dagen later komt utorrent uit en plots is azureus het trage geheugen vretende java monster.

Java mag volgens mij beter verder ontwikkeld worden. (lees afgeslankt) voordat ze uit gaan breiden.

[flowerp]

Java staat gelijk aan traag.

Ook dat valt behoorlijk mee. In een groot aantal gevallen kan Java (en de .NET talen ook) zelfs sneller zijn dan native code. Dit komt omdat de VM runtime optimalisaties kan doen waarvoor variabelen nodig zijn die je nog niet at compile time had.

De talen die primair native compilen proberen dat wel een beetje na te doen door profiling data te gebruiken: je compiled een applicatie eerst, draait hem dan een tijdje via de profiler, en daarna weet de compiler al meer dingen te optimizen.

Voor sommige applicaties werkt dat echter niet, gewoonweg omdat de datasets die echte users gebruiken nogal verschillen. Voor native applicaties heb je dan ook weer native optimizers. Dit zijn eigenlijk VMs die de host CPU emuleren, met als enige doel om run time te kunnen optimezen (bv Dynamo).

Een voordeel wat een talen als C# en C++ beiden hebben is dat je objecten kunt alloceren op de stack of op de heap. In het algemeen is een stack allocatie veel goedkoper. Een programmeur weet vaak of een bepaald object alleen lokaal gebruikt wordt en kiest dan in C++ voor een stack allocatie. Op bepaalde algorithmen zijn hiermee aanzienlijke performance voordelen te behalen. Het nadeel is dan wel weer dat de grote van de stack implementatie afhankelijk is (er is bv geen universele parameter in GCC om de stack grootte te zetten).

In Mustang wordt het al genoemde escape analysis geintroduceerd. Hiermee analyseert de compiler en/of VM of een object uit een scope kan 'ontsnappen' of niet. Zo niet dan kan, indien het een hotspot wordt, gekozen worden voor een stack allocatie. Dit kan dus een heel groot performance voordeel geven. Het maakt het er voor de programmeur ook makkelijker op. Nu moet je vaak in C++ gaan nadenken of je heap of stack wilt. Veel programmeurs doen maar wat, zodat het potentiele voordeel niet benut wordt. De JVM kan deze keuze dus zelf maken, zodat ook code van 'mindere' programmeurs versneld kan worden.

Het opstart probleem van de VM is ook al langer bekend. Hier komen ook oplossingen voor. Apple heeft bijvoorbeeld code bijgedragen die zorgt dat er meer geshared kan worden tussen verschillende VMs. In Mustang zal dit nog meer toegepast gaan worden.

Veel traagheid is ook 'perceived' traagheid. De code draait opzich niet langzamer (berekeningen duren even lang als native code), maar is het vooral de interface die traag reageert. Een alternatieve toolkit van IBM die voornamelijk native widgets gebruikt is SWT. Deze zit niet standaard in Java, maar gebruik van deze set geeft ook alweer een veel betere performance.

Bij elkaar genomen zou het best wel eens zo kunnen zijn dat met alle performance verbeteringen in Mustang, het zou kunnen lonen om een PHP applicatie naar Java bytecode te compilen en via de JVM te draaien. Mogelijk geeft dit grote performance winst en wordt het dus aantrekkelijk om de JVM onderhuids te gaan gebruiken voor hele andere platformen.

[arjankoole]

Java staat gelijk aan traag.

dat ligt eerder aan de ontwikkelaar dan aan java. Het bedrijf waarvoor ik werk bouwt en host gecompliceerde java-apps, en dat draait allemaal heel snel, maar als je kijkt naar al die java-based games... tja.. dan wordt het inderdaad wat trager.

[Verwijderd]

Het enige trage dat ik aan java merk, is het opstarten: als je een java app opstart, moet je eerst de javavm opstarten, dat kost veel tijd en geheugen.
Maar als je daadwerkelijk benchmarks gaat voeren op de uitvoering van algoritmen is java lang niet zo traag.

Ik moest een algoritme inplementeren als studieopdracht. Ik deed het in java, een andere jongen in matlab. Hij gebruikte 10 000 rondes en klaagde dat het simuleren zo lang duurde. Ik gebruikte 100 000 en vond het in totaal toch niet echt veel tijd kosten.

[Verwijderd]

"Ik gebruikte 100 000 en vond het in totaal toch niet echt veel tijd kosten."

Jij VOND dat het niet echt veel tijd kostte...het zou duidelijker zijn als je er een tijdsduur bij zette, dan kun je pas concreet iets vergelijken...maar dat lijkt me logisch (Cruijff tm)

[eamelink]

Een ander puntje waardoor Java apps initieel eventjes traag zijn is dat de JIT compiler nog wat bytecode gaat zitten compileren. Dat kost even, dus het opstarten gaat vaak niet zo heel snel.

Daarna zijn goede applicaties niet merkbaar sneller dan native applicaties.

Dat Java langzaam is (en dan ook echt langzaam), is een combinatie van een mythe uit de tijd dat alles nog geïnterpreteerd werd omdat er nog geen JIT compilers waren en omdat het laden in het begin even wat langer duurt dan bij native apps.

[Verwijderd]

Dat zegt helaas heel weinig, want ik weet niet precies hoe lang het algoritme duurde in matlab. Ik heb het gemeten met 36 meetpunten, en voor elk meetpunt 100000 loops. Dat duurde zo'n 4 minuten, maar dat zegt evenveel over het algoritme en de snelheid van mijn processor als de snelheid van java.

Het was ook zeker niet mijn bedoeling een goed onderbouwd onderzoek hier te presenteren op tweakers. Het was maar een voorbeeldje.

Dat java in benchmarks niet trager is dan andere talen heb ik eens ergens gelezen, maar ik weet niet meer waar (mogelijk op tweakers.net). Je zou denken dat java trager is omdat java bytecode niet native is aan de processor, maar hier kan ook weer voordeel uit gehaald worden dmv on the fly optimalisatie. Op dit gebied doet java voor zover ik weet niet onder op andere talen.

Wat wel een nadeel van java is, is dat bij het opstarten van programma's ook de java virtual machine gestart moet worden. Bovendien gebruikt java niet de standaard libraries in windows/linux/mac/whatever. Dit zorgt ook weer voor extra opstarttijd en geheugenverbruik, maar heeft als voordeel een enorme portability. Als de libraries eenmaal volledig in het geheugen zijn geladen merk ik niets meer van traagheid (even getest met limewire).

Ditzelfde effect merk ik ook op linux. Ik gebruik xfce (gebruikt gtk libraries), maar mijn favoriete editor is kate (gebruikt qt). Kate voor het eerst opstarten duurt vaak belachelijk lang en kost veel geheugen. Start ik daarna ook konqueror (ook qt) dan gaat dat al sneller.

Naar mijn mening zijn alleen de lange opstarttijden en het grote geheugengebruik van javaprogramma's vervelend. Dit effect zou een stuk minder zijn als je heel veel javaprogramma's gebruikt, maar dat doet niemand geloof ik .

[s3n]

Sun kent de techniek HotSpot die sinds 1.4 automatisch gebruikt word. Ieder stukje bytecode wat 1500 keer uitgevoerd is word gecompiled naar native machine code met allerlei optimalisaties.
De laatste 98500 keer dat jij je iteraties draaide zal het idd een stukje sneller zijn geweest

[Verwijderd]

Sun Java vind ik erg traag en belastend voor het systeem. Zelfs op mijn XP2500. Niet alleen bij het opstarten van het Java, maar ook in het gebruik. Daarbij dan nog die vervelende icoontjes die Sun overal meer neer denkt te moeten planten. Daarom gebruik ik nog gewoon ouderwets MS-Java. Doet het veel beter.

[flowerp]

Daarom gebruik ik nog gewoon ouderwets MS-Java.

Duh! Dat is een JDK 1.1 implementatie. Natuurlijk is die lichter. Als ik Windows 3.1 op mijn P4 draai is dat ook minder belastend. Alleen jammer dat je er ook minder mee kan he?

[Verwijderd]

Minder kan? Wat dan? Ik merk er niks van dat ik iets niet kan. Ik heb dat Java nodig voor map24.nl en verder nergens voor.
Als Sun Java er op staat verschijnt te pas en te onpas dat icoontje zonder dat er ook maar iets aan de functionaliteit veranderd.

[Verwijderd]

"Daarna kom ik bij het reisbureau (d-reisen) om mijn vlucht (traag) te zien crashen."

dus Java laat nu ook al vliegtuigen uit de lucht vallen ?

N.B. Java zal altijd wat langzamer zijn & meer geheugen vreten, omdat er nu eenmaal een vertaalslag tussen zit (de Virtual Machine). Om Azureus als voorbeeld te nemen: die gebruikt om mijn Mac Mini wel veel geheugen, maar gebruikt niet echt bijzonder veel processorkracht.

Ik blijf erbij dat Java eigenlijk niet gebruikt moet worden om GUI's te maken, maar beter tot z'n recht komt 'onder water'...als server-process

[spazmaster]

Java is een beetje te laat! Web 2.0 gaat trouwens alleen voor een klein gedeelte over rich user interfaces.

En het gaat tegenwoordig niet alleen om 'rich user interfaces' (blijft belangrijk voor de end user) maar developers eisen nu ook een efficiente werkomgeving.

Frameworks zoals Ruby on Rails en Django spelen hier goed op in. Je hebt natuurlijk Spring voor Java, maar er zijn fundamentele verschillen die niet zo snel goed gemaakt worden. Java is geen dynamische taal (Ruby, Python en PHP wel) wat een nadeel is voor webapplicaties.

Met EE 5.0 en SE 6 maken ze de die hard Java programmeurs blij, verder niet. Laat Java maar lekker voor backends en laat het maar een snelle dood sterven voor de frontend

[flowerp]

Java is een beetje te laat!

Zo in het algemeen is dit een dom onzin statement. Met wat is Java te laat? Met sommige dingen ligt Java voor met sommige achter. Ook is voor en achter liggen relatief. Kijk je naar web componenten dan ligt ASP.NET duidelijk mijlenver voor: super goede IDE support, uitstekend werkende technology en een gezonde industrie die web componenten levert.

Java ligt hier wat inderdaad wat achter. De Java versie van de ASP's 'controlls' zit nog steeds in previes. Alleen Scot weet waarschijnlijk wanneer de echte release nu eens zal gaan komen. Deze zomer? Eind van het jaar? Of mischien tot de datum wat verschuiven naar volgend jaar? Niemand die het weet, terwijl in ASP.NET dagelijks duizenden programmeurs de techniek voor productie gebruiken.

Aan de andere kant. De markt voor de Java web componenten komt wel duidelijk op gang. Apache biedt een mooie set componenten aan en Oracle heeft ook een super mooie set gemaakt (met oa rich tables, tree widgets, ajax progress bars, etc, etc).

Kijk je dan naar PHP dan zie je weer dat Java mijlenver voorloopt. Terwijl Java op het punt staat om officieel met web componenten te beginnen en er dus zeer sterk een kritische massa aan het ontstaan is (door de preview versie van de techniek), is er in PHP nog lang en lang geen sprake hiervan. Er zijn wat versnipperde kleine projecten die het aan het proberen zijn, net zoals je met Java 5 jaar terug had...

Web 2.0 gaat trouwens alleen voor een klein gedeelte over rich user interfaces.

Er is geen sluitende definitie van Web 2.0. Het gaat voornamelijk over rich user interfaces, maar iedereen roept wat anders.

Java is geen dynamische taal (Ruby, Python en PHP wel) wat een nadeel is voor webapplicaties.

Ten eerste, dynamische taal is een eufenisme om het als iets goeds te laten klinken. Oorspronkelijk was de naam voor het concept: "weak binding". Maar ja, als taal aanhanger wil je natuurlijk niet je taal als "weak" karakteriseren en daarom ga jij het maar dynamisch noemen want dat klinkt positever, toch?

Ten tweede, waarom is weak binding een voordeel in web applicaties? -zo veel- betekenis heeft het nu ook weer niet in de praktijk. Je geeft geen types op voor je variabelen. Voordeel dat prutsers nix over types hoeven te leren, nadeel dat de compiler je code niet op type errors kan checken. Weak binding bestaat al zo lang. Basic had het al. Toch is basic nou niet bepaald een success geworden voor mainstream apps.

In talen als PHP moet je zowel je frontend als je backend typeless maken. Heel erg handig voor business logic. In Java heb je overigens een speciaal taaltje voor de frontend: Expresion Language. Dit is eigenlijk geen turing complete taal (wordt alleen gebruik voor zoals de naam al zegt expressies), maar deze is ook weak binding. Voordeel hiervan is dat het expliciet extreem simpel en gelimiteerd is, zodat je niet verleidt kan worden om business logic op je pages te gaan zetten, iets wat PHP progammeurs vaak toch nog doen ook al weten ze dat het niet mag.

[Verwijderd]

dynamisch...als in: lek als een spons?

webontwikkelaars van tegenwoordig...Websites worden gemaakt in Flash, Applicaties worden gemaakt in HTML en een zeer slecht gestandaardiseerde scripting taal en de back-end systemen die het meeste veiligheid behoeven (die op het web) worden gemaakt met de meest labiele technologiën.

Server-side scripting talen werken misschien efficient, maar als je je een beet gaat verdiepen in hoe je een echt veilig systeem bouwt ben je met die talen veel verder van huis dan met bijvoorbeeld Java.

[Bobco]

Elk voordeel heb ze nadeel... Natuurlijk zitten er verschillen in bijveoobeeld de ontwikkeltijd van een simpele site in RoR of J2EE. Maar er zijn ook verschillen op andere aspecten: Java heeft een enorme user base, er worden vrij veel 'grote' applicaties voor bedrijven in geschreven en het is door vrijwel elke grote software leverancier (behalve uiteraard MS) omhelst.

Dat maakt de Java-wereld veel groter dan alleen webapplicaties. Die zijn weliswaar erg zichtbaar, maar de gemiddelde webapp heeft de functionele diepgang van een zwinnetje bij laag water. Het echte werk wordt toch nog vaak op grote servers gedraaid en dat is een gebied waar Java 1 van de weinige 'moderne' talen is die veel gebruikt wordt.

Natuurlijk wordt er veel aandacht besteed aan het makkelijker kunnen ontwikkelen van webapps, MS heeft daar een duidelijke voorsprong op het Java-kamp, zekere als het gaat om de integratie tussen ontwikkelomgeving en de rest van de tooling. Aan de andere kant is Java vaak veel flexibeler en heeft mogelijkheden die .Net waarschijnlijk nooit gaat bieden. Ontwikkelen op Windows, testen op Linux en draaien op Solaris? WIj doen dat dagelijks en zijn nog nooit een probleem met portabiliteit tegen gekomen...

[MisterData]

Ik denk dat je Java verwart met ActiveX, want bij mijn weten zijn er nog nooit virussen bij mij via Java binnengekomen hoor... Java was een van de eerste technologieën die het idee van een 'sandbox' voor applets gebruikte, zodat applets niet bij de rest van je computer kunnen...

[mjvdvlugt]

Kijk eens naar "Sancho" dit programma is in Java geschreven maar daarna specifiek per processortype gecompiled. Dit zorgt voor een native snelle applicatie zonder de Java vm.

Ik moet eerlijk zeggen dat Microsoft ook best wel meegeholpen heeft aan de slechte naam van Java. Het was vroeger echt gekloot met die vm van Microsoft versus de vm van Sun.

[VelhaChica]

De koppeling tussen scriptingtalen en Java-applicaties maken het volgens mij wel heel erg handig. Nu lijken dat, in mijn ogen, twee totaal verschillende werelden.

[Verwijderd]

Prima, extra ondersteuning voor scriptingtalen, maar dat heeft an sich natuurlijk geen hol met Web 2.0 te maken. Niet om cynisch te zijn, maar ik vind het wel weer erg typisch dat die woorden afkomstig zijn van een productmarketingmanager.

[Verwijderd]

Sowieso is de hele term nog grotere onzin dan Ajax.

[Verwijderd]

Is dit een soort capitulatie?
If you can't beat them...

[Verwijderd]

zijn 2 heel verschillende dingen, java werk op de client en de rest op de server

[Sv3n]

Nee dus, zoek de term servlets eens op, je kunt daarmee serverside scripten en je hebt het hele java platform tot je beschikking.

Een servlet is een in Java geschreven programma dat binnen een J2EE-webcontainer op een server draait. De servlet maakt hierbij gebruik van een aantal diensten die de webcontainer biedt, zoals het afhandelen van de communicatie met de client. Deze communicatie vindt meestal plaats op basis van het HTTP-protocol. Servlets kunnen worden gebruikt om bijvoorbeeld invulpagina's op een website te verwerken, grafieken te maken of de toegang tot een website te regelen.

Versie 2.3 van de servletspecificatie heeft filters geïntroduceerd. Een filter is een speciaal soort servlet en werkt in een zogeheten filterchain. Een filterchain bestaat uit 1 of meer filters die de aanvragen voor een bepaalde URL verwerken. Elk filter beslist of de aanvraag voor een bepaalde URL verder verwerkt moet worden door de filterchain. Op deze manier is het mogelijk om functionaliteit die voor alle clientrequests gebruikt wordt op een eenduidige manier te programmeren en configureren. Filters worden vaak gebruikt voor compressie, encryptie en logging. Filters zijn een implementatie van het Decorator design pattern.

De tegenhanger van een servlet is een applet, dat is een (klein) Java-programma dat in de browser draait. Er zijn meer soorten programma's die op een webserver kunnen draaien, dit zijn o.a. perl, PHP en ASP.

http://nl.wikipedia.org/wiki/Servlet

[M-ThijZ]

Onzin, we spreken hier van server-side scripting.

[Verwijderd]

Nou, leg dat maar eens uit.

[Verwijderd]

Ok, met Java kan je apps bouwen, bijvoorbeeld een app op een webpagina. Dat laatste kan met Ajax ook. Dan hoor je al tijden van Java ontwikkelaars dat je daar Java voor moet gebruiken en niet die vunzige scripttalen. Ze gooien nu al de handdoek.