Java volgend jaar meer gebruikt dan C, C++ en VB

Een onderzoek van Evans Data Corp heeft uitgewezen, dat steeds meer software-ontwikkelaars overstappen van C of C++ naar Sun's Java. Meer dan de helft van de Noord Amerikaanse programmeurs maakt al gebruik van de taal, en bovendien zal dit aantal nog behoorlijk gaan toenemen in het komende jaar. Verwacht wordt dan ook, dat Java in 2002 meer gebruikt zal worden dan de voorheen gangbaardere talen Visual Basic en C(++). Wat het motief van de software-developers is om over te stappen, is ZDNet nog onbekend.

Wat betreft Microsoft's nieuwste ontwikkelhulp, C-Sharp, is het onderzoek niet zo positief. Slechts een klein gedeelte van de IT-branche zal overstappen naar deze op .NET gebaseerde technologie. Veel reden om van programmeertaal te veranderen is er eigenlijk niet, aldus een woordvoerster van Evans:

The research also shows that Java usage has been rising at the expense of Visual Basic and C/C++. "This means that, for the first time, more North American developers will be using Java than Visual Basic or C/C++ next year," Garvin said. "Java usage is even stronger outside North America, with almost 60 percent of developers expecting to spend some part of their programming time using Java."

Initial surveys have shown that only a small portion of developers intend to try Microsoft Corp.'s C# language, which is relatively new, and those developers will predominantly be ones already using Microsoft programming languages, Garvin said. There is no evidence of any significant adoption to date, she added.

Lagune, bedankt voor de tip.

Reacties (77)

[appelsientje]

Dit vind ik wel prettig nieuw om te horen.

Dit jaar word ik namelijk vol gestopt met Java bij de hogeschool, dus heb ik eindelijk het gevoel dat ik ook echt wat nuttigs ga leren dat veel word toegepast.


Niet dat ik ook nog maar enig ervaring heb met Java.

[.oisyn]

Ik ben ook volgestopt met java op de HvU (ik had er al een hekel aan, en nu heb ik er nog steeds een hekel aan . Alleen de Applets vind ik nuttig), en ik denk ook eerlijk gezegt dat dat de reden is voor de afname van C(++) en de toename van Java, omdat leerlingen na hun school als Java-programmeur aan de bak gaan ipv als C(++)-programmeur

[Ritch]

Applets vind ik dan weer totaal niet nuttig, maar servlets, daar schijnt de echte kracht van java te liggen en daar ga ik aankomend schooljaar op school mee stoeien...

[mbravenboer]

Servlets zijn inderdaad interessant. Normaal gesproken worden servlets in tegenstelling tot CGI slechts 1 maal geinitialiseerd. Ze zijn dan ook niet state-less (ze hebben dus een state ), ook dit in tegenstelling tot CGI.

Applets zijn altijd al een vervelend probleem geval van het Java platform geweest. Met de recente beslissing van Microsoft zou dit wellicht kunnen veranderen. Sun gaat nu ook de JRE (in het bijzonder de plug-in) zo aanpassen dat deze in Internet Explorer te gebruiken is met de normale Applet tags.

Vergeet echter ook Java Web Start niet. Dit is een zeer interessante techniek die vooral geschikt is voor de wat nuttigere Java applets of applicaties via het web. Als deze niet percee in een web-pagina geintegreerd hoeven te zijn (zoals een menu of een animatie) biedt Java Web Start zeer interessante mogelijkheden. De applicaties worden via het web gestart via een launch-file. Java Web Start zorgt ervoor dat de resources uit de launch-file aanwezig zijn (inclusief de correcte versie van de VM) en checked bovendien of er nieuwe versies van de applicatie zijn. Het is ook mogelijk een via Java Web Start de applicatie off-line te gebruiken.

In de volgende versie van het Java 2 Platform: 1.4, zal Java Web Start standaard opgenomen worden. Als dat eenmaal gebeurd is, zou het een grote invloed op het client-side gebruik van Java kunnen hebben.

Als je trouwens eens wilt kijken wat er zoal mogelijk is met client-side Java, is deze site een absolute must:
http://java.sun.com/products/jfc/tsc/sightings/S1.ht ml

Je zult zien dat veel applicaties al van Java Web Start gebruik maken.

[Anoniem: 28824]

Let er echter wel op dat dit onderzoek in Amerika heeft plaatsgevonden en niet in Europa.
Hier is het aantal programmeurs dat Delphi, C(++) en VB doet vele malen groter dan Java.
Een van de redenen daarvan is dat JAVA niet makkelijk is te leren, alleen via C(++) is er een redelijk makkelijk overstap te maken, maar daarnaast is JAVA een koffie drink programma.
Je hebt dus veel geduld nodig

[mbravenboer]

Een van de redenen daarvan is dat JAVA niet makkelijk is te leren, alleen via C(++) is er een redelijk makkelijk overstap te maken

Java is een zuivere object georienteerde taal. Dit vereist een denkwijze die voor sommige mensen lastig aan te leren is. Object orientatie is echter ontstaan omdat het juist makkelijk moet zijn. De ervaring is dan ook dat veel mensen met eenvoudige OO-concepten weinig problemen hebben. Omdat Java het op veel punten een stuk gemakkelijker maakt voor de programmeur is Java dan ook voor veel mensen makkelijker te leren dan C of C++ die je vooral in het begin bezighouden met irrelevante details.

Als jij andere ervaringen hebt, is misschien het les materiaal nog niet helemaal optimaal. Meestal is dat het grootste probleem bij het leren van een OO-taal.

maar daarnaast is JAVA een koffie drink programma. Je hebt dus veel geduld nodig

Dat is een statement uit 1995 die je sindsdien bent vergeten bij te werken .

[mbravenboer]

Nee. OO is ontstaan als een andere manier van het vertalen van fuctionaliteit naar programmatuur. <knip> het is bedoelt voor het gemakkelijk maken van het schrijven van programmatuur die is bedoeld voor een data-georienteerde omgeving

Feit blijft dat object orientatie programmeren (uiteraard van bepaalde problemen) makkelijker moet maken. De verdeling in klassen met data en methoden is een denkwijze die vrij direct aansluit op de 'echte' wereld. Ik weet niet hoever je wilt gaan met 'data georienteerd', maar waarschijnlijk ben ik het hier niet helemaal met je eens. Ook voor problemen die niet direct met data te maken hebben is OO een goede oplossing. Objecten met methoden en mogelijkheden (eventueel via interfaces) zijn in het algemeen een prettige manier van werken. Het maakt het makkelijker om software op te delen in componenten en bevordert hergebruik, black box gebruik en generiek programmeren. Uiteraard blijven er problemen waarvoor je de oplossing typisch niet in de OO hoek moet zoeken.

Java is een leuke taal en een klote platform.

Waarom vind je het een klote platform? Je kan toch moeilijk ontkennen dat de Java bibliotheken (uitgezonderd AWT) zeer goed, helder en gebruiksvriendelijk zijn. De Java Collections lijken zeer veel op de verzamelingen in .NET en Swing heeft een prachtig design, waar de WinForms niet aan kunnen tippen. Ik neem aan dat je doelt op performance problemen en te grote platform onafhankelijheid, waardoor je systeem specifieke functies niet kan benaderen? Tja, voor sommige applicaties is dat nodig, maar zoals je zelf al zei is Java niet voor alles geschikt .

Dit is mislukt omdat de 2 deling: taal java vs platform java niet los gezien mag worden van Sun. Wat voor de taal adepten jammer is.

Misschien heb je daar wel gelijk in. Waarschijnlijk heeft Sun er nu ook wel spijt van dat de taal Java te sterk verbonden is aan het Java Platform. Java bytecode biedt veel meer mogelijkheden. Uiteraard zijn er veel mogelijkheden om andere talen te gebruiken, maar die worden niet door Sun gesupport. Ze moeten toch met een enigzins jaloers oog kijken naar de uitgebruidere instructie-set van CIL, waardoor er meer exotischere talen makkelijk in .NET gebruikt kunnen worden. Overigens valt dat gebruik me nog wel iets tegen, maar dat is een ander onderwerp .

Wat voor 'multiplatform-programming' wellicht nuttig is, maar in de praktijk kom je dat niet zo vaak tegen (en dat wordt met webservices alleen maar minder <knip&gt

Dat vraag ik me af, waarom zou je een server-side applicatie ook niet platform onafhankelijk willen maken? Java Servlets zijn tenslotte ook een enorm succes. Dit heeft natuurlijk ook andere redenen, maar run-time platform onafhankelijkheid is toch een groot voordeel.

Ik vrees ook dat Java als taal het moeilijk gaat krijgen omdat het platform er als een loden last aan vast geklonken is.

Bij .NET is dit toch niet veel anders? De downloads van de .NET SDK zijn velen malen groter dan de Java 2 SDK (zelfs v1.4). Uiteraard zal downloaden niet nodig zijn omdat Microsoft al over een beter distributie-kanaal beschikt (lees Microsoft Windows) maar toch is het nogal een toestand wat .NET met zich meebrengt.

Inzichtvolle, interessante stukjes schrijf je vandaag btw .

[mbravenboer]

Het OO concept is NIET bedoelt om programmeren in algemene zin makkelijker te maken!

Toch blijf ik het daar niet helemaal mee eens . Door goed gebruik te maken van OO kan je een zeer lage lokale complexiteit bereiken. Een mens kan maar een x aantal items tegelijk op een rijtje hebben. Als je goed gebruik maakt van OO (inclusief design patterns, refactoring, unit testing) dan bereik je een zeer lage complexiteit door middel van korte duidelijke methoden. Lange lappen code duiden onmiddelijk op een slecht design. Naar mijn mening maakt het programmeren van veel problemen, dus makkelijker, maar ik geloof dat we op dat punt van mening blijven verschillen .

[JVM kan handig zijn] maar in VEEL gevallen niet.

Ik vind dat de JVM vol tot zijn recht komt bij het dynamisch linken/downloaden van code en het gebruik van reflectie. Dat zijn zaken waarvoor het toch vrij noodzakelijk is dat het zaakje in een virtual machine draait. In veel Java programma's wordt hier toch wel op enkele plaatsen gebruik van gemaakt (in die van mij in ieder geval wel ).

Verder wordt het belang van platform onafhankelijkheid sterk overschat. Het grootste voorbeeld daarvan is Swing. <knip> Maar ik heb wel last van dat het programma ook op apple draait ivm de grootste gemene deler in Swing.

Hum ik kan alleen maar vermoeden dat je hier AWT en Swing door elkaar haalt. Er is absoluut geen reden waarom Swing een grootste gemene deler zou moeten zijn. Swing wordt volledig getekend en beheerd in 100% Java code, waardoor er absoluut geen afhankelijkheden van platform features zijn. Uiteraard kan je zeggen dat het overbodig is om een volledig GUI te gaan zitten tekenen, maar het is in ieder geval een volledig platform onafhankelijke, geavanceerde en fraaie oplossing.

.NET zit er wel aan vast, maar het draait niet onder de programmatuur maar er naast. Een C# applicatie draait wel in de CLR maar wordt naar native code gecompileerd en DAN gerunt. .NET vervangt dan ook op den duur Win32, terwijl de JVM bovenop bv win32 blijft liggen.

Dat begrijp ik, maar ik vraag me af of dit nu echt zo'n essentieel verschil is. De JIT compilers worden steeds beter en er komt vast en zeker een moment waarbij run-time analyse voor performance verbetering het gaat winnen van volledige native compilatie. De opstarttijd van de JVM is nu nog het grootste probleem, maar binnen afzienbare tijd is dat geen punt meer. Op Mac OS X is VM Sharing nu al geimplementeerd, waardoor het geheugen gebruik aanzienelijk daalt. Alle bibliotheken worden door alle draaiende VMs dan gezamelijke gebruikt. Over niet al te lange tijd wordt het ook mogelijk om maar 1 VM te hebben draaien en daar de Java applicaties in te draaien. De opstarttijd is dan ook geen probleem meer. Omdat het Java platform ook kan interpreteren hoeft er bovendien niet gelijk naar native code gecompileerd te worden, waardoor de applicatie sneller start.

Ik ben overigens niet altijd te spreken over .NET hoor

Ik denk dat het een probleem gaat worden dat de programmeur moeilijk kan inzien waar de performance problemen gaan optreden door onder andere het auto-boxing. Veel mensen roepen om auto-boxing in Java (nu ook weer bij de JSR van de geparameterizeerde typen), maar tot nu toe ziet het er absoluut niet naar uit dat dit geimplementeerd gaat worden. Ik denk dat dat een goede beslissing is.

[EfBe]

Object orientatie is echter ontstaan omdat het juist makkelijk moet zijn.

Nee. OO is ontstaan als een andere manier van het vertalen van functionaliteit naar programmatuur. Het is nl. in sommige gevallen omslachtig om in een procedureel georienteerde omgeving data-georienteerd bezig te zijn. Vandaar dat men het OO concept heeft bedacht en het ook daar wordt gebruikt. Het is NIET bedoelt als 'makkelijker', het is bedoelt voor het gemakkelijk maken van het schrijven van programmatuur die is bedoeld voor een data-georienteerde omgeving, je implementeert je functionaliteit dan met de data als basis, niet met de procedure/functie als basis.

Andersom is het dus ook in veel gevallen ONHANDIG om met een OO concept een procedureel/functioneel gerichte implementatie te doen van functionaliteit die niet zozeer gericht is op data. Voorbeeld hiervan is een operating system.

Java is een leuke taal en een klote platform. Zodra je die 2 los van elkaar gaat zien is er niets aan de hand. MS heeft bv java als taal naar voren te schuiven voor het bouwen van middle-tier components in webapplicaties (in J++ 6). Dit is mislukt omdat de 2 deling: taal java vs platform java niet los gezien mag worden van Sun. Wat voor de taal adepten jammer is.

Want, nu zit je aan het java platform vast wanneer je een java applicatie bouwt. Wat voor 'multiplatform-programming' wellicht nuttig is, maar in de praktijk kom je dat niet zo vaak tegen (en dat wordt met webservices alleen maar minder, zoals het hoort: functionaliteit is multiplatform, programmatuur niet).

Ik vrees ook dat Java als taal het moeilijk gaat krijgen omdat het platform er als een loden last aan vast geklonken is. Veel java developers van het 1e uur, ik ook, hebben dankzij dat platform de taal de rug toe gekeerd. Het krijgt nu een nieuw leven in de embedded wereld, de smartcard wereld (met kleine appletjes die je op de chip kunt laden en kunt runnen in de cardreader) en als het aan sun ligt, op de server als middle-tier platform voor business logic components.

[mijn mening]
Ik denk dat Java het onderspit gaat delven tov C# en VB7. Temeer omdat er geen reden is om Java te gebruiken op het windows platform, die 2 talen heb je immers al en java is dan overbodig. Het is nu al niet de 1e keuze voor windows developers en dat wordt het dankzij VS.net ook niet. En ondanks wat ZDnet vertelt, zitten de meeste developers nog wel voor windows programma's te maken, een platform, zoals gezegd, waar Java niet echt de 1e keuze is als ontwikkeltaal (ivm Visual Studio).
[/mijn mening]

[EfBe]

[Otis: OO is ontstaan omdat men dataoriented de functionaliteit wilde implementeren]

Feit blijft dat object orientatie programmeren (uiteraard van bepaalde problemen) makkelijker moet maken. De verdeling in klassen met data en methoden is een denkwijze die vrij direct aansluit op de 'echte' wereld. Ik weet niet hoever je wilt gaan met 'data georienteerd', maar waarschijnlijk ben ik het hier niet helemaal met je eens.

OO programmeren vs Procedureel programmeren zijn allebei even moeilijk/makkelijk. Het OO concept is NIET bedoelt om programmeren in algemene zin makkelijker te maken! Het is een _andere_ manier van het implementeren van functionaliteit, die in gevallen waarbij je data-georienteerd bezig bent gemak oplevert en in gevallen waarbij je je focust op functies (een wiskunde-library bv) juist onhandig is, en waar dus procedureel programmeren handiger is.

Of real life dataoriented is weet ik niet. Ik ben er na jaren wel achter dat het beste een hybride oplossing gekozen kan worden: soms functies en soms OO. (bv C en C++ ineen).

Software opdelen in componenten heeft NIETS te maken met OO talen. COM components zijn bv binaire componenten die hergebruik bevorderen, maar kunnen gewoon in C worden geschreven, zonder structs met pointers/fake vtables.

[Otis: Java is een klote platform]

Waarom vind je het een klote platform?

Omdat de JVM in specialistische gevallen nuttig kan zijn (bv wanneer er een optimalisatie slag plaats kan vinden op basis van gegevens die tijdens runtime zijn verkregen, en dus niet verwerkt kunnen worden door een compiler tijdens compiletime), maar in VEEL gevallen niet. Ik heb erg veel javaprogrammatuur gezien en geschreven, van gui apps tot servlets tot applets, en ik heb zelden tot nooit gevallen bij de hand gehad waarbij ik dacht: hier zie je de kracht van runtime optimizing. Bijna altijd had je geen moer aan die JVM, en kon je veel beter native compileren naar het uiteindelijke doelplatform. Het draait toch op een platform (de hardware), waarom moet ik daar een cpu op gaan emuleren?

Alleen omwille van de platform 'onafhankelijkheid'. Maar dat is een farce. Op veel platforms is niet een vergelijkbare JVM te verkrijgen die eenzelfde performance biedt als bv op windows of solaris. Verder wordt het belang van platform onafhankelijkheid sterk overschat. Het grootste voorbeeld daarvan is Swing. Als ik op windows een programma run als gebruiker, interesseert me het geen RUK of dat programma ook op apple moet draaien, ik draai het op een PC. Maar ik heb wel last van dat het programma ook op apple draait ivm de grootste gemene deler in Swing. Het is verder zo bar traag in het afbeelden van schermpjes dat bv de GDI ook kan, dan ik denk: waarom moet dit?

vandaar.

Dat vraag ik me af, waarom zou je een server-side applicatie ook niet platform onafhankelijk willen maken? Java Servlets zijn tenslotte ook een enorm succes. Dit heeft natuurlijk ook andere redenen, maar run-time platform onafhankelijkheid is toch een groot voordeel

Omdat de platform onafhankelijkheid zoals gepredikt door Sun niet bestaat, plus niet speelt bij projects. Wat ik wil als developer is mn middle tier kunnen bouwen op een manier dat hij met een serie databases kan praten en kan worden gebruikt door hogere orde layers. Of die middle tier dan op een sundoos staat en de rest niet of op een windows doos en de rest niet, boeit niet. Platformonafhankelijkheid speelt ALLEEN als men die middletier doos wil vervangen door een ander merk en ander OS, waardoor de middletier niet meer werkt. Echter elk bedrijf heeft een heterogeen systempark, waardoor een vreemd OS voor de middletier niet uitmaakt, daar dat OS veelal niet vreemd is voor de organisatie. Ergo: je sleept een heleboel ballast mee om platformonafhankelijk te zijn, terwijl die klant die de app draait dat niet boeit. Die wil alleen maar de functionaliteit aanzetten en inzetten.

Bij .NET is dit toch niet veel anders? De downloads van de .NET SDK zijn velen malen groter dan de Java 2 SDK (zelfs v1.4). Uiteraard zal downloaden niet nodig zijn omdat Microsoft al over een beter distributie-kanaal beschikt (lees Microsoft Windows) maar toch is het nogal een toestand wat .NET met zich meebrengt.

.NET zit er wel aan vast, maar het draait niet onder de programmatuur maar er naast. Een C# applicatie draait wel in de CLR maar wordt naar native code gecompileerd en DAN gerunt. .NET vervangt dan ook op den duur Win32, terwijl de JVM bovenop bv win32 blijft liggen.

Bij de JVM zit je dus, botweg gezegd, met een amiga emulator op een PC een amiga programma te draaien, terwijl .NET het amiga programma vertaalt naar x86 en het programma draait native op bv windows.

Ik ben overigens niet altijd te spreken over .NET hoor, bv op het gebied van OO. Typerend voorbeeld: een C# tutorial sprak over het bouwen van een DLL met 2 functies: Add en Sub. (telt 2 getallen op vs trekt 2 getallen van elkaar af). Pure procedurele benadering. Maar dat gaat niet werken, want alles is een object dus moest er een object worden gecreeerd waarIN die 2 functies zaten als methods. Is dus een paradoxale toestand: procedureel lopen knutselen in een OO omgeving, je kunt dan beter een functionele omgeving pakken. Maar dat kan niet met .NET.

[Anoniem: 28824]

moet hierbij ook zeggen dat ik JAVA ongeveer 2 jaar voor het laatst heb zien draaien. Was bij een Delhi advanced cursus en daar was het niet echt vlot.
En geloof me, dit is een understatement

[Aaargh!]

Java is juist ontzettend makkelijk te leren, en een goeie taal om te leren voordat je met C++ aan de gang gaat. (geen geklooi met pointers e.d.)

[Exploited]

De grote vraag is nu waar dat "Evans Data Corp" mee gelieerd is. Het stikt in de automatisering (en andere plaatsen) van onderzoeken die zogenaamd wetenschappelijk/onpartijdig zijn, maar die in werkelijkheid gewoon gesponsord worden door een van de beide kampen (Microsoft vs. Sun). "Statistieken zijn de grootste leugens" wordt wel gezegd en dit nieuws wordt ik dan ook niet echt warm of koud van.

Microsoft zal Java ten alle tijde blijven bestrijden, want het doel van Java staat nu eenmaal lijnrecht tegenover het doel van Windows (beiden zijn bedoeld om tussen de hardware en het programma in te zitten - hardware abstractie heet dat). Het is afwachten of het Microsoft zal lukken om Java ooit de doodsklap te geven, maar de geschiedenis leert ons dat Micro$oft niet al te veel problemen heeft dit soort klusjes te klaren.

[mbravenboer]

Het is in ieder geval al opvallend dat de resultaten gepresenteerd zijn op de 'IBM's Solutions technical developers conference'. Zoals bekend is IBM een van de grootste supporters van het Java platform, maar ze zijn op z'n tijd ook niet bepaald vies van Microsoft technieken.

Op http://www.evansdata.com/ zag ik dat ze in ieder geval zowel Microsoft als Sun Microsystems als klant hebben. Verder kon ik er helaas niet veel vinden.

[EfBe]

Stond daar ook hoeveel duizenden developers ze hebben ondervraagd en wat de achtergrond van die developers was? Of is het werkelijk het groepje van 300 wat genoemd wordt in het ZDNet artikel?

[mbravenboer]

Ik heb helaas niets kunnen vinden... Het rapport is geeneens openbaar volgens mij . Ik heb ook zo mijn twijfels bij de betrouwbaarheid van dit onderzoek en vraag me bovendien af of dit wel relevante informatie is.

[EfBe]

Ik dook net in die reacties daar (altijd goed voor de nodige flamewars) en het schijnt 600 te zijn. Mja, lijkt me een illuster aantal.

Wat ik ook graag zou willen weten wat voor werk die mensen doen. Als je Smartcard developers vraagt wat ze gaan gebruiken, zullen ze geen C# roepen. Als je linux developers vraagt, gaan ze geen 'VB!' zeggen.

Java zal een belangrijk deel van de markt hebben, daar ben ik wel van overtuigd, maar hoe groot dat deel is blijft volgens mij sterk doelmarkt afhankelijk. En 1 keer raden welke 'doelmarkt' het grootst is.

[Anoniem: 25658]

Statistieken zijn misschien de grootste leugens, maar in dit geval denk ik dat het wel een beetje klopt.

Ik denk ook wel dat het aantal programmeurs dat Java wel eens gebruikt groter is dan de andere talen.

Over Java wordt altijd een beetje schamper gedaan alszijnde langzaam en inefficient (zie ook hierboven), maar als er maatwerk moet worden gemaakt tegen 300 piek per uur dan is het makkelijker om met een taal te werken waar je snel mee iets in elkaar zet en die toch krachtig genoeg is om aan de meeste eisen van de klant tegemoet te komen.

Het heeft natuurlijk ook veel met de mogelijkheden van Java te maken, die variëren van applets tot servlets, embedded software tot stand alone applicaties. Ook is het een relatief makkelijke taal, met duidelijke afspraken en goede documentatie, en biedt het goede mogelijkheden om te debuggen en de applicatie robuust te krijgen.

Java is absoluut geen concurrent voor Windows. De VM is geen vervanging voor het OS, maar een interface tussen OS en het programma (OS abstractie heet dat ). Ik denk dat M$ Java meer ziet als concurrent voor VB en C#, en terecht dus...

Ik zou zelf ook tien keer liever Java gebruiken dan VB of C#.

[Compacto]

Java zal in de toekomst ook veel gebruikt gaan worden in mobiele telefoons e.d. , daar zal ook veel groei zijn.
Ook is java erg goed voor dynamische sites door jsp i.c.m. javascript

[Ritch]

jsp valt niet te combineren met javascript (serverside <-> clientside) en javascript heeft ook helemaal nix met java te maken.

[Compacto]

Jazeker wel, door javascipt maak je de client kant wat dynamischer. Je moet dan wel met de parameters die de gebruiker selecteerd (b.v. door menu's) de pagina reloaden.

[Anoniem: 22682]

Wat betreft Microsoft's nieuwste ontwikkelhulp, C-Sharp, is het onderzoek niet zo positief. Slechts een klein gedeelte van de IT-branche zal overstappen naar deze op .NET gebaseerde technologie.

Ik vind het knap dat ze dat nu al weten, aangezien de ontwikkelomgeving voor C# (Visual Studio.NET) nog niet eens final is en het in principe nog niet toegestaan is om C# apps te exploiteren.

Anyway, ik denk idd dat er in het begin niet veel mensen C# zullen adopten. Waarom C# (volgens sommingen een Java-kloon) gebruiken als Java al een tijd wordt gebruikt en dus kan rusten op grote ervaring van ontwikkelaars..

[JeroenNietDoen]

als dat echt gebeurt dan zal Microsoft zich nog bedenken door het achterwege laten van een up to date JVM.

relatie: Java Virtual Machine zal niet in Windows XP z itten en Sun opent frontale aanval op Microsoft

[Anoniem: 27537]

Microsoft was, terecht, bang dat Sun haar zou aanklagen als ze de JVM in XP zou stoppen: uit de rechtszaak over Microsoft's te goed werkende JVM (hij gebruikte Windows-specifieke code en dat maakte hem meteen een stuk sneller, maar mocht niet van Sun) is immers naar voren gekomen dat Microsoft de JVM niet verder mocht ontwikkelen, maar nog wel 7 jaar lang gebruik mocht maken van de oude. Mooi, want anders had ook niemand nog J++ kunnen gebruiken. Met de introductie van C# zal J++ sterven. Microsoft heeft dus geen enkele reden om de oude JVM nog te willen gebruiken.

Daarnaast, de 7 jaar is bijna voorbij: stel je voor dat SUN Microsoft nog even zou aanklagen omdat Microsoft zich niet aan de afspraak houdt en de JVM nog steeds gebruikt.... De introductie van XP uitstellen kost simpelweg teveel geld.

Anywayz, zie ook dit artikel: http://news.cnet.com/news/0-1003-200-6895623.html?ta g=mn_hd

Ik denk niet dat Microsoft het echt zal betreuren dat ze Java niet ondersteunt. En deze vermoedens van Evans Data Corp vind ik erg voorbarig: eerst zien, dan geloven. De échte C++/OO-programmeurs die ik ken hebben een hekel aan Java: als je op een lekker laag niveau bezig wilt zijn dan kan dat niet en in plaats van normale multiple inheritance moet je rare sprongen maken met het extenden van de ene class en het implementeren van interfaces...

* 786562 Bugu

[mbravenboer]

Microsoft was, terecht, bang

Dat is werkelijk onzin. De rechtzaak is uitgelopen op een schikking, waarbij Sun Microsoft toestond om nog 7 jaar lang hun huidige Java VM met enige aanpassingen te blijven gebruiken. De versies die nu geleverd worden met Internet Explorer en Microsoft Windows 2000 voldoen aan deze eisen. Microsoft had gewoon deze VM mee kunnen leveren. Ik ben blij dat ze dit niet doen, maar de statement van donderdag waarin ze zeggen dat ze rechtzaken willen voorkomen raken kant nog wal. Ik heb over deze statements een uitgebreidde nieuwsposting gedaan, maar helaas is deze er (nog) niet opgekomen.

hij gebruikte Windows-specifieke code en dat maakte hem meteen een stuk sneller, maar mocht niet van Sun

Dat was absoluut niet de reden van de rechtzaak. In de Microsoft VM waren essentiele delen van het Java Platform weggelaten. Ook heeft Microsoft de Java bytecode attributen gebruikt ten behoeve van COM, waardoor applicaties die ontwikkeld zijn voor de Microsoft VM ook percee op de Microsoft Java VM moeten draaien. Dit is gewoon een grove schending van de licentie en alle grondbeginselen van Java.

Daarnaast, de 7 jaar is bijna voorbij, stel je voor dat SUN Microsoft nog even zou aanklagen omdat Microsoft zich niet aan de afspraak houdt en de JVM nog steeds gebruikt

Dat valt wel mee. Er is geen enkel bezwaar tegen het meeleveren van de Microsoft Java VM in Microsoft Windows XP, behalve dat we liever een betere willen hebben > .

De échte C++/OO-programmeurs die ik ken hebben een hekel aan Java

In de academische wereld, waar toch echt erg veel OO-kenners zitten, wordt toch vooral gebruik gemaakt van Java. Vrijwel alle artikelen bevatten Java code, omdat deze veel duidelijker is dan C++ code. Dat echte OO-programmeurs dus een hekel aan Java hebben is dus onzin.

in plaats van normale multiple inheritance moet je rare sprongen maken met het extenden van de ene class en het implementeren van interfaces...

Bij een goed design heb je maar zelden multiple inheritance nodig. Overigens bevat C# ook geen multiple inheritance, wat toch een teken is dat de keuze die gemaakt is bij Java ook als een goede wordt gezien.

Bugu vindt Java een taal die te vaak tekortschiet en stapt dan ook snel over naar .NET, waarin ie tenminste van de kracht van alle talen tegelijkertijd gebruik kan maken, in plaats van dat hij al die krachten moet inleveren.

Ook op het Java Platform kan je verschillende talen gebruiken. C++ is inderdaad niet mogelijk, maar een taal als Python wordt ook veel gebruikt. .NET is een interessante ontwikkeling en C# is een fraaie taal, maar voorlopig moet het zich qua platform-onafhankelijkheid nog bewijzen.

[EfBe]

Dat was absoluut niet de reden van de rechtzaak. In de Microsoft VM waren essentiele delen van het Java Platform weggelaten. Ook heeft Microsoft de Java bytecode attributen gebruikt ten behoeve van COM, waardoor applicaties die ontwikkeld zijn voor de Microsoft VM ook percee op de Microsoft Java VM moeten draaien. Dit is gewoon een grove schending van de licentie en alle grondbeginselen van Java.

Het ging om extensies aan de compilerkant. J++ liet je COM components bouwen in java (taal) en die kon je native compileren, dus niet met de jvm als target.

Verder had MS vele classes toegevoegd die je standaard gebruikte in J++, als je de tool wat efficienter inzette (bv bij het tekenen van schermpjes etc).

RMI wat niet geimplementeerd was in de MS JVM is op zich niet iets wat in de TAAL nuttig kan zijn. het is een platform specifiek iets, iets specifieks van het java platform. De toepassingn van MS was op zich krachtiger: je kon 3rd party COM objects gebruiken in classes die draaiden op de JVM, niet java components op een JVM op een andere computer.

Met een grove schending heeft het niet zoveel te maken, tenslotte heeft HP ook een extensie voor java gemaakt, waarbij java niet geheel is geimplementeerd en waarbij men eigen toevoegingen heeft gedaan aan java (voor embedded systems).

Het is dan ook typerend dat Sun juist MS aanvalt, en niet zozeer andere bedrijven. J++ is met afstand de meest verkochte Java development tool ter wereld, met een editor die bv realtime syntax checking deed, intellisence etc. Sun heeft verzuimt om de taal los te laten van het platform. Hadden ze dat WEL gedaan, dan was java nu de taal voor .NET geweest en niet C#, daar ben ik van overtuigd.

Het ergert me soms echt wel dat mensen niet snappen dat java 2 dingen betekent: een taal (goede taal) en een platform (lang niet altijd geschikt voor de toepassingen waar het voor bedoelt is). En dat die connectie er ook zal blijven zolang Sun het platform ziet als DE manier om windows tegen te zitten, terwijl dat nu juist de developer (i.e. de persoon die de programmatuur voor het javaplatform moet maken) niets interesseert: of zn java programma nu op een jvm draait op een solaris doos of native op die solarisdoos.

[mbravenboer]

Het ging om extensies aan de compilerkant. J++ liet je COM components bouwen in java (taal) en die kon je native compileren, dus niet met de jvm als target.

Ik had begrepen dat in de geproduceerde Java bytecode, waarin attributen zijn toegestaan om hints te geven aan de Virtual Machine die echter niet noodzakelijk mogen zijn voor executie, extra attribuut gegevens werden toegevoegd die percee nodig waren om de code te kunnen uitvoeren. Juist hierdoor werkte de geproduceerde code niet op andere Java VMs op het Microsoft Windows platform (andere platforms was natuurlijk sowieso uitgesloten, maar in principe is dat geen probleem).

RMI wat niet geimplementeerd was in de MS JVM is op zich niet iets wat in de TAAL nuttig kan zijn. het is een platform specifiek iets, iets specifieks van het java platform.

RMI heeft helemaal niets met Java als taal te maken. Het is slechts een API, waarbij de remote objecten een bepaalde interface moeten implementeren. Een RMI compiler produceert daarna stubs (skeletons zijn ondertussen deprecated omdat ze generiek zijn) die ook gewoon 100% (normale) Java code zijn. Ik heb daarom eigenlijk nooit begrepen waarom ze RMI niet opgenomen hebben. Dit was echt een vrij kleine moeite geweest. Met een beetje goede wil bouw je RMI zo zelf na.

De toepassingn van MS was op zich krachtiger: je kon 3rd party COM objects gebruiken in classes die draaiden op de JVM, niet java components op een JVM op een andere computer.

Dat was inderdaad een interessant gegeven, maar het vervelende was dat de Java bytecode daarmee direct verbonden was met de Microsoft Java VM. Volgens mij was het ook mogelijk geweest om COM gewoon met behulp van JNI in native code te implementeren, waardoor Microsoft zich keurig aan alle voorwaarden had kunnen houden.

Sun heeft verzuimt om de taal los te laten van het platform. Hadden ze dat WEL gedaan, dan was java nu de taal voor .NET geweest en niet C#, daar ben ik van overtuigd.

Daar heb je wel gelijk in. Ik ben het dan ook wel met je eens op dit punt.

Het ergert me soms echt wel dat mensen niet snappen dat java 2 dingen betekent

Wauw, we hebben een ergernis gemeen .

terwijl dat nu juist de developer niets interesseert: of zn java programma nu op een jvm draait op een solaris doos of native op die solarisdoos.

Op het web is run-time platform onafhankelijkheid van essentieel belang. Microsoft beseft uiteraard ook dat dit de toekomst is en .NET is volgens mij dan ook gewoon de Microsoft variant van het Java platform met positieve en negatieve punten. Ik denk dus eigenlijk wel dat het de developer interesseert waar zijn code wordt gedraaid. Het is van essentieel belang dat de goede bibliotheken beschikbaar zijn. Alleen via een platform of framework kan dit verzekerd worden. Overigens is het geen enkel probleem om Java naar native code te compileren en ik denk ook dat het zelfs makkelijk gebruikt kan worden om naar IL te compileren. Het mag dan alleen geen Java platform worden genoemd. Er zijn immers ook nogal wat (goede) native compilers op de markt.

[EfBe]

De toepassingn van MS was op zich krachtiger: je kon 3rd party COM objects gebruiken in classes die draaiden op de JVM, niet java components op een JVM op een andere computer
Dat was inderdaad een interessant gegeven, maar het vervelende was dat de Java bytecode daarmee direct verbonden was met de Microsoft Java VM. Volgens mij was het ook mogelijk geweest om COM gewoon met behulp van JNI in native code te implementeren, waardoor Microsoft zich keurig aan alle voorwaarden had kunnen houden

Een object, wat wordt geinstantieerd als COM object en draait op de JVM moet benaderbaar zijn voor de SCM, ik denk dat dat het probleem is geweest en dat ze de JVM zo hebben aangepast dat het OS via de JVM altijd bij de instance kon en de instance andere com components kon instantieren via het OS en dat die dan terecht kwamen in de service control manager (SCM). Anyway, het zij zo, MS heeft nooit een geheim gemaakt vanhet feit dat ze taal en platform apart zagen, waardoor het voor hen een logische stap was, voor sun uiteraard niet.

[santaklos]

[i] Ik heb daarom eigenlijk nooit begrepen waarom ze RMI niet opgenomen hebben. Dit was echt een vrij kleine moeite geweest. Met een beetje goede wil bouw je RMI zo zelf na. [/i[

Toen de rechtzaak begonnen was, heeft MS al vrij snel RMI als aparte download ter beschikking gesteld, inderdaad omdat dit uit een set Java classes bestaat die eenvoudig werkend te krijgen zijn.

Mijn stelling is dan ook dat het een actie is gemeest met puur politieke achtergonden, namelijk om de vaart uit de acceptatie te halen, dat vanaf het begin een raketstart heeft gehad, waar MS enorm van geschriokken schijnt te zijn.

Al leek de strijd om Java zich eerst te richten om het veroveren van de client, heeft Sun een paar jaar terug al de focus verlegt naar de server (eerst servlets en later nog veel sterker met Enterprise Java Beans).
En Sun lijkt daar vooralsnog zeer succesvol in te zijn. Ook MS lijkt in te zien dat de strijd op de server gewonnen moet worden, wat ook de kern is geworden van de .NET strategie.
Dit verklaart dat de "intermediate language" van .NET portable is via het netwerk en dat er Mac en Linux runtime systemen komen.
Waar het M$ dan om zal gaan is dat de server spulletjes van .NET niet op een Unix/Linux/Max box te draaien zullen zijn.

[RetepV]

De échte C++/OO-programmeurs die ik ken hebben een hekel aan Java: als je op een lekker laag niveau bezig wilt zijn dan kan dat niet en in plaats van normale multiple inheritance moet je rare sprongen maken met het extenden van de ene class en het implementeren van interfaces

Doordat je er bij zegt 'De échte C++/OO-programmeurs...' heb je je eigen argumentatie omver geworpen. Dat soort programmeurs zullen inderdaad nooit overstappen op Java, tenzij voor de grap. Maar die programmeurs houden zich ook _helemaal_ niet bezig met high-level applicaties.

Eigenlijk zeg je alleen maar wat iedereen al duizend jaar roept: voor elk probleem de juiste tool gebruiken.

Als je drivers schrijft ben je ziek in je hoofd als je Java gaat programmeren. Ook als je servers schrijft doe je dat niet, want je hebt gewoon te weinig grip op het geheugengebruik. Hetzelfde geldt voor computer games, en eigenlijk alles waar high-performance belangrijker is dan time-to-market. In bijna alle andere gevallen is Java beter dan C/C++.

[packman]

Hopelijk zal MS zijn JVM dan juist niet meeleveren, maar wel toestaan van een third-party plugin ervoor te kunnen installeren, iets wat nu niet gaat. De JVM van MS mag dan wel een snelle en performante zijn, hij is totaal achterhaald qua versie. Ik installeer liever de IBM of Sun JVM.

[Anoniem: 10256]

maar wel toestaan van een third-party plugin ervoor te kunnen installeren, iets wat nu niet gaat.

microsoft is niet echt het bedrijf waar je als klant veel keuzevrijheid krijgt, dus ik denk dat de kans klein is. Dat zal pas gebeuren als C# geflopt is, en dan nog zullen ze proberen hun eigen JVM te ontwikkelen voordat ze die van een concurrent zullen toestaan.

Ik vind het op zich niet gek dat java nu omhoogkruipt. De laatste jaren zie je dat in de ontwikkeling van in-house software van bedrijven bijna alleen nog maar java gebruikt wordt. C(++) is veel meer lowlevel, en voor dat soort software heb je dat gewoon niet nodig. C(++) gebruik je voor het bouwen van een operating system of zo. C# is een soort java waar ze weer memory leaks en pointers in hebben gestopt dus wie wil dat nou? het is te log/traag voor low-level programmeurs, en voor high-level applicaties is het ongeschikt.

[curry684]

C# is een soort java waar ze weer memory leaks en pointers in hebben gestopt dus wie wil dat nou?

Voor pointers in C# moet je een blok programma expliciet als unsafe marken, en dan komt ie vervolgens niet meer door 'safety-tests' van het OS voor remote installs. Memory-leaks zijn net zo bout als in Java zelf: het heet een brakke garbagecontroller. In allebei de implementaties wordt soms pas een half uur na het sluiten van het programma al het geheugen vrijgegeven.

[Slush]

Meer dan de helft van de Noord Amerikaanse programmeurs maakt al gebruik van de taal, en bovendien zal dit aantal nog behoorlijk gaan toenemen in het komende jaar.

Ik maak ook gebruik van java... maar ik maak ook gebruik van de andere programmeermogelijkheden... tis maar waar je het voor nodig hebt. Lekker ongenuanceerd verhaal weer...

[Anoniem: 5243]

Ik denk dat ze voornamelijk bedoelen dat veel programmeurs Java gebruiken voor commerciele doeleinden...

[Anoniem: 2141]

inderdaad
't wordt lekker opgeblazen

[Anoniem: 10902]

Hmmmmkay...
Ik kan me wel voorstellen dat het aantal Java programmeurs toeneemt maar om nou te stellen dat 'meer dan de helft van de Noord Amerikaanse programmeurs' gebruik maakt van Java (ten koste van C/C++) vind ik ietwat te enthousiast.

Wie weet is het misshien wel een marketing truukje van Sun

Op zich is het bericht niet vreemd; elk jaar groeit de e-business gigantisch dus de vraag en het gebruik van Java zal +/- evenredig meegroeien. Ik ben zelf een veteraan C/C++ progger en gebruik het uitsluitend voor low-level doeleinden (Device drivers, real-time applicaties etc.). Internettoepassingen geschreven in C/C++ zijn nogal zeldzaam en niet voor de hand liggend, Java - on the other hand - wel.

[Left]

Verbaast mij niks dat Java volgend jaar de meest gebruikte taal wordt. En ook al klopt dit onderzoek niet dan nog zal het niet lang duren voordat Java nr. 1 is.
C++ is een mooie taal maar het kost gewoon teveel tijd (=geld) om een maatwerk applicatie erin te schrijven. Met VB heb je juist weer zomaar een applicatie in elkaar geprogrammeert, alleen is het niet erg schaalbaar naar grotere toepassingen. En Java zit daar lekker tussenin, je zet er relatief snel een applicatie mee in elkaar en het is toch goed schaalbaar omdat het zo object georienteerd is.
C# ken ik niet maar ik heb er veelbelovende dingen over gehoord. Alleen is Micro$oft er een beetje laat mee, ze lopen 6 jaar achter op Java. Waarschijnlijk hadden ze in eerste instantie gehoopt dat ze met hun eigen JVM verder konden?

[The Dolf]

En waarom niet?
Java wordt nog zeer veel gebruikt voor internet en serverdoeleinden. Java wordt meer en meer gebruikt dus is het logisch dat C, C++ en VB afnemen.

[Vastloper]

erg leuk dat java voor internet en serverdoeleinden word gebruikt maar daar was c++ enz toch al geen optie vaak. Maar de meeste echte applicaties worden naar mijn weten gewoon in c/c++ gemaakt aangezien ik geen compiler oid ken. java draait in een virtual machina naar mijn weten en daardoor kun je nooit alle performance halen die je met c/c++ haalt waarbij je de code gewoon omzet naar opcodes voor de processor. Voor prestatiegerichte programma's zul je dus nooit java gebruikt zien worden. Voor programma's die overal op moeten kunnen draaien is het weer wel geschikt maar java blijft daardoor behoorlijk gelimiteerd. Ik vind het vergelijk van de 2 talen daarom vaak ook zo onzinnig. Ze zijn gewoon allebei voor zeer verschillende doeleinden. Als ik bijvoorbeeld een standalone windows applicatie wil maken die gebruik maakt van specifieke api's, lijk ik wel gek om java te gebruiken dit is gewoon zeer gelimiteerd en traag hiervoor het sterke punt van java is gewoon puur dat het overal op draait en aangezien internet tegenwoordig ook overal op draait is het ook goed geschikt voor toepassing op internet.

[RG]

Volgens mijd enk jij alleenmaar in Aplets ofzo... Java is op zich best een goede techniek en wordt in de academische wereld tegenwoordig erg veel gebruit. Echter talen als C enzo zullen nooit verdwijnen, je kunt moeilijk alles in java schrijven.

[Aaargh!]

Volgens mij ken jij alleen IE met MS's brakke en zwaar verouderde java implementatie.

[Anoniem: 2141]

toch niet

[*marco*]

Zal het gebruik van java niet eerder gaan afnemen als microsoft JVM niet in windows xp mee leverd ?

mensen kunnen het inderdaad wel zelf gaan downloaden maar of dat massaal gaat gebeuren moet ik nog zien.

[Slush]

Toevallig ben ik momenteel met een InstallShield project bezig waar om de java-engine gevraagd word... Persoonlijk vind ik het wel charmant dat Microsoft die ellende niet meer mee installeert met XP. Kan ik er tenminste een nette installatie van maken en hoeft MS zich geen zorgen meer te maken dat er in verkeerde registry-settings wordt geschreven (ik ga verder niet op details in, maar kort gezegd is een zelfgeinstalleerde java-engine altijd stabieler dan elke engine die microsoft heeft mee kunnen leveren...

[mbravenboer]

Microsoft mag na de rechtzaak, die Sun aangespannen heeft vanwege het schenden van de licentie, alleen nog maar een zeer oude versie van het Java platform distribueren. Hun virtuel machine is gebaseerd op versie 1.1.4 van Java. Helaas heeft dit voor een enorme technologische achterstand gezorgd, omdat Java sindsdien op vrijwel alle fronten is opgegroeid. De virtual machines zijn sneller en er zijn veel betere en uitgebreidere APIs beschikbaar.

Omdat Microsoft de VM nu helemaal niet meer meelevert zal dit weinig gevolgen hebben voor Java. Java wordt het meest gebruikt op de server-side, waar het installeren van een JRE absoluut geen punt is. Sun richt zich echter ook steeds meer op de client-side. Wellicht dat de beslissing van Microsoft om geen VM meer te distribueren weleens gunstig uit kan pakken...