[ALG] .NET versus J2EE

[Woudloper]

Ik zat mij vandaag eens af te vragen wat nou daadwerkelijk de verschillen zijn tussen de .NET architectuur van Microsoft en de J2EE architectuur van SUN.

Qua architectuur streven ze beide dat ze OO zijn, en dat zal nu toch wel zo zijn? Het is zo dat Java en C# alletwee in weze afstammen van C.

Naar mijn weten is het zo dat .NET een heel arsenaal aan technologieën bevat (zoals C#, VB.NET, ASP.NET, etc), maar welke technologieën bevat J2EE welke hieraan vergelijkend zijn? * Woudloper is niet zo heel erg thuis in J2EE

Daarnaast vroeg ik mij af hoe het zit met de snelheid van een applicatie welke ontwikkeld is op basis van de .NET architectuur en op basis van J2EE? Is daar een groot verschil tussen of maakt dat in weze niet uit? M.a.w. wat doet een bedrijf/persoon er toe overwegen om met één van beide aan de gang te gaan...

[mbravenboer]

Woudloper: Qua architectuur streven ze beide dat ze OO zijn, en dat zal nu toch wel zo zijn?

IMHO heb je gelijk. Velen zouden nu over me heen vallen en beweren dat .NET meerdere paradigma ondersteunt. Dat is inderdaad waar.... maar... De libraries van .NET zijn object-georienteerd opgezet. Alle imperatieve talen die goed in het .NET Framework passen zijn ".NETified": Java, VB .NET, C++.

De intructie-set van de Intermediate Language (IL) van .NET is een stuk uitgebreider (beter?) dan de Java Bytecode. Java Bytecode is een enorme 1:1 mapping van Java en ik beschouw dat eigenlijk altijd maar als een equivalent van Java. Als je dus een andere taal naar Java Bytecode wilt gaan compileren kan je eigenlijk net zo goed naar Java compileren.

Voor .NET is het naar mijn mening een vervelende situatie: de IL is een stuk beter berekend op andere paradigma's zoals functioneel programmeren. De kern van de het probleem bij samenwerken tussen paradigma's is echter nog steeds niet opgelost: de libraries. Het is te kort door de bocht om te stellen dat je een bepaalde library zomaar op een intuitieve manier kunt gebruiken vanuit elke paradigma. Daarom zie je ook dat alle talen aangepast worden om goed in .NET te passen.

Het is zo dat Java en C# alletwee in weze afstammen van C.

Ach, het zijn allemaal imperatieve talen.

maar welke technologieën bevat J2EE welke hieraan vergelijkend zijn? * mbravenboer is niet zo heel erg thuis in J2EE

Voordat je thuis wilt raken in J2EE moet je eerst thuis zijn in J2SE imho. Het gehele Java Platform heeft echter vrijwel geen beperkingen qua mogelijke toepassingen van technologie. Je kunt met behulp van JSP/Servlets server-side applicaties maken. Er zijn uitstekende XML parsers standaard in Java. XSLT is standaard beschikbaar. Web-services libraries zijn op dit moment in early-access of al afgerond. In tegenstelling tot .NET is de hele gedachte van web-services minder geintegreerd in het platform. Het zijn gewoon libraries die apart beschikbaar zijn. Verder is er sinds kort een mogelijkheid voor XML serializatie van Java Beans. Ook kan je standaard werken met Corba (wat Microsoft niet wil kennen). Database toegang gebeurt platform-onafhankelijk met JDBC. GUIs kan je schrijven met Swing.

Kortom: de keuze is reuze .

Het grote verschil is echter dat Java al bewezen platform-onafhankelijk is en al enkele jaren meegaat op Mac OS X, MS Windows, Linux, Solaris, FreeBSD enzovoorts. .NET is tot nu toe alleen in theorie platform-onafhankelijk. Het zal heel lang duren voordat dat ook daadwerkelijk is gerealiseerd.

Daarnaast vroeg ik mij af hoe het zit met de snelheid van een applicatie welke ontwikkeld is op basis van de .NET architectuur en op basis van J2EE?

Java gebruikt net als .NET een just-in-time compiler om de intermediate language om te zetten naar native code. Bij Java worden applicaties over het algemeen in mixed-mode uitgevoerd: interpretatie in combinatie met native code. Bij .NET is er ook een just-in-time compiler, maar in principe voert .NET alleen native code uit. In latere releases zal deze native code gecached gaan worden zodat niet elke keer opnieuw de compilatie van IL naar native code gedaan zal moeten worden.

[Tomatrix]

Even nog een vraagje:
Heeft .NET eigenlijk een tegenhanger voor EJB's? Oftewel een gedistribueerde component technologie? Speelt DCOM hier nog een rol of wordt alles nu via webservices afgehandeld. En zo ja, hoe is het dan geregeld met persistence en transactions e.d.?

[Woudloper]

mbravenboer:

Voordat je thuis wilt raken in J2EE moet je eerst thuis zijn in J2SE imho.

Denk niet dat ik thuis wil raken in J2EE (of J2SE) Momenteel bevalt het mij nog wel mbt VB, ASP, HTML, JavaScript....

Het grote verschil is echter dat Java al bewezen platform-onafhankelijk is en al enkele jaren meegaat op Mac OS X, MS Windows, Linux, Solaris, FreeBSD enzovoorts. .NET is tot nu toe alleen in theorie platform-onafhankelijk. Het zal heel lang duren voordat dat ook daadwerkelijk is gerealiseerd.

Dan hebben we het nu toch over het algemeen over Web based applicaties? Of niet? Ik kan even niet zoveel voorbeelden vinden van applicaties welke op meerdere platformen draaien... Je ziet wel vaak applicaties voorbijkomen die geschreven zijn in VB, C++, Delphi, etc... Maar Java? Nee, die heb ik nog niet gezien. Ik kan mij natuurlijk wel vergissen

Java gebruikt net als .NET een just-in-time compiler om de intermediate language om te zetten naar native code. Bij Java worden applicaties over het algemeen in mixed-mode uitgevoerd: interpretatie in combinatie met native code. Bij .NET is er ook een just-in-time compiler, maar in principe voert .NET alleen native code uit. In latere releases zal deze native code gecached gaan worden zodat niet elke keer opnieuw de compilatie van IL naar native code gedaan zal moeten worden.

Kan je hier iets meer over vertellen (ik bedoel dat compilen)? Of zeggen waar ik hier meer over kan vinden! Zou er gewoon graag iets meer over willen weten....

Hoe ziet het dan nog met de performance? Ik dacht dat er afgelopen week een artikeltje (column) in de Automatiseringgids had gestaan waarin een onderzoek werd aangehaald dat .NET sneller was dan J2EE... Alleen de meetmethode was geloof ik een beetje omstreden...

[Tomatrix]

Op maandag 04 februari 2002 17:53 schreef Woudloper het volgende:

[..]

Denk niet dat ik thuis wil raken in J2EE (of J2SE) Momenteel bevalt het mij nog wel mbt VB, ASP, HTML, JavaScript....

tsk, tsj, j2ee is wel wat meer dan VB/ASP/HTML, het is een volledige specificatie van een infrastructuur voor het schrijven van enterprise applicaties. En ja, het heeft ook voorzieningen voor een webinterface.

Dan hebben we het nu toch over het algemeen over Web based applicaties? Of niet? Ik kan even niet zoveel voorbeelden vinden van applicaties welke op meerdere platformen draaien...

Op de desktop kom je (helaas) weinig Java applicaties tegen. Java heeft de laatste tijd dan ook vooral faam gemaakt aan de server kant. Je moet hierbij dan denken dat je bijvoorbeeld een windows ontwikkelserver hebt, en dat je vervolgens de binaries over zet op, pak 'm beet, een leuke SUN bak met solaris daarop.

Overigens enige voorbeelden van applicaties die dankzij java binary compatible zijn (dus gecompileerde versie draait zowel op linux/windows/etc.):
- TogetherJ
- Forte 4 Java
- JBuilder (?)
- IntelliJ
Dit zijn stuk voor stuk krachtige IDE's. Java maakt op dit moment het Write Once Run Everywhere pincipe waar, voor .NET is dit absoluut (nog) niet het geval.

Hoe ziet het dan nog met de performance? Ik dacht dat er afgelopen week een artikeltje (column) in de Automatiseringgids had gestaan waarin een onderzoek werd aangehaald dat .NET sneller was dan J2EE... Alleen de meetmethode was geloof ik een beetje omstreden...

IBM/SUN liggen de afgelopen weken nogal in de clinch met microsoft over de zogenaamde petstore applicatie. Dit is een door SUN ontwikkelde enterprise applicatie die als voorbeeld dient voor developers hoe een J2EE applicatie te ontwikkelen. Microsoft heeft deze zelfde applicatie nagebouwd in .NET en beweerd vele malen sneller te zijn, minder code te vergen, en sneller te zijn ontwikkeld dan de Java tegenhanger. Beide partijen gebruiken echter de benchmarks/hardware die hen het beste uitkomt , dus daar is verder weinig over te zeggen qua performance.

[mbravenboer]

Woudloper: Denk niet dat ik thuis wil raken in J2EE (of J2SE) Momenteel bevalt het mij nog wel mbt VB, ASP, HTML, JavaScript....

De technieken die jij noemt zijn absoluut niet te vergelijken met J2EE en vormen ook niet het interessantste deel van .NET imho... Overigens kan het absoluut geen kwaad om je breder te orienteren en zo een betere kijk op je vakgebied te krijgen. Je opmerking hierboven vind ik dan ook in schril contrast staan tot je interesse die je in je oorspronkelijke post laat zijn .

Dan hebben we het nu toch over het algemeen over Web based applicaties? Of niet?

Voor een deel. Er zijn iderdaad al veel server-side applicaties die Java Servlets of JSP technologie gebruiken. In verhouding is Java maar vrij klein op de client-side.

Je ziet wel vaak applicaties voorbijkomen die geschreven zijn in VB, C++, Delphi, etc... Maar Java? Nee, die heb ik nog niet gezien. Ik kan mij natuurlijk wel vergissen

Voor interne software wordt het wel veel gebruikt omdat er dan geen JVM problemen zijn. Ook zijn er ontzettend veel goede ontwikkelingstools, die niet alleen op Java ontwikkeling gericht zijn.

Kan je hier iets meer over vertellen (ik bedoel dat compilen)? Of zeggen waar ik hier meer over kan vinden! Zou er gewoon graag iets meer over willen weten....

Tja er zijn zoveel bronnen. Ik heb op GoT al een paar keer wat slides over .NET jitters gepost. Van Java kan je enorm veel vinden op het web.

Hoe ziet het dan nog met de performance? Ik dacht dat er afgelopen week een artikeltje (column) in de Automatiseringgids had gestaan waarin een onderzoek werd aangehaald dat .NET sneller was dan J2EE...

Mwah, die automatiseringsgids verhalen zou ik maar niet al te serieus nemen . Testjes zijn ook nog zo heel erg interessant, je moet eerst eens bekijken wat de fundamentele verschillen in opzet zijn. Op dit moment zijn die naar mijn mening nog vrij klein omdat allebei de platformen voor elke executie JIT compilers gebruiken. Uiteraard zal de ene het beter of anders aanpakken dan de andere, maar de essentie is hetzelfde. Het is nog sterk afwachten wat er gaat gebeuren met de performance als .NET ook daadwerkelijk JIT gecompileerde code gaat cachen. Tegen die tijd zal Java echter ook al JVM sharing hebben, wat al veel problemen oplost.

Feit is in ieder geval dat Microsoft een enorme smak uitstekende ontwikkelaars rond heeft lopen. Niet voor niets was de JVM van Microsoft een van de snelste JVMs (niet dat het een acceptabele oplossing is). Bovendien kan Microsoft bouwen op een hun eigen operating system en kennen ze uitermate goed alle zaken die belangrijk zijn op hun OS.

Ik zie .NET zelf dan ook als een aantrekkelijke kijk op het MS Windows Platform. Dat dat platform-onafhankelijk te maken is, is tot nu toe een irrelevant voordeel. Voorlopig zal niemand er in slagen om een acceptabele port te maken voor andere besturings-systemen ( met ADO .NET, .NET WinForms enz.).

[mbravenboer]

Tomatrix: Heeft .NET eigenlijk een tegenhanger voor EJB's? Oftewel een gedistribueerde component technologie? Speelt DCOM hier nog een rol of wordt alles nu via webservices afgehandeld. En zo ja, hoe is het dan geregeld met persistence en transactions e.d.?

.NET Remoting (wat je het gedistribueerde object systeem van .NET kunt noemen) werkt via SOAP en is dus in feite 1 grote web-service. Transacties etc worden hier allemaal in ondersteunt. Hoe dat precies in verhoudig staat tot EJB weet ik niet omdat ik helaas meer verstand heb van .NET Remoting dan van EJB .

Overigens kan .NET Remoting voor grote verassingen zorgen als je daarmee bezig bent . Er vindt namelijk geen communicatie plaats als je een stub aanvraagt naar een remote object. Hierdoor kan er dan in feite nooit vanuit gaan dat je ook daadwerkelijk een goede stub in handen hebt. Je kunt deze zogenaamde stub ook naar alles casten . Ik weet niet precies hoe ze dit gedaan hebben, maar ik vermoed dat ze at-runtime stubs generen aan de hand van de klasse waarnaar je cast. Je werkt ook niet meer met interfaces (overal kan je gewoon een stub van maken) en dat vind ik eigenlijk vrij onprettig werken. Vooral ook omdat de client-side dan niet via een interface werkt en dus een implementatie moet hebben. Dat werkt dus allemaal nog niet helemaal soepel.

[whoami]

Op maandag 04 februari 2002 17:53 schreef Woudloper het volgende:

Kan je hier iets meer over vertellen (ik bedoel dat compilen)? Of zeggen waar ik hier meer over kan vinden! Zou er gewoon graag iets meer over willen weten....

In een notedop:
Bij .NET wordt uw (VB.NET, C# whatever) programma gecompileerd naar de IL (Intermediate Language).
Bij het opstarten van dat programma gaat de CLR (Common Language Runtime) de JIT (Just In Time) compiler gaan lanceren die de IL gaat gaan compileren naar de native instruction set van de machine waarop het draait.

[whoami]

Op maandag 04 februari 2002 18:44 schreef mbravenboer het volgende:

Tja er zijn zoveel bronnen. Ik heb op GoT al een paar keer wat slides over .NET jitters gepost. Van Java kan je enorm veel vinden op het web.

Idd, zie oa de topics
[topic=398832/1/25]

en

[topic=398651]

Voorlopig zal niemand er in slagen om een acceptabele port te maken voor andere besturings-systemen ( met ADO .NET, .NET WinForms enz.).

Waarom denk je dat? Is dat niet een beetje voorbarig? Waarop baseer je die mening?

[Verwijderd]

Op maandag 04 februari 2002 19:09 schreef whoami het volgende:

Waarom denk je dat? Is dat niet een beetje voorbarig? Waarop baseer je die mening?

Als je de voortgang van dat Mono project bekijkt lijkt die mening helaas terecht .
Aan ADO.Net en WinForms _beginnen_ ze voorlopig nog geen eens .
Verder is het natuurlijk een ontzettend &#$&*^$# werk om al die tig-duizend klassen te gaan herprogrammeren... lijkt me echt onmogelijk, maar laten we hopen dat het wat wordt .

[whoami]

Op maandag 04 februari 2002 19:25 schreef KoenM het volgende:

Verder is het natuurlijk een ontzettend &#$&*^$# werk om al die tig-duizend klassen te gaan herprogrammeren... lijkt me echt onmogelijk, maar laten we hopen dat het wat wordt .

Als ze dat voor .NET Moeten doen, hebben ze dat toch voor Java ook moeten doen?

[Verwijderd]

Op maandag 04 februari 2002 19:27 schreef whoami het volgende:

Als ze dat voor .NET Moeten doen, hebben ze dat toch voor Java ook moeten doen?

Maar Java is op een manier opgezet die rekening houdt met het feit dat het op meerdere OS'sen moet kunnen draaien. Daardoor is er geen OS specifieke code te vinden, en als dat al moest (voor AWT lijkt me) zal dat heel erg mooi op één plaats zijn gegooid zodat je er verder geen rekening mee hoeft te houden...

Bij .Net is het niet echt de bedoeling geweest de boel platform onafhankelijk te maken...
Zoals mbravenboer al een keer mooi heeft met het voorbeeld van de system directory. Hoe moet je die nou in linux implementeren :0.
Om maar één voorbeeld te noemen, zoek anders maar eens naar Mono, dan kom je het hele topic wel tegen... Dan hoeven we die discussie niet nog een keer te voeren

[mbravenboer]

whoami: Waarom denk je dat? Is dat niet een beetje voorbarig? Waarop baseer je die mening?

Op de keiharde en vervelende realiteit. Ik vertel dit niet omdat ik .NET irritant vind of wat dan ook, sterker nog: ik vind .NET fantastisch. Een grondige analyse van de verschillen in aanpak tussen het Java Platform en .NET zorgen echter voor pijnlijke conclusies....

Lees maar mee .

whoami: Als ze dat voor .NET Moeten doen, hebben ze dat toch voor Java ook moeten doen?

Er is een belangrijk verschil tussen de huidige Java 2 Runtime Environments en de .NET CLR van Microsoft: Bij Java zijn zoveel mogelijk libraries volledig platform-onafhankelijk geimplementeerd (bijvoorbeeld Swing, XML libraries). De libraries van Java bevatten dus maar heel weinig platform-specifieke code. Veel van de libraries van .NET (WinForms en ADO .NET bijvoorbeeld) zijn echter gewoon een view op de al lang bestaande native onderdelen.

Het porten van de .NET WinForms komt in feite neer op het porten van de MS Windows GUI libraries naar andere platformen. Voor een deel kan dit platform-onafhankelijk, maar dat is simpelweg nog niet gebeurd.

Het volledig implementeren van de libraries moet gewoon ontzettend veel werk zijn. In feite komt het er naar mijn mening gewoon op neer dat je een bestaand platform ombouwt naar MS Windows. Bovendien moet je dan nog maar eens zorgen dat alles compatible is. Gruwelijk veel werk dus.

AWT, de platform specifieke GUI toolkit van Java is maar zeer beperkt. Het bevat alleen wat simpele TextFields, Labels, List, Checkboxen etc. De functionaliteit is voor de meeste applicaties volstrekt ontoereikend en daarom is er Swing. Swing is in principe in 100% Java geimplementeerd en is dus bruikbaar op alle platformen als er maar een JVM is. Overigens kan je in Swing ook native code gebruiken. Voor de J2RE van MacOS X hebben ze bijvoorbeeld een native Look and Feel voor Swing gemaakt.

Mono schiet inderdaad totaal niet op. De ideeen zijn heel leuk maar het kernwoord voor succesvolle platform-onafhankelijk is >libraries<. Uiteraard moeten deze libraries echter ook nog compatible zijn en als ik zie dat Mono werkelijk elk detail opnieuw gaat implementeren houd ik daarvoor mijn hart vast. Vergeet niet dat het grootste deel van de .NET libraries helemaal niet gestandaardiseerd is!

Het bouwen van een C# compiler en een jitter is geen enkel punt. Dat kan iedereen wel met wat inspanning en ervaring. Maar daar hebben we in de praktijk helemaal niets aan.

Moet je voor de grap eens Mono downloaden en kijken wat ze al geimplementeerd hebben. Kijk dan ook eens in de source en schrik je te pletter: alles is zelf geschreven en er is nog vrijwel niets af. Logisch.

Alleen een project wat volledig door Microsoft wordt gesteund met zowel informatie als grote hoevelheden developers kan ooit een succesvolle en volledig implementatie maken die op kan tegen het .NET Framework voor MS Windows.

Merk je overigens hoe slim de aanpak is? Ze maken een platform-onafhankelijk view op hun eigen libraries en verklaren die view platform-onafhankelijk. Ze hebben nu zonder al te veel moeite een zeer goede implementatie en ze kunnen voorlopig andere besturingssystemen de schuld geven van het gebrek aan een goede .NET implementatie.

.NET is mooi voor MS Windows ontwikkeling, maar voorlopig vind ik zowel de samenwerking tussen paradigma's als de platform-onafhankelijkheid grote sprookjes.

Over die samenwerking tussen paradigma's nog iets grappigs: zoals je wellicht weet zal er waarschijnlijk een Haskell compiler voor IL komen. Je kunt dan dus vanuit Haskell de .NET libraries gebruiken. Haskell is echter een pure functionele taal. Dit betekent dat er bijvoorbeeld geen 'state' is. Niets in Haskell heeft bijvoorbeeld side-effects. Alles is een functie. Neem nu eens een procudure. Een procedure heeft geen resultaat en is dus alleen zinvol als die procedure side-effects heeft. De .NET library barst uiteraard van de procedures. Nu moet je vanuit Haskell dus procedures gaan gebruiken! Voorlopig moet ik dat dus eerst nog zien en zorgvuldig beoordelen.

[Verwijderd]

Op maandag 04 februari 2002 20:00 schreef mbravenboer het volgende:
Over die samenwerking tussen paradigma's nog iets grappigs: zoals je wellicht weet zal er waarschijnlijk een Haskell compiler voor IL komen. Je kunt dan dus vanuit Haskell de .NET libraries gebruiken.

Is hier nu al concreets over bekend? Want op internet is er helemaal niks over te vinden En het idee lijkt me wel leuk . Maar idd. eerst zien en dan pas geloven...

[mbravenboer]

KoenM: Is hier nu al concreets over bekend? Want op internet is er helemaal niks over te vinden En het idee lijkt me wel leuk . Maar idd. eerst zien en dan pas geloven...

* mbravenboer is ook nog steeds onwetend . Behalve dat het overal wordt genoemd in praatjes heb ik nog nergens examples of concrete code gezien.

Ik ken alleen Mondrian en dat stemt mij in ieder geval niet erg vrolijk.

[mbravenboer]

Hier een man die er behoorlijk wat mee te maken heeft (en duidelijk geinspireerd is door Mondriaan ):

http://research.microsoft.com/~dsyme/
http://research.microsoft.com/~dsyme/net.htm

Zie ook hier:

http://www.haskell.org/pipermail/haskell/2001-May/001175.html

Zie ook hier bovenaan:

http://research.microsoft.com/ppt/

Hier trouwens nog hele leuke slides over de implementatie van Generics (die pas later opgenomen zullen gaan worden )

http://www.acm.org/sigplan/pldi/pldi2001/pldi01-presentations/DonSyme.pdf

Verder geen concrete info .

[mbravenboer]

Hier trouwens ook nog interessante docs en een paper over de implementatie van functionele talen op OO-virtuele machines:

http://docs.msdnaa.net/ark/Webfiles/whitepapers.htm
http://docs.msdnaa.net/ark/Webfiles/WhitePapers/PerryAndMeijer.pdf
(vooral die laatste zal je wellicht leuk vinden).

Deze is ook wel leuk volgens mij (waarschuwing: geschreven door Erik Meijer ).
http://systems.cs.colorado.edu/Groups/ARG/Papers/clr.pdf

[mbravenboer]

Ik heb even wat door zitten lezen en ik vermoed dat ze wachten met het uitbrengen van Haskell compilers totdat .NET ook Generics gaat ondersteunen. Voor het compileren van functionele talen zijn Generics eigenlijk onmisbaar en in de eerste versie van .NET is dat dus niet mogelijk. Een compiler uitbrengen zou wel mogelijk zijn, maar dit zou barsten van de casts en work-arounds.

Ik denk dus dat we voorlopig helemaal niets te zien krijgen. Ik zag ergens .NET 2.0 staan . Geen idee wanneer dat moet komen overigens.

[Verwijderd]

Op maandag 04 februari 2002 22:30 schreef mbravenboer het volgende:
Ik heb even wat door zitten lezen en ik vermoed dat ze wachten met het uitbrengen van Haskell compilers totdat .NET ook Generics gaat ondersteunen. Voor het compileren van functionele talen zijn Generics eigenlijk onmisbaar en in de eerste versie van .NET is dat dus niet mogelijk. Een compiler uitbrengen zou wel mogelijk zijn, maar dit zou barsten van de casts en work-arounds.

Ik denk dus dat we voorlopig helemaal niets te zien krijgen. Ik zag ergens .NET 2.0 staan . Geen idee wanneer dat moet komen overigens.

Wat houden die Generics precies in? Ik heb nog geen tijd gehad om bovenstaande links te volgen, maar wordt het daarin uitgelegd

Ik hoop trouwens niet dat MS met de snelheid van windows .Net updates gaat uitbrengen, want elke zoveel maanden weer een nieuwe (/aangepaste) API lijkt me niet echt makkelijk
Gelukkig gaat MS wel wat guller om met de release versie, want dat Java nog steeds pas bij 1.4 is klinkt zo lullig, dan kan je beter versie 4.0 XP TM R C bla bla bla hebben

[Woudloper]

Tomatrix:
tsk, tsj, j2ee is wel wat meer dan VB/ASP/HTML, het is een volledige specificatie van een infrastructuur voor het schrijven van enterprise applicaties. En ja, het heeft ook voorzieningen voor een webinterface.

mbravenboer:
De technieken die jij noemt zijn absoluut niet te vergelijken met J2EE en vormen ook niet het interessantste deel van .NET imho... Overigens kan het absoluut geen kwaad om je breder te orienteren en zo een betere kijk op je vakgebied te krijgen. Je opmerking hierboven vind ik dan ook in schril contrast staan tot je interesse die je in je oorspronkelijke post laat zijn .

Ik geloof dat ik mij hier niet helemaal duidelijk heb uitgedrukt... Ik zou graag meer willen weten over het concept en zo, maar had niet de behoefte om J2EE te leren. Ik had momenteel al genoeg aan bovengenoemnde onderdelen.

Maar om te kijken wat nou daadwerkelijk de verschillen waren tussen de twee platformen stelde in allereeste vraag.

whoami:
In een notedop:
Bij .NET wordt uw (VB.NET, C# whatever) programma gecompileerd naar de IL (Intermediate Language).
Bij het opstarten van dat programma gaat de CLR (Common Language Runtime) de JIT (Just In Time) compiler gaan lanceren die de IL gaat gaan compileren naar de native instruction set van de machine waarop het draait.

Thanx, weet ik dat ook weer....

mbravenboer:
Het volledig implementeren van de libraries moet gewoon ontzettend veel werk zijn. In feite komt het er naar mijn mening gewoon op neer dat je een bestaand platform ombouwt naar MS Windows. Bovendien moet je dan nog maar eens zorgen dat alles compatible is. Gruwelijk veel werk dus.

Met dat in het achterhoofd denk ik niet dat de andere platform gebruikers daar heel erg blij mee zullen zijn Maar het idee staat mij echter wel aan..

Ik denk dus dat we voorlopig helemaal niets te zien krijgen. Ik zag ergens .NET 2.0 staan . Geen idee wanneer dat moet komen overigens.

Grapje zeker.... Ik dacht dat .NET eigenlijk te zien was als o.a. een nieuwe versie voor VS6 en dat je het meer moet zien als VS7.... het ligt dan wel in de lijn der verwachtingen dat er ooit een VS8 uit gaat komen, maar denk dat ze het eerst houden bij SP's.... voor VS6 is er net nog SP5 uitgekomen....

[mbravenboer]

KoenM: Wat houden die Generics precies in? Ik heb nog geen tijd gehad om bovenstaande links te volgen, maar wordt het daarin uitgelegd

Hum, de gedachte van generics niet echt... Wat dat betreft kan je beter de link in mijn signature even volgen en de Java Generics bekijken.

Het gaat om geparameterizeerde typen (wat leidt tot parametrisch polymorphisme). Je kunt hiermee een klasse parameterizeren met een type. Dit is vooral handig voor collecties, maar er zijn veel meer handige toepassingen.

Voor Java en C# vind ik het eigenlijk onmisbaar en ik vind het dan ook heel jammer dat ze niet gelijk in de eerste release Generics hebben opgenomen. Voor Java gaan Generics voor een enorme rewrite zorgen, voor C# geldt exact hetzelfde.

Simpel voorbeeldje:

code:

List<String> strings = new ArrayList<String>();

strings.add("Blaat1");
strings.add("Blaat2");
strings.add("Blaat3");

Iterator<String> iterator = strings.iterator();
while(iterator.hasNext()) {
    String s = strings.next();
    System.out.println(s);
}

Zoals je ziet is de klasse ArrayList hier geparameterizeerd met een type. In dit geval is dat een String. Operaties zoals add en get zijn gedefinieerd in termen van dat type en dus bespaar je je een hoop casts en is er betere type-checking at compile-time.

Dit zijn vooral concrete directe voordelen, maar er zijn dankzij Generics nog veel meer voordelen te behalen, zoals veel meer mogelijkheden tot polymorphisme. Generics leveren een nieuwe vorm van polymorphisme voor de OO: parametrisch polymorphisme.

Deze vorm van polymorphisme wordt juist zwaar gebruikt in functionele talen en dus is dit ook voor de compilatie van functionele talen naar OO-taal een zeer goede toevoeging .

[mbravenboer]

Woudloper: Grapje zeker.... Ik dacht dat .NET eigenlijk te zien was als o.a. een nieuwe versie voor VS6 en dat je het meer moet zien als VS7.... het ligt dan wel in de lijn der verwachtingen dat er ooit een VS8 uit gaat komen, maar denk dat ze het eerst houden bij SP's.... voor VS6 is er net nog SP5 uitgekomen....

Ik had het hier over een mogelijke Haskell compiler voor .NET IL, niet over een .NET CLR of een IDE.

.NET staat trouwens los van Visual Studio .NET. Er is een soort runtime, een gratis SDK en een joekel van IDE. Alle drie verschillende zaken .

[whoami]

[b]Op dinsdag 05 februari 2002 09:48 schreef mbravenboer iets over Generics

Als ik het goed snap (heb de post maar vluchtig gelezen, heb niet veel tijd), zijn die Generics voor Java eigenlijk wat templates zijn voor C++?

[mbravenboer]

whoami: Als ik het goed snap (heb de post maar vluchtig gelezen, heb niet veel tijd), zijn die Generics voor Java eigenlijk wat templates zijn voor C++?

Dat druk je wel aardig uit ja . Inderdaad kan je Generics op sommige punt wel zien als 'zijn voor Java wat templates zijn voor C++'. Je kunt op veel punten dezelfde effecten bereiken. De implementatie is echter compleet verschillend en er gelden ook wat andere regels qua semantiek en typering.

Templates zijn in feite niet echt een toevoeging van het type-systeem, terwijl de Generics zoals die in Java zullen komen (en in C# zoals het er nu naar uit ziet in grote lijnen vrijwel equivalent) dit wel zijn....

Dit is trouwens wel vaker ter sprake gekomen in P&W, als je even zoekt naar generics java en templates vind je vast wel wat .

[mbravenboer]

Hier bijvoorbeeld:

[topic=197726/2/25]
[topic=359900/1/25]
[topic=293010/1/25]

[Verwijderd]

Op maandag 04 februari 2002 21:30 schreef mbravenboer het volgende:
waarschuwing: geschreven door Erik Meijer

De smerige overloper

Ik heb die links naar Mondrian ff doorgenomen, maar dat lijkt wel verdomd veel op Haskell (gelukkig maar ) maar alleen die irritante ';' (damn )

Waarom ben je er dan toch niet zo positief over Want hier zijn ze dus al tamelijk ver mee. Wat ik zo zag over Haskell zag er nog geeneens zo slecht uit, het merendeel van de modules was al geimplementeerd, dus dat moet dan toch wel lukken hoop ik.

Wat ik me alleen nog afvraag: is zo iets als Mondriaan nou ook sneller in bv. een ASP.Net pagina dan vergelijkbare code in c#, of alleen duidelijker/mooier

[mbravenboer]

KoenM: De smerige overloper

Dat zie ik anders: op de UU was hij een wolf in schaapskleren .

Waarom ben je er dan toch niet zo positief over Want hier zijn ze dus al tamelijk ver mee. Wat ik zo zag over Haskell zag er nog geeneens zo slecht uit, het merendeel van de modules was al geimplementeerd, dus dat moet dan toch wel lukken hoop ik.

Mwah, zolang .NET geen generics heeft gaat het niet zo opschieten denk ik. Verder compileeert Mondrian op dit moment naar C#. Echte fraai is dat imho niet.

Zie ook:
[topic=386183/1/25]

Het probleem met Mondrian is volgens mij dat we het wellicht maar moeten accepteren . Mondrian is in feite ontstaan als functionele taal die bruikbaar is in combinatie met OO omgevingen. Op dit moment compileert het dus naar C#, waardoor optimalisatie vrijwel kansloos is. Functionele programma's komen zo denk ik niet toch hun recht .

Wat ik me alleen nog afvraag: is zo iets als Mondriaan nou ook sneller in bv. een ASP.Net pagina dan vergelijkbare code in c#, of alleen duidelijker/mooier

Het is vooral anders . Sommige problemen kan je heel fraai uitdrukken in hogere-orde functionele talen zoals Haskell. Dankzij de wiskundige basis en het declaratieve karakter zou je in theorie zeer goede optimalisaties uit kunnen voeren omdat je uitmuntende analyse kunt uitvoeren op de applicatie. Tot nu toe is dat echter niet echt gerealiseerd naar mijn mening en moet je er dus maar niet vanuit gaan dat functionele code sneller zal draaien dan imperatieve code. Overigens is dat sowieso kansloos als je naar C# compileert. Er worden daar ontzettend veel casts uitgevoerd om het over de ongelofelijk object-creatie nog maar niet te hebben....