Sun gaat eigen Java-ontwikkeltools flink aanpassen

Sun heeft laten weten grote verandering aan te gaan brengen in de Java-ontwikkeltools, zo schrijft Reuters. Het plan is om te zorgen voor het uitbreiden van het gebruik van de programmeertaal. Tijdens de JavaOne-conferentie in San Francisco zullen de precieze details deze week bekendgemaakt worden. Dit jaar zal Java daarmee uit moeten groeien tot een solide product in de informatietechnologie. Een onderliggende gedachte achter de verdere verspreiding van Java is te vinden op een compleet ander vlak: servers en opslagsystemen. Sun heeft namelijk beloofd gratis bepaalde servers weg te geven indien klanten licenties op ontwikkeltools nemen. Gehoopt wordt dat de verkoop van dergelijke systemen hiermee gestimuleerd zal worden.

Reacties (56)

[dawuss]

Dit jaar zal Java daarmee uit moeten groeien tot een solide product in de informatietechnologie

Dit vind ik een vreemde zin. Is het namelijk niet al jaren zo dat Java een grote speler is in de softwaremarkt?
Het feit dat een java programma altijd portable is naar een willekeurige machine met een Virtual Machine, zonder daarbij rekening te houden met de aanwezige libraries en dergelijke, spreekt een boel programmeurs aan.

Ik ben benieuwd wat de toekomst van Java vs .NET ons gaat brengen. Het lijkt me in ieder geval dat Sun dit zeer serieus neemt.

[Standeman]

offtopic:
je moet wel degelelijk rekening houden met je libraries! (maar als je slim bent gooi je die in je jar-file)

Zoals eerder opgemerkt is de .NET omgeving toch een stukje verder dan de verschillende Java IDE's die er zijn. Zeker voor ondersteuning voor de beginnende noob is het wat makkelijker om in .NET te programmeren dan in een willekeurige Java IDE. (Hoewel "echte" programmeer taken niet door noob's uitgevoerd moeten worden, anders wordt het echt een zooitje )
Ik ben benieuwd wanneer er een IDE komt die aan de .NET omgeving kan tippen. Ik geloof dat WebSphere Developer en JBuilder al redelijk in de buurt komen.

[register]

Wat de noobs betreft, er wordt aan gewerkt... het is momenteel een belangrijke prioriteit voor Sun. Getuige bijvoorbeeld JSF en Sun Java Studio Creator.

Plus natuurlijk dat de ontwikkelingen aan NetBeans (voor de wat gesofistikeerdere developer) ook nog steeds verdergaan.

[Bermpje]

JBuilder is redelijk, al heeft het soms wel wat rare trekjes. Zelf ben ik wel onder de indruk van Eclipse ( http://www.eclipse.org ). Is via zijn plugin systeem aan te passen naar eigen behoefte. Project files zijn uitwisselbaar met JBuilder. CVS ondersteuning in JBuilder vind ik dan weer stukken beter.

[Pruttelpot]

En toch bestaat Java nu al zo lang, en is het nog nooit echt hard van de grond gekomen.

Hoewel, nu laatste die Java Office versie.
En natuurlijk op mobiele telefoons is het wel redelijk bekend al.

Maar voor echt grote standaard paketten blijft Java geen gebruikelijke taal. Tot voorkort waren de redenen daarvoor dat Java te traag was. Met de nieuwe verise van Java lijkt ook dat probleem een stuk minder te kloppen.

[register]

Pardon, nooit van de grond gekomen?

Voor server-side programma's is het dé standaard. Je moet als bedrijf al goed gek zijn om iets anders te kiezen. Voor grote, ingewikkelde, mission-critical programma's is Java veruit het belangrijkste platform! Tenzij je met 'grote paketten' desktopprogramma's zoals tekstverwerkers bedoelt...

Voor mobiele toestellen is het dé standaard (zo'n anderhalf miljard toestellen draaien een recente Java-versie... afgeslankt natuurlijk).

En idd, traag is het al jaren niet meer. Er is praktisch geen performanceverschil meer met native C++.

[MisterData]

Dat is niet geheel waar. Het mooie van Java is dat de VM de Java Bytecode zelfs kan optimaliseren aan het systeem waar het op draait. Met C/C++ kun je op een Pentium II geen SSE en weet ik allemaal voor trucs uithalen die een Pentium IV wel kan (en heb je dus ofwel verschillende executables etc nodig, of je gebruikt de extensies niet). Bij Java echter zou de VM in principe kunnen kijken hoe het systeem eruit ziet en de code specifiek voor die PC kunnen optimaliseren. En dan zou het zelfs wel eens sneller dan C/C++ kunnen zijn. Het moge duidelijk zijn dat Java allesbehalve 'yet another' interpreted taal is, dat is het dus niet.

En wat betreft het WOrd verhaal hierboven: Java Word zal indien je het maakt met Swing inderdaad een stuk trager zijn, maar dat is gewoon omdat de Swing-toolkit echt een stuk trager is. Zou je het met SWT (dat bijvoorbeeld door Eclipse wordt gebruikt, zie eclipse.org) maken, dan zou je geen verschil merken tussen een native C/C++ app en een Java applicatie. Geloof je me niet? Download dan de Eclipse-IDE maar es....

[Verwijderd]

Razend dure libraries voor Java dus, inferieur taaltje...

http://www.apache.org
http://jakarta.apache.org

En dat is nog maar het topje van de ijsberg. Ik heb nog NOOIT een library gekocht in Java, en toch heb ik er al ontelbare gebruikt.

Java is conceptueel een vrij mooie OO taal (het is nog geen Smalltalk) en de application servers die BEA, IBM, Oracle etc. in Java schrijven zijn al jaren niet meer plat te krijgen. De, in C en C++ geprogrammeerde ORB's van enkele jaren geleden zijn daarentegen al lang op de vuilnisbelt terecht gekomen. Dit na telkens weer financiele catastrofes tijdens projectontwikkeling en productie bij het bouwen van CORBA based servers.

Nu ja, sommige mensen zijn altijd tegen meer 'high-level' talen; het geeft ze immers minder kansen om hun tijd met prutsen te verknoeien ('weer eentje die een linked list gaat zitten bouwen') en dwingt ze om eindelijk eens productief te zijn....

[Remenic]

Dussss jij kan mij garanderen dat MS Word in JAVA net zo snel zou zijn als dat deze nu is, op mijn 366MHz PII laptop met 160MB RAM?

Of is VB/C/C++ (native compiled) toch nog steeds iets sneller?

[Little Penguin]

Ik ben de URI kwijt -dus ik kan je geen link naar de benchmarks geven, maar er is iemand geweest die de server JVM, de client JVM en native C(++) vergeleken heeft qua snelheid.

Wat blijkt: De server JVM is ongeveer net zo snel als compiled C++, dus dat performance verschil valt wel mee. (Ik wist zelfs niet eens dat er een server en een client JVM is, het grootste verschil zit 'm in het geheugen gebruik van de JVM - de server JVM lust flink meer geheugen dan de cient-JVM; maar dat wordt ook steeds minder een probleem...)

Voor het geval je het nog niet wist, als er pagina's getoond worden met .jsp in de filenaam dan heb je een server die geheel of gedeeltelijk in Java werkt. Er zijn zelfs sites die bewust voor een Java based server (zoals Resin of Tomcat) kiezen i.vm. performance...

Op basis van eerdere ervaringen (brakke JVM/JRE's) iets zeggen is wel aardig, maar soms is het checken van recentere versies te prefereren.

[voodooless]

Je weet dat je in native C++ ook fratsen als SIMD kunt gebruiken?

En? Is dat interessant is server omgevingen: nee, totaal niet! En de java JIT compiler kan ook net zo eenvoudig van SIMD genbruik maken!

[Jace / TBL]

En? Is dat interessant is server omgevingen: nee, totaal niet! En de java JIT compiler kan ook net zo eenvoudig van SIMD genbruik maken!

Ik had het ook niet alleen over server-omgevingen. Voor webservices zal het inderdaad weinig boeien, hoewel ik me kan voorstellen dat het zelfs daar soms nog nut heeft (routeplanner service die een zooi afstanden optimaliseert, tabellen met statistieken doorploegen, whatever).

Dat de JIT compiler net zo eenvouding SIMD code kan produceren betwijfel ik, want voor zover ik weet heb je geen native 128bit datatypes met standaard 4-in-1 operaties waar ook in bytecode nog iets anders van over blijft dan de vervangende losse instructies of for-loopjes.

[Jace / TBL]

Dat is niet geheel waar. Het mooie van Java is dat de VM de Java Bytecode zelfs kan optimaliseren aan het systeem waar het op draait. Met C/C++ kun je op een Pentium II geen SSE en weet ik allemaal voor trucs uithalen die een Pentium IV wel kan (en heb je dus ofwel verschillende executables etc nodig, of je gebruikt de extensies niet).

Welnee: gewoon verschillende implementaties van dezelfde functie in je exe, en bij het initten check je de cpu-specs en vul je de optimale function pointers in (of new je de juiste afgeleide class).

Bij Java echter zou de VM in principe kunnen kijken hoe het systeem eruit ziet en de code specifiek voor die PC kunnen optimaliseren.

In theorie wel, maar in de praktijk produceren vooralsnog de laatste C++ compilers van Intel en VC 7.1 een stúk slimmere asm dan die voor Java.

Verder lijkt het me sterk dat een Java VM of JIT zelf kan herkennen welke stukken code geschikt zijn voor MMX of SSE.

Geloof je me niet? Download dan de Eclipse-IDE maar es....

ff uit nieuwsgierigheid: is die er ook voor de Mac, en krijg je dan met dezelfde code op PC een native "XP look en feel" gui, en op Mac hetzelfde met OS X uiterlijk?

[mxcreep]

@Little Penguin

Dat de file extensie van een web file .jsp is betekend nog niet dat dat een java jsp is...
Ik kan ook .jsp extensies door een php engine uit laten voeren bijvoorbeeld.
Maar in de praktijk : Broadvision gebruikt ook de extensie .jsp en dat is in de meeste gevallen gewoon server side javascript...voorbeeld : http://www.ingbank.nl

[Bermpje]

niet te vergeten dat met chips als microJava 701 en PicoJava II niet eens meer een VM nodig hebt! Dan is JAVA helemaal niet langzamer meer.

Ben overigens wel van mening dat je een taal zoekt die het meest geschikt is voor je project. Soms is dat JAVA, dan weer C#, soms C++, etc etc.

[Jace / TBL]

En idd, traag is het al jaren niet meer. Er is praktisch geen performanceverschil meer met native C++.

Je weet dat je in native C++ ook fratsen als SIMD kunt gebruiken?

[PatMan]

Ik ben de URI kwijt -dus ik kan je geen link naar de benchmarks geven, maar er is iemand geweest die de server JVM, de client JVM en native C(++) vergeleken heeft qua snelheid.

Ik denk dat je dit artikel bedoelt!

[Verwijderd]

ff uit nieuwsgierigheid: is die er ook voor de Mac, en krijg je dan met dezelfde code op PC een native "XP look en feel" gui, en op Mac hetzelfde met OS X uiterlijk?

Ja en Ja.

Er is wel een kleine cotcha; de Mac OS X versie van Eclipse 2.1 (eigenlijk van de corresponderende SWT lib) is erg brak op OS X. Van alle SWT versies is het de aller slechtste. In Eclipse 3.0 zou dit een stuk beter moeten zijn, echter deze vereist wel Mac OS X 10.3. Zelf heb ik nog slechts 10.2 draaien, dus heb het nog niet kunnen uitproberen.

[Verwijderd]

Er draait meer java dan je denkt....
Maar het meeste draait als middleware of webfrontends van grote business pakketten.
Trouwens hoeveel java phones zijn er inmiddels al?

[Verwijderd]

COBOL heeft de toekomst.

[haven]

Herstel: COBOL had de toekomst

[hardwareaddict]

Er draait ook meer Fortran nog als je denkt...

[Jace / TBL]

.NET is natuurlijk zo platform-afhankelijk als de pest, dus wat dat betreft mis je compleet de 100% portability waar ze bij Java altijd zo mee schermen.

Dat Java als standaard voor normale applicaties nooit echt is aangeslagen, komt doordat
- het stukken trager is (misschien al sneller dan vroeger, maar afaik loopt het nog steeds mijlenver achter op de c++ compiler van VC 7.1)
- de IDE's zonder meer bagger zijn vergeleken met die van VC.NET
- de portability van Java voor normale software in de praktijk bitter tegenvalt: geen native GUI controls (apps die eruit zien als web forms), afhnakelijk zijn van wat voor VM er op een random bak staat (met alle incompleetheid of versieverschillen van dien in de libs), en cross-platform compilen is er al helemaal niet bij (bijv. een Mac versie van je software builden op een PC).

Wat dat laatste betreft, de platform-onafhankelijkheid, werkt mijns inziens C++ nog altijd een stuk lekkerder.

[MetroidPrime]

Waarom wil je crosscompilen? De portabiliteit houdt in dat je de software 1 keer compileert en daarna draait de software op elke machine met de juiste VM. Het draaien van de juiste VM is ook geen probleem meer, de nieuwere versies controleren standaard automatisch of er geen nieuwere release is en als dat wel zo is updaten ze indien nodig.

Over IDE's die bagger zijn, heb je ooit met Eclipse gewerkt? Ik wel en hoef sindsdien echt geen andere IDE meer.

[Verwijderd]

Waarom doe ik dan elke keer als ik een programmaatje voor telefoons wil maken.
select de goede VM, SE 1, SE2, Nokia S40, Nokia S60, Siemens, Motorola enz. en compileren.

Helaas is het nog steeds niet mogelijk met 1 jar file alle telefoons te bedienen. Zonder geluid of speciale features kom je een eind, maar zelfs transparancy van plaatjes wordt niet op elke telefoon hetzelfde afgehandeld.

Probleem is de "juiste" VM. Heb je bij desktop applicaties enkel 1.2,1.3, 1.4 bij telefoons heeft elke telefoon zijn eigen VM met zijn eigen trucjes. Zelfs midp 2.0 is niet echt een verbetering. BT ondersteuning, Java 3D ondersteuning enz enz hangt nog steeds van de telefoon af die je gebruikt. Dus zo makkelijk is het nou ook weer niet. (Helaas)

[hardwareaddict]

Windows heeft gewonnen zoals we ons allemaal realiseren. Het is heel jammer en ik hoop dat er ook ooit eens een alternatief voor komt, maar dat zie ik persoonlijk voorlopig nog niet zitten.

Laten we beginnen met spelletjes. Spelletjes willen natuurlijk dingen als 3d, direct3d sound etcetera.

Allemaal dus directx gebaseerd.

Wat toevallig, microsoft had een grootse rechtszaak gewonnen over hun DC (device contests), te weten dat nieuwe OpenGL drivers niet gecast mogen worden op de windows DC's. Kortom SGI en dat soort fabrikanten mochten geen OpenGL driver uitbrengen voor toekomstige OpenGL standaarden (belachelijk inderdaad, maar het recht dat dom is praat recht wat krom is, ik kan er ook niks aan doen).

Kortom voor alles wat sound en graphics gebruikt in de toekomst is directx de enige die werken gaat voor je, omdat de rest gewoon niet gaat werken onder windows simpelweg.

Dus een concurrerend OS zal al die functionaliteit die in directx zit, ook werkend moeten zien te krijgen voor hun OS.

Kortom windows heeft daar een voordeel waar je natuurlijk niet tegenaan kunt programmeren. Je moet namelijk dansen naar de pijpen van microsoft.

Dat is natuurlijk niet een erg leuk vooruitzicht, maar ik hoop dat dit wel illustreert hoe enorm de dominantie van microsoft windows zal zijn in de komende jaren.

Dat betekent voor JAVA software dus simpelweg dat ze ook onder windows zullen moeten werken voor directx.

Kortom Sun gaat voor zijn concurrent microsoft software ontwikkelen. Zit microsoft nog steviger in het zadel

[joco]

Wat hoor ik hier toch allemaal weer verschrikkelijk veel onzin. Ik ben al jaren programmeur in java met uitstapjes naar dot net. Maar ik snap die mensen niet die dot net echt makkelijker vinden. Ja puur de design tools. De quick hack werk dat gaat sneller maar voor de rest is die editor en debugger echt niet zo best als wat ik met eclipse hebt. Bij lange na niet. En ik heb toch al een tijdje met beide gewerkt.

Java traag is ook onzin tegenwoordig. Java kreeg die naam door de UI componenten genaamd swing. Want java op de serverside is verre van traag. Maar Swing is met 1.4.2 en nu straks met 1.5 kwa snelheid behoorlijk verbetered. En daarnaast heb je SWT waar eclipse mee werkt En bv ook de bit torrent client azures die door velen worden gebruikt. Dus zelfs java op de clientside is nog lang niet dood maar komt er zelfs eindelijk weer aan.

Ik heb de laatste tijd een beetje in C#, Visual Basic (6 en dot net) en in java geprogrammeerd. VB6 is echt een ramp trouwens. Maar doe mij maar java veel cleaner en netter.

[KurtDB]

Er zijn hier duidelijk mensen die met een verkeerd idee zitten. Er is recent een studie geweest die heeft aangewezen dat Java tegenwoordig sneller is dan geoptimaliseerde C++ programma's. Dus die factor performantie valt ook héél erg goed mee.

http://www.kano.net/javabench/

De fout ligt dus niet bij de JVM, maar bij de slechte code die geproduceerd wordt. (pas op: ik zeg niet dat alle java-programmeurs slechte code schrijven)

@ hardwareaddict: je vergeet je argumenten te staven door een vergelijking te trekken. Niet alle libraries van .Net zijn gratis, zodus dat kost je ook al een aardige duit. Daarenboven komt nog dat je licenties moet kopen voor elke machine waarop je wil ontwikkelen.

De gebruiksvriendelijkheid van .Net heeft ook haar beperkingen: de asp.net code is bv al niet w3c valid te krijgen en de ide klooit vrij vaak in je html-tags.

[voodooless]

Idd, gebruikersvriendelijkheid van .Net stopt zodra je het windows platform verlaat. Sun (en vele ander bedrijven) doe(t/n) in ieder geval moeite om java op alle platformen gebruikersvriendelijk te houden!

Wat betreft JVM performance: Idd, java is in OO gewoon net zo snel of sneller dan C++. Daarnaast heb je ook nog eens geen last van buffer overflows ed. Voor Server apps is het gewoon ideaal dat het gewoon op vele platformen runt, en dat de apps zonder problemen met elkaar kunnen communiceren via jni of CORBA. Vooral java op de opteron is leuk, waar de 64-bit's vm 30% en in eklele gevallen tot 100% sneller is dan de 32-bit versie

[Jace / TBL]

Er zijn hier duidelijk mensen die met een verkeerd idee zitten. Er is recent een studie geweest die heeft aangewezen dat Java tegenwoordig sneller is dan geoptimaliseerde C++ programma's. Dus die factor performantie valt ook héél erg goed mee.

Hou nou toch op... moet je die benchmark zien. Gaan ze GCC gebruiken als referentie

Goeie C++ die door een fatsoenlijke compiler is gehaald, krijg je niet sneller in Java, punt.

[Yoshi|IA2]

Man man man...
Iedereen is hier aant zagen dat java traag is. We moesten dit trimester op school een routeplanner maken. Mijn projectgroep natuurlijk fijn in java, de rest van de projectgroepen in C++ "vanwege de snelheid".
Resultaten: onze routeplanner vloog van Oostende naar Aarlen in 0.5 seconden (Zo'n 350km). De snelste van de andere groepen was 5 seconden op zo'n lange route. Dus ga me niet vertellen dat java traag is...
Ik persoonlijk vind java veel fijner om mee te werken. Tenminste een deftige compiler, en je kan JBuilder gebruiken!

En van de gui? Ik heb al verschillende gui applicaties gemaakt in java, en die hadden telkens gewoon de look and feel van het operating system. Je moet gewoon weten hoe je de look and feel aanpast...
Alhoewel ik moet toegeven dat een Gui maken fijner is in C++ icm Qt...

[Jace / TBL]

Dat heeft natuurlijk niets met de snelheid van C++ of Java te maken, maar met wie het slimste algoritme verzint.

[Yoshi|IA2]

Bwa, allemaal ongeveer hetzelfde algoritme... Sneller als astar is er niet voor het optimale pad te vinden in een graaf...
Trouwens, wij hebben ons algoritme ook omgezet in C++ met dezelfde geheugen structuren, en er was geen snelheidswinst.
Ik wil niet zeggen dat c++ slechter is, ik krijg alleen stress van het vooroordeel dat java traag is, want dat is niet...

[Bermpje]

Toch bij het maken van 3d animaties is het aan te raden om voor perfomance redenen in C++ te werken en niet in Java. Het ligt gewoon heel sterk aan het type project. Tevens bepalen randvoorwaarden gesteld door de opdrachtgever heel sterk de taal waarin je ontwikkeld.

[Vaudtje]

Dat zal ook de reden zijn dat Project Lookinglass in Java geschreven is....
(Okee, dat is dus ook van Sun, maar het lijkt allemaal wel erg goed te werken ook al is het gemaakt in Java)

[qless]

Daarom is er ook Java3D

[dotnetpower]

Of de rest van die groepen kunnen niet efficient programmeren

[Verwijderd]

Dat lijkt me ook zeker een slimme zet, aangezien Microsoft met haar .NET-omgeving imho een vrij grote voorsprong heeft op de rest van de programmeeromgevingen wat betreft de combinatie programmervriendelijkheid en portabiliteit

[mayhem]

Vergeet ook de eclipse IDE niet.
Samen met de IBM ontwikkeltools zijn dit toch de meest uitgebreide ontwikkelomgevingen die ik ken.

[Verwijderd]

Idd, eclipse IDE

er is nog iets van IBM: WSAD, daar krijg je veel tools bij

[Verwijderd]

en dat is verschikkelijk duur, WSAD wel te verstaan.
Geef my maar IntelliJ IDEA, is tenminste betaalbaar en zeer goed:
wat kost dat? $500 tegen ruim $4000 voor WSAD.

Wat Netbeans betreft: heeft nooit echt indruk gemaakt.

[Jace / TBL]

aangezien Microsoft met haar .NET-omgeving imho een vrij grote voorsprong heeft op (..) en portabiliteit

Wablief!? Hoe is .NET precies portable dan?

[Verwijderd]

je KAN theorethisch gezien .NET porten, met ''mono'' bijvoorbeeld, daarmee begint dat portobiliteitstheorie werkelijkheid te worden, kijk op : http://www.go-mono.com/

[Verwijderd]

Tuurlijk, maar de parent heeft het over de VOORSPRONG die .NET wat dat betreft heeft, da's dus complete stiereschijt.

[Verwijderd]

dan heb je wel gelijk voorsprong noem ik niet, maar .net heeft wel andere ''leuke'' eigenschappen, iets betere performance, een hele goede msdn, keuze uit meerdere programmeertalen, en een ''completer' IDE (VS.NET).

[Kahlan]

.NET draait op een groot aantal platformen hoor:
Windows XP
Windows XP SP1
Windows XP SP2
Windows 2003 Server
Windows 2003 Advanced Server
Windows 2000
Windows 2000SP1
Windows 2000SP2
Windows 2000SP3
Windows 2000SP4

Het bovenstaande lijstje is nog niet eens compleet en haalt de 10 al!

[Verwijderd]

Aanvulling:
Win 98
Win Me
Windows Media Center
Windows CE.NET
Linux
FreeBSD
MAC OS 10.2

En ik dacht ook al unix

[TheOneLLama]

I werk liever in eclipse als VS.NET eerlijk gezegd.

[jimshatt]

Ik werk liever in Eclipse als mezelf.
En ik werk ook liever in Eclipse dan in VS.NET. Al is het maar omdat je als je in VS.NET werkt 'beschermd' wordt tegen allerlei achterliggende systemen wat handig lijkt totdat je wilt afwijken van de manier die MS bedacht heeft.

Wat betreft netbeans zijn er een aantal dingen waar ze op Eclipse voorlopen (wireless toolkit en code folding bijvoorbeeld). Eclipse 3.0 haalt dat weer ruimschoots in en blijft de IDE naar voorkeur IMHO. Alleen de CVS integratie van Eclipse sux echt big-time, zeker als je ook nog andere CVS tools wilt gebruiken. Met Subversion is het beter, en hopelijk is Eclipse 3.0 ook beter op CVS gebied.

IDEA lijkt weer een klasse hoger, maar je moet wel geld voor neerleggen, wat ik niet heb

[Remenic]

JAVA is niet programmeur-vriendelijk? Heb je uberhaupt wel eens in JAVA geprogrammeerd? En wat versta jij onder portabiliteit? Dat het op alle Windows machines werkt?

Ik krijg het idee dat jij alleen met Visual Studio .NET hebt geprogrammeerd, op een Windows machine natuurlijk

[mxcreep]

Ligt maar net aan wat je ermee wilt bouwen denk ik. ik persoonlijk vind de combi jsp + struts nogal een omslachtige manier van werken voor web...de frontends dan uiteraard he...
Als ik veel schermpjes moet maken etc gebruik ik toch echt liever een scripting language als php, werkt een stuk vlotter...
Aan de andere kant als je veel business logic in een site hebt werkt dat in java weer een stuk overzichtelijker en dus eenvoudiger...

[Fuzzillogic]

netbeans.orgValt allemaal wel mee met die voorsprong

[sid3windr]

portabiliteit? oh my...

[Verwijderd]

laat ze nu zorgen dat java minder cpu gebruik in beslag neemt, het vreet power