[J2EE] De toekomst?

[JKVA]

Ik lees net op TheServerSide een stuk over de toekomst van J2EE in combinatie met SOA. Die ziet er volgens die persoon niet rooskleurig uit en dit komt voornamelijk door de complexiteit.

http://www.theserverside.com/news/thread.tss?thread_id=41283

Nu laat ik me (als J2EE-er) niet uit het veld slaan door één verhaaltje op een site, maar deze week lees ik ook op het intranet van mijn werkgever een column van iemand anders die er ook zo over denkt. (is onder andere één van de auteurs van de UML standaard, dus weet wel één en ander)

Aangesterkt door ook mijn eigen opvattingen en die van mijn omgeving dat er een veel te grote stortvloed aan bijvoorbeeld frameworks is, moet ik zeggen dat het de laatste tijd wel ernstig is.

Nu is het niets nieuws dat J2EE te moeilijk is, maar de vereenvoudigingen lijken naar mijn idee tot nu toe nog niet echt aan te slaan, door onder andere niet super goede tooling ondersteuning. Bovendien heeft Sun net een mooie schone, niet al te complexe standaard neergezet, komt JBoss weer om de hoek kijken met Seam.

Is het niet zo dat er een te grote hoeveelheid J2EE "zaken" in omloop zijn en dat dat momenteel J2EE een beetje aan het nekken is?

Als ik het vergelijk met .NET, dan kan ik alleen maar concluderen dat het daar beter voor elkaar is. Eén standaard waar je mee moet kunnen werken. Ok, in .NET bestaan er ook frameworks bovenop deze standaard, maar je hebt tenminste een basis om vanuit te werken. Bij J2EE moet je steeds weer op zoek naar het goede framework dat zo goed mogelijk bij het probleem past.

Ik ben benieuwd hoe jullie erover denken.

[CubicQ]

Technisch gezien is .NET misschien beter dan Java (zou ook verwonderlijk zijn als dat niet zo is: Microsoft heeft natuurlijk goed naar de sterke en zwakke punten van Java kunnen kijken). Maar ik denk dat dat slechts 1 kant is om naar dit punt te kijken (en misschien wel het minst belangrijke).

In de financiele wereld hebben veel bedrijven een strategische keuze gemaakt om Java te gebruiken en zo'n keuze bepaalt voor lange termijn welke technologie ze zullen gebruiken (om het meest extreme voorbeeld te pakken: kijk eens hoeveel Cobol er nog is, en hoeveel Cobol er nog steeds bij komt). Dus ik verwacht (zeker in die branche; en ik ben te onbekend met andere branches om daar uitspraken over te doen) de komende tijd zeker toekomst voor J2EE.

Een ander punt wat vaak als voordeel van Java boven .NET beschouwd wordt is vendor-lockin. Maar daar geloof ik eigenlijk niet zo in: met Java heb je in de praktijk net zo veel last van vendor-lockin (IBM!).

[Alarmnummer]

CubicQ schreef op dinsdag 11 juli 2006 @ 23:00:
Technisch gezien is .NET misschien beter dan Java (zou ook verwonderlijk zijn als dat niet zo is: Microsoft heeft natuurlijk goed naar de sterke en zwakke punten van Java kunnen kijken).

Heb jij genoeg ervaring met Java (en de gigantische collectie met projecten die je kunt gebruiken) en genoeg ervaring met .NET om hier een betrouwbare vergelijking te maken.

Daarom dit soort 'uitspraken' voor je houden als je niet weet waar je over praat.

[Alarmnummer]

JKVA schreef op dinsdag 11 juli 2006 @ 21:48:
Ik lees net op TheServerSide een stuk over de toekomst van J2EE in combinatie met SOA. Die ziet er volgens die persoon niet rooskleurig uit en dit komt voornamelijk door de complexiteit.

http://www.theserverside.com/news/thread.tss?thread_id=41283

The serverside is een enorme bashing site en niet echt serieus te nemen. Java is idd complex, maar als je je focust op een aantal technieken, dan valt het best te overzien. Verder staat sun erom bekend dat ze niet altijd de meest vriendelijke api's/specs maken. Dit komt gedeeltelijk doordat een enorme lading grote bedrijven (waaronder tool leveranciers) veel in de melk te brokkelen hebben.

Nu is het niets nieuws dat J2EE te moeilijk is, maar de vereenvoudigingen lijken naar mijn idee tot nu toe nog niet echt aan te slaan, door onder andere niet super goede tooling ondersteuning. Bovendien heeft Sun net een mooie schone, niet al te complexe standaard neergezet, komt JBoss weer om de hoek kijken met Seam.

Seam is idd een 'eenvoudige' stack van technologieen die helemaal op elkaar afgestemt is. Kun jij binnen de beperkingen van Seam leven, dan zal Seam denk ik een heel productief product zijn. Maar op het moment dat je er vanaf af gaat wijken, dan komen de problemen.

Als ik het vergelijk met .NET, dan kan ik alleen maar concluderen dat het daar beter voor elkaar is.

.NET heeft het voordeel van weinig opties. Dus als jij een schroef in de muur moet krijgen en je hebt alleen een hamer, dan is de keuze vrij eenvoudig.

Eén standaard waar je mee moet kunnen werken. Ok, in .NET bestaan er ook frameworks bovenop deze standaard, maar je hebt tenminste een basis om vanuit te werken. Bij J2EE moet je steeds weer op zoek naar het goede framework dat zo goed mogelijk bij het probleem past.

mee eens. Maar ik weet uit ervaring dat je meestal een aantal basis technieken gebruiken dus je hoeft niet bij ieder project echt alles te gaan zoeken.

[JKVA]

Alarmnummer schreef op woensdag 12 juli 2006 @ 07:10:
[...]

The serverside is een enorme bashing site en niet echt serieus te nemen. Java is idd complex, maar als je je focust op een aantal technieken, dan valt het best te overzien. Verder staat sun erom bekend dat ze niet altijd de meest vriendelijke api's/specs maken. Dit komt gedeeltelijk doordat een enorme lading grote bedrijven (waaronder tool leveranciers) veel in de melk te brokkelen hebben.

Ehm, Das toch juist een nadeel???

Seam is idd een 'eenvoudige' stack van technologieen die helemaal op elkaar afgestemt is. Kun jij binnen de beperkingen van Seam leven, dan zal Seam denk ik een heel productief product zijn. Maar op het moment dat je er vanaf af gaat wijken, dan komen de problemen.

Ik bedoelde voornamelijk dat nu Sun eindelijk een redelijke standaard heeft neergezet, er weer een framework bij komt. Als je alle nieuwtjes een beetje volgt, kun je je de hele dag blijven bijscholen. Natuurlijk is dat bij 90% niet nodig, maar het is nog steeds een grote overvloed aan zaken. Nu moet ik zeggen dat ik voornamelijk bij de bekende zaken blijf en daaruit probeer verder te werken, maar als ik alleen al kijk wat er allemaal voor JSF te krijgen is... Dat is niet bij te benen, zeker niet als je op een druk project zit.

.NET heeft het voordeel van weinig opties. Dus als jij een schroef in de muur moet krijgen en je hebt alleen een hamer, dan is de keuze vrij eenvoudig.

Maar bij J2EE heb je een complete schuur vol met schroeven die in niet goed geordende kasten en dozen liggen, waardoor de juiste schroef onvindbaar is.

mee eens. Maar ik weet uit ervaring dat je meestal een aantal basis technieken gebruiken dus je hoeft niet bij ieder project echt alles te gaan zoeken.

Mee eens...

[Hydra]

Alarmnummer schreef op woensdag 12 juli 2006 @ 07:01:
Daarom dit soort 'uitspraken' voor je houden als je niet weet waar je over praat.

Lekker lomp.

Anyway, ik werk als integratie consultant bij een technologie bedrijf, en we zien tegenwoordig dat A) steeds meer bedrijven die naar enterprise solutions gaan voor .Net kiezen en dat zelfs een aantal grote klanten van een Java enterprise omgeving naar .Net overstappen. Zelf zijn we vooral Windows gebaseerd, hoewel we een API beschikbaar hebben in zowel .Net als Java (Java versie wordt uitgegenereerd uit de .Net versie, wel cool).

[JKVA]

Hydra schreef op donderdag 13 juli 2006 @ 18:00:
[...]
en we zien tegenwoordig dat A) steeds meer bedrijven die naar enterprise solutions gaan voor .Net kiezen en dat zelfs een aantal grote klanten van een Java enterprise omgeving naar .Net overstappen.
[...]

En dat is net waar ik als Javaan bang voor begin te worden...

[RedRose]

Hydra schreef op donderdag 13 juli 2006 @ 18:00:
dat zelfs een aantal grote klanten van een Java enterprise omgeving naar .Net overstappen.

en

Zelf zijn we vooral Windows gebaseerd.

[Verwijderd]

Ik heb helemaal niet het idee dat er momenteel een sterke migratie naar .NET plaatsvindt. Er lijkt zelfs een groeiende vraag te zijn naar J2EE specialisten de laatste tijd (verkeer momenteel zelf primair in het .NET kamp).

[ Voor 17% gewijzigd door Verwijderd op 14-07-2006 00:32 ]

[Verwijderd]

Ik denk dat je je vooral niet te druk moet maken. EE gaat naar mijn mening langzamerhand wel dood, maar voordat dat echt het geval is. Dat we richting SOA gaan is niet zo vreemd. SOA componenten zijn veel beter te hergebruiken. Maar veel componenten maak je nog gewoon in Java. De meeste SOA produkten gebruiken ook Java en EE. Maar je gebruikt EE niet meer als de basis, maar als hulpmiddel. Het overstappen naar .NET valt naar mijn mening ook wel mee.
Lightweight EE en SOA vervangen heavyweight EE.

[JKVA]

Java EE zal niet zomaar Lightweight worden denk ik. Daar zorgen de partners van Sun wel voor.

IBM, Oracle en dergelijke hebben allen hun eigen belangen en willen allemaal hun eigen features erin.

Gevolg, dikke vette bloat JEE.

[Verwijderd]

PlatformNotSupportedException anyone?

Ik wilde hier eerst een heel verhaal ophangen. Door mijn hoofd flitsen zaken als OSS, lock-ins, evil Bill, het gegeven dat J2EE niet in essentie complex is maar voor sommige overweldigend omdat er zoveel keuzes (stacks) te maken zijn, etc. Maar zijn hier niet gewoon ergens wat cijfertjes van?

[Mars Warrior]

Tja, een lastige doch interessante discussie

Bij onze klanten zie ik een tweetal stromingen:
1. Zij die expliciet voor Java/J2EE kiezen
2. Zij die ooit voor Java/J2EE kozen, en nu vanuit de business (kosten, onderhoud) voor een overstap naar .NET kiezen

Naast deze keuze zie ik vanuit de techniek / J2EE ontwikkelaars een totaal ander iets, iets dat wel eens wat sarcastisch kan overkomen, nl:
Geef twee teams, een in .NET, de ander in Java/J2EE de opdracht om voor een systeem gedurende een maand een initiele opzet neer te zetten die aan de klant gedemood moet worden:
1. Het .NET team komt na die maand met prototypes aan
2. Het Java/J2EE team komt met een dik architectuurdocument aan met daarin een 20-lagen structuur die vervolgens met hand en tand verdedigd wordt...

Hoewel ik het er persoonlijk mee eens ben dat J2EE complex is, de architecten het ook nog eens nodeloos complex weten te maken...

Een voorbeeld hiervan is te vinden in de PetStore: de Java/J2EE versie is puur architectuur gedreven en toont een enorm verschil met de .NET versie, die functioneel hetzelfde doet, maar "It is necessary to acknowledge well that it is difficult to reproduce all the architectural concepts of Java PetStore with 10 classes and 7 times less code. The Serviced Component API is possibly less verbose than the Enterprise JavaBeans API , the syntax of C# is undoubtedly more concise than its Java counterpart, but it is a advisable reason to keep, te lezen op deze site.

Dus:
1. Even los van de architectuur punten (dwz juist of niet) gaat het mij om het voorbeeld wat ik hierboven heb aangegeven, dat nl wederom "bewezen" (men verdedigd zich vanuit architectuur punten) wordt...
2. Indien de applicaties functioneel hetzelfde doen (en de klant tevreden is), dan kan het niet anders zijn dan dat de Java/J2EE versie vele malen duurder is (7x meer code) dan de .NET versie, hetgeen weer valt binnen de stelling van klanten dat .NET goedkoper is in ontwikkelen en dus ook in het onderhoud (dat meestal een percentage is van de bouw).
3. Het is op deze manier ook niet vreemd dat Java/J2EE applicaties trager zijn dan .NET. Wij hebben meermaals verschillen gemeten van ruim een factor 10 in performance nadat we onderdelen van een systeem mochten overzetten van Java/J2EE naar .NET op advies van een extern bedrijf dat in zijn rapport aangaf dat "...de performance problemen niets dan logisch zijn [met de J2EE applicatie] als gekozen wordt om voor het wijzigen van 1 getal in de database 10 lagen en 20 objecten te moeten doorlopen...".

[Alarmnummer]

Mars Warrior schreef op vrijdag 14 juli 2006 @ 12:59:
Tja, een lastige doch interessante discussie

Bij onze klanten zie ik een tweetal stromingen:
1. Zij die expliciet voor Java/J2EE kiezen
2. Zij die ooit voor Java/J2EE kozen, en nu vanuit de business (kosten, onderhoud) voor een overstap naar .NET kiezen

Je hoeft niet altijd aan zware en lompe technieken vast te zitten. Check het Spring platform en Hibernate bv eens.

1. Het .NET team komt na die maand met prototypes aan
2. Het Java/J2EE team komt met een dik architectuurdocument aan met daarin een 20-lagen structuur die vervolgens met hand en tand verdedigd wordt...

Dat hoeft niet zo te zijn. Agile technieken zijn hot in Java land, check nog een keer Spring en Hibernate.

Hoewel ik het er persoonlijk mee eens ben dat J2EE complex is, de architecten het ook nog eens nodeloos complex weten te maken...

Als je je aan de Sun specs wilt houden dan is dit vaak waar.

Een voorbeeld hiervan is te vinden in de PetStore: de Java/J2EE versie is puur architectuur gedreven en toont een enorm verschil met de .NET versie, die functioneel hetzelfde doet, maar "[i]It is necessary to acknowledge well that it is difficult to reproduce all the architectural concepts of Java PetStore with 10 classes and 7 times less code.

Ik wil de vergelijking nog wel eens zien tussen Agile frameworks zoals Spring/Hibernate en .NET. En dan wil ik dezelfde vergelijking nog wel eens zien tussen Agile java frameworks vs Agile .NET frameworks (zoals NHibernate/Spring.NET).

2. Indien de applicaties functioneel hetzelfde doen (en de klant tevreden is), dan kan het niet anders zijn dan dat de Java/J2EE versie vele malen duurder is (7x meer code) dan de .NET versie, hetgeen weer valt binnen de stelling van klanten dat .NET goedkoper is in ontwikkelen en dus ook in het onderhoud (dat meestal een percentage is van de bouw).

Nog maals.. niet alles hoeft via de Sun specs te gaan. Spring is erg lightweight en alhoewel je soms wel iets meer complexiteit hebt omdat je meer keuzes hebt, kan je enorm snel iets uit de grond stampen dat voorspelbaar en van hoge kwaliteit is.

3. Het is op deze manier ook niet vreemd dat Java/J2EE applicaties trager zijn dan .NET. Wij hebben meermaals verschillen gemeten van ruim een factor 10 in performance nadat we onderdelen van een systeem mochten overzetten van Java/J2EE naar .NET op advies van een extern bedrijf dat in zijn rapport aangaf dat "...de performance problemen niets dan logisch zijn [met de J2EE applicatie] als gekozen wordt om voor het wijzigen van 1 getal in de database 10 lagen en 20 objecten te moeten doorlopen...".

Woehoe.. generaliserende uitspraken. Ik durf te wedden dat ik met mijn keuze aan java api's een net zo snelle applicatie neer kan zetten als in .NET. Je moet gewoon niet al die Sun meuk gebruiken. Dat is ook de reden waarom er in de java wereld dus een beetje een scheiding is:
Agile/Lightweight vs Sun specs.

[ Voor 3% gewijzigd door Alarmnummer op 14-07-2006 13:47 ]

[Not Pingu]

Alarmnummer schreef op woensdag 12 juli 2006 @ 07:10:
.NET heeft het voordeel van weinig opties. Dus als jij een schroef in de muur moet krijgen en je hebt alleen een hamer, dan is de keuze vrij eenvoudig.

Leg uit? Je gaat wel tekeer tegen mensen die nadelig over Java spreken, maar baseer je je eigen uitspraken wel op jarenlange ervaring met .NET?

[Hydra]

RedRose schreef op donderdag 13 juli 2006 @ 19:28:
[over ons windows gebaseerd zijn]

Dat heeft hier geen invloed op. Wij volgen de klant, niet andersom. Wij leveren backend software met custom koppelingen. Het maakt voor ons geen fluit uit wat de klant wil.

[Castor385]

JKVA schreef op dinsdag 11 juli 2006 @ 21:48:

Nu laat ik me (als J2EE-er) niet uit het veld slaan door één verhaaltje op een site, maar deze week lees ik ook op het intranet van mijn werkgever een column van iemand anders die er ook zo over denkt. (is onder andere één van de auteurs van de UML standaard, dus weet wel één en ander)

Ik lees vandaag toevallig een zelfde verhaal. Wellicht is dit het zelfde artikel waar jij het over hebt: "Programmeren is te moeilijk". Ik kan me deels vinden in de stellingen die de auteur poneert. Zo vind ik ook dat J2EE nodeloos ingewikkeld is geworden door het gebruik van honderden verschillende frameworks. Ik kan me goed voorstellen dat het voor de nieuwbouwers onder ons nog enigszins bij te benen is, omdat je daar vaak gebruik maakt van een selecte set frameworks. Waar je dan weer een aantal maanden in project verband mee werkt. Ik ben echter werkzaam op een beheer afdeling. Ondertussen heb ik in een jaar tijd een applicatie of 10 voor mijn neus gehad. Daarbij komen zoveel verschillende frameworks, libraries en andere hulpstukken aan bod dat ik ondertussen door de bomen het bos niet meer kan zien. Zo moet ik spring, struts, hibernate, toplink, jfor, 5 verschillende JDKs, ant, JAXB, Junit, clover, jmeter, cactus, quartz, fop, xslt, xsd, xml, itext, rtf, etc etc. beheersen waardoor je haast zou vergeten dat ik me ook nog eens verdiepen in alle businesslogica van de 10 applicaties waarvoor weer verschillende branche kennis voor benodigd is.

Nee, J2EE is verre van simpel. Ik vind dat er ondertussen veel te veel aandacht wordt besteed aan de gebruikte techniek en dat het uiteindelijke resultaat steeds minder hoog in het vaandel is komen te staan.

[Mars Warrior]

Alarmnummer schreef op vrijdag 14 juli 2006 @ 13:45:
[...]

<Heel mooi verhaal over Agile technieken en Sun richtlijnen lompheid>

[...]

Eigenlijk raak je hier denk ik de kern van het probleem (wat ik eigenlijk indirect aangaf), nl dat:

• De richtlijnen van Sun min of meer (mogelijk) de veroorzaker zijn van stempels als complex, traag, omslachtig, duur in bouw, duur in onderhoud
• Agile technieken met lichte frameworks als Spring mogelijk de redder zijn van J2EE
• Het de vraag is of bedrijven dit inzien en hierop overschakelen, of waaraan ik eigenlijk refereerde het J2EE platform uitfaseren en overstappen op .NET (al dan niet met een framework als Spring)

Ik wil de vergelijking nog wel eens zien tussen Agile frameworks zoals Spring/Hibernate en .NET. En dan wil ik dezelfde vergelijking nog wel eens zien tussen Agile java frameworks vs Agile .NET frameworks (zoals NHibernate/Spring.NET).

De eerste hebben wij in een klein project al eens getest en .NET wint dat met vlag en wimpel. Het waarom is overigens simpel en doet niets af aan de kwaliteit en het gemak van Spring: Er wordt zwaar geleund op proxies, objectwrappers en reflectie (method aanroepen, properties set/get etc.) en dat zal het altijd verliezen (percentage hangt af van het gebruik) van meer directe aanroepen, waarbij overigens dezelfde ontwerp aanpak met bijv. DI/IoC is gebruikt.

De tweede zou heel leuk zijn, maar ben ik nog niet tegengekomen

maw ben het op grote lijnen met je eens

Wat ik me enkel afvraag is of dit de TS nu verder helpt in het beantwoorden van zijn vraag, want daar wordt gesteld dat SOA het mes in de rug van J2EE is, naast de complexiteit van J2EE...

[Alarmnummer]

[b][message=26135395,noline]Mars Warrior schreef op vrijdag 14 juli 2006 @ • Het de vraag is of bedrijven dit inzien en hierop overschakelen, of waaraan ik eigenlijk refereerde het J2EE platform uitfaseren en overstappen op .NET (al dan niet met een framework als Spring)

Java is zeker niet uitgefaseerd, Java is in veel professionele omgevingen de norm zoals Unix dat ook is. En Java zal op korte termijn ook zeker niet gaan verdwijnen. Het moet gewoon wat groeistuipen door en er zullen er gegarandeerd ook nog veel gaan komen. Het is een geweldig innovatief platform met een paar goeie standaards.

De eerste hebben wij in een klein projet al eens getest en .NET wint dat met vlag en wimpel.

Vreemde conclusie. Ik zou eerder concluderen dat .NET en Java dan gelijkwaardige tegenstanders zijn aangezien dan alleen het onderliggende platform anders is (hiermee bedoel ik niet slechter).

En dan zou ik zelf nog in favour zijn voor Java omdat de .NET branches hoogstwaarschijnlijk achter de ontwikkelingen van het orginele java product gaan lopen.

Het waarom is overigens simpel en doet niets af aan de kwaliteit en het gemak van Spring: Er wordt zwaar geleund op proxies, objectwrappers en reflectie (method aanroepen, properties set/get etc.) en dat zal het altijd verliezen (percentage hangt af van het gebruik) van meer directe aanroepen, waarbij overigens dezelfde ontwerp aanpak met bijv. DI/IoC is gebruikt.

Deze moet je me nog een keer goed uitleggen.

Wat ik me enkel afvraag is of dit de TS nu verder helpt in het beantwoorden van zijn vraag, want daar wordt gesteld dat SOA het mes in de rug van J2EE is, naast de complexiteit van J2EE..

Soa is oa een manier om systemen op te gaan zetten.
Deze systemen moeten draaien op een platform zoals .NET/Java.
Maw: de SAO heeft Java of .NET nodig als omgeving om op te draaien.

je sao is je tcp
en je platform is je ip

[ Voor 23% gewijzigd door Alarmnummer op 15-07-2006 10:39 ]

[JKVA]

Castor385 schreef op vrijdag 14 juli 2006 @ 15:14:
[...]
Ik lees vandaag toevallig een zelfde verhaal. Wellicht is dit het zelfde artikel waar jij het over hebt: "Programmeren is te moeilijk".

Idd, ik bedoelde die column.

Mars Warrior schreef op vrijdag 14 juli 2006 @ 17:06:
[...]
Wat ik me enkel afvraag is of dit de TS nu verder helpt in het beantwoorden van zijn vraag, want daar wordt gesteld dat SOA het mes in de rug van J2EE is, naast de complexiteit van J2EE...

Ehm, ik gooide dit artikel voornamelijk als voorbeeld in de groep. Niet zo zeer door het SOA verhaal, maar meer de complexiteit van J2EE, hoewel SOA het wel gemakkelijker maar om J2EE uit te faseren, mocht daar interesse in zijn.