[Java] public static abstract method mag niet, waarom?

[Verwijderd]

Een goeienavond,

Ik ben hier nog even snel aan het proberen een deadline te halen en nou loop ik tegen het volgende vage probleem aan. Ik heb een stukje code voor een abstracte statische utility class met daarin een geneste public statische class die de functionaliteit implementeerd. Zie de code hieronder:

Java:

public abstract class PageLoader
{
    public static abstract Page load();

    public static class DBNodeLoader extends PageLoader
    {
      public static Page load()
      {
        // do stuff
        return null;
      }
    }
}

Het nut hiervan is dat ik (dacht ik dan) PageLoader.DBNodeLoader.load() kan aanroepen om de specifieke loader te gebruiken, een beetje à la Ellipse2D en Ellipse2D.double. Maar nou klaagt m'n Java compiler (Sun JDK 1.4.2_03) dat static astract een illegale combinatie van modifiers is.

Heeft iemand enig idee waarom?

offtopic:
Het is niet zo belangrijk, want ik gooi gezien de tijdsdruk de abstract method gewoon uit de superclass. Ik vraag me alleen af waarom dit niet mag, het leek zo'n mooie oplossing... ach ja, het wordt laat

[Soultaker]

Een static method is 'statisch' omdat je 'ie gebonden is aan de klasse waarop je 'm implementeert. Je kunt 'm dan ook niet in een andere klasse overriden: A.foo is anders dan B.foo. Het declareren van een abstracte statische methode is dan ook nutteloos: als je die methode niet gaat definiëren, waarom declaar je 'm dan?

[ Voor 7% gewijzigd door Soultaker op 08-06-2004 13:45 ]

[Alarmnummer]

Soultaker schreef op 07 juni 2004 @ 23:37:
Een static method is 'statisch' omdat je 'ie gebonden is aan de klasse waarop je 'm implementeert. Je kunt 'm dan ook niet in een andere klasse overloaden: A.foo is anders dan B.foo. Het declareren van een abstracte statische methode is dan ook nutteloos: als je die methode niet gaat definiëren, waarom declaar je 'm dan?

In java is dit idd op deze manier geimplementeerd, maar dat betekent niet dat ik het ermee eens ben. Ik zou ook liever hebben gezien dat een statische methode zich net zo gedraagt qua overerving als een niet statische methode.

Ik kan het topic niet zo snel vinden, maar ik heb hier in het verleden ook wel eens over geklaagd.

[ Voor 9% gewijzigd door Alarmnummer op 07-06-2004 23:41 ]

[Soultaker]

Oh ja, een voorbeeld om m'n punt inzichtelijker te maken is het volgende:

Java:

class Base {
    public static int foo() {
        return 1;
    }
}

class Derived extends Base {
    public static int foo() {
        return 2;
    }
    
}

public class Test {
    public static void execute(Base object) {
        System.out.println( object.foo() );
    }
    
    public static void main(String[] args) {
        execute(new Derived());        
    }
}

Wat denk je dat er weergegeven wordt?

[Soultaker]

Alarmnummer schreef op 07 juni 2004 @ 23:39:
In java is dit idd op deze manier geimplementeerd, maar dat betekent niet dat ik het ermee eens ben. Ik zou ook liever hebben gezien dat een statische methode zich net zo gedraagt qua overerving dan een niet statische methode.

Ik vind het vooral erg jammer dat je die statische methodes op een object kan aanroepen, wat suggereert dat het run-time type van dat object relevant is (terwijl het dus uitsluitend om het compile-time type gaat). Als je die statische methode alleen maar op klasse aan zou kunnen roepen (e.g. Base.foo() in plaats van object.foo()) dan zou ik er al een stuk minder moeite mee hebben.

[Alarmnummer]

Soultaker schreef op 07 juni 2004 @ 23:42:
[...]

Ik vind het vooral erg jammer dat je die statische methodes op een object kan aanroepen, wat suggereert dat het run-time type van dat object relevant is (terwijl het dus uitsluitend om het compile-time type gaat). Als je die statische methode alleen maar op klasse aan zou kunnen roepen (e.g. Base.foo() in plaats van object.foo()) dan zou ik er al een stuk minder moeite mee hebben.

Dan krijg je helemaal de bibbers van de static imports.

code:

package bla;

class Foo{
     static void foo(){}
}


----------------

package blabla;

import static bla.Foo.*;

class Jaja{
     void main(){
         foo();
     }
}

En nu maar raden waar die foo methode vandaan komt.

[Verwijderd]

Het declareren van een abstracte statische methode is dan ook nutteloos: als je die methode niet gaat definiëren, waarom declaar je 'm dan?

... Ik vind het nog steeds een beetje vreemd maar als ik het dus begrijp zal in jou voorbeeld dus Base.foo() worden uitgevoerd.

Ik heb om door te kunnen de method gewoon public static gemaakt en hem een stub body gegeven die null returned. Op deze manier werkt het voor mij, maar ik zie wel in (na m'n nachtrust ) dat ik beter gewoon een factory had kunnen maken

Dan krijg je helemaal de bibbers van de static imports.

Hey, die kon ik nog niet... Als ik het goed begrijp kun je dus gewoon de statische methods van een utility class in andere classes importeren? Wat gebeurt er als er als de class Jaja al een static void foo(){} heeft?

Weer een geweldig handige feature van Sun hoor Dat ze in plaats van deze onzin eens wat nuttige uitbreidingen en verbeteringen aan Java gaan maken... Zo is het voor MS ook geen uitdaging meer om de markt over te nemen met .NET

modbreak: dat bedrijf heet Microsoft en kort je af tot MS. Verbasteringen als M$, Mickeysoft etc. zijn enkel flamebait en dus net zomin gewenst op GoT als scheldpartijen naar medegebruikers.

[ Voor 13% gewijzigd door curry684 op 08-06-2004 09:12 ]

[Alarmnummer]

Verwijderd schreef op 08 juni 2004 @ 08:54:
[...]
Hey, die kon ik nog niet... Als ik het goed begrijp kun je dus gewoon de statische methods van een utility class in andere classes importeren? Wat gebeurt er als er als de class Jaja al een static void foo(){} heeft?

Ik neem aan dat je dan alsnog moet aangeven welke je wilt hebben.

Weer een geweldig handige feature van Sun hoor Dat ze in plaats van deze onzin eens wat nuttige uitbreidingen en verbeteringen aan Java gaan maken... Zo is het voor M$ ook geen uitdaging meer om de markt over te nemen met .NET

Ik vind niet dat je dit soort opmerkingen kan maken. Sun die zorgt voor open standaarden en het java platform is veel meer dan wat syntactische goodies.

[Robtimus]

Verwijderd schreef op 08 juni 2004 @ 08:54:
Ik heb om door te kunnen de method gewoon public static gemaakt en hem een stub body gegeven die null returned. Op deze manier werkt het voor mij, maar ik zie wel in (na m'n nachtrust ) dat ik beter gewoon een factory had kunnen maken

Een UnsupportedOperationException is nog netter dan null returnen. Dan weet je meteen dat je iets fout doet.

[Soultaker]

Verwijderd schreef op 08 juni 2004 @ 08:54:
Ik heb om door te kunnen de method gewoon public static gemaakt en hem een stub body gegeven die null returned.

Wat heb je er dan nog aan? Het is niet alsof je die methode moet of zelfs maar kunt overriden in afgeleide klassen. Waar gebruik je die methode dan nog voor?

Alarmnummer schreef op 08 juni 2004 @ 08:59:
Sun die zorgt voor open standaarden en het java platform is veel meer dan wat syntactische goodies.

Met het tweede ben ik het eens. Het eerste is op zichzelf geen garantie voor kwaliteit, zeker niet als je bedenkt dat concurrent .NET net zo'n 'open' standaard is, maar wel een aantal zaken handiger op gelost heeft (al is dat een andere discussie).

[Alarmnummer]

Soultaker schreef op 08 juni 2004 @ 13:47:
Met het tweede ben ik het eens. Het eerste is op zichzelf geen garantie voor kwaliteit, zeker niet als je bedenkt dat concurrent .NET net zo'n 'open' standaard is, maar wel een aantal zaken handiger op gelost heeft (al is dat een andere discussie).

Laten we als voorbeeld J2EE nemen. Dat is een hele collectie met open standaarden (waar veel grote bedrijven aan mee doen: IBM. BEA, Borland etc). Heb jij iets vergelijkbaars van MS gezien? Ik niet.

[Verwijderd]

Ik vind niet dat je dit soort opmerkingen kan maken. Sun die zorgt voor open standaarden en het java platform is veel meer dan wat syntactische goodies.

Sorry voor deze reactie en de uitlatingen (vroeger mocht M$ wel ). Ik ben zelf ook een grote Java fan, maar ik kon het ff niet hebben dat Java niet deed wat ik wou

Maar om hier even inhoudelijk op te reageren. Het java platform is veel meer dan wat syntactische goodies, dat klopt. Maar met die opmerking over de open standaarden ben ik het ook niet eens. Ze doen wel een poging, maar op de een of andere manier lukt het Sun niet of niet snel genoeg om te voldoen aan de eisen van de markt.

Neem het .NET platform. Toen het uit kwam vond ik dat het gewoon een rip-off was van Java (wat betreft C# en de CLR). Maar als je dan kijkt wat voor ontwikkeling .NET heeft doorgemaakt sinds de eerste release en dan kijkt naar Java, dan lijkt het wel alsof de tijd voor Java heeft stilgestaan.

En binnen niet al te lange tijd komt .NET 2.0 uit en die is naar verluidt twee keer zo omvangrijk geworden als 1.0. Kijk dan eens naar Sun die nou al een half jaar ofzo bezig is om de J2SE 1.5 uit de beta te halen, dan denk ik dat Java z'n langste tijd heeft gehad. En dat vind ik jammer. En daarom snap ik dus niet waarom Sun niet eens wat dingen in Java inbouwt die wel zoden aan de dijk zetten, in plaats van static imports

Laten we als voorbeeld J2EE nemen. Dat is een hele collectie met open standaarden (waar veel grote bedrijven aan mee doen: IBM. BEA, Borland etc). Heb jij iets vergelijkbaars van MS gezien? Ik niet.

Misschien is dat wel de kracht van Microsoft, ze kunnen zelfstandig bepalen wat ze nou gaan doen, welke features ze toevoegen of welke herzieningen ze willen doorvoeten. Dit draagt volgens mij juist toe aan de snelheid waarmee MS/.NET de markt verovert. Kijk eens in de JDK API wat een rommel daar nog in rondhangt for the sake of backward compatibility... en dan heb ik het nog niet eens over de syntax van de nieuwe foreach loop

Een UnsupportedOperationException is nog netter dan null returnen. Dan weet je meteen dat je iets fout doet.

Klopt, maar zie mijn signature

Wat heb je er dan nog aan? Het is niet alsof je die methode moet of zelfs maar kunt overriden in afgeleide klassen. Waar gebruik je die methode dan nog voor?

Je hebt gelijk. Ik was meer aan het denken aan een factory en daarom was ik was aan het rommelen met een dergelijke statische overerving. Ik had beter gewoon meteen een factory kunnen gebruiken, want nu ik er over na denk is mijn oplossing natuurlijk een OO nachtmerrie

[Robtimus]

Verwijderd schreef op 09 juni 2004 @ 11:42:
Misschien is dat wel de kracht van Microsoft, ze kunnen zelfstandig bepalen wat ze nou gaan doen, welke features ze toevoegen of welke herzieningen ze willen doorvoeten. Dit draagt volgens mij juist toe aan de snelheid waarmee MS/.NET de markt verovert. Kijk eens in de JDK API wat een rommel daar nog in rondhangt for the sake of backward compatibility...

Die backwards compatibility zit in zoveel libraries, zodat oudere programma's niet voor een groot deel herschreven hoeven te worden. Dat ze dan meteen waarschuwen bij het compilen van (nieuwe) code dat het niet meer gebruikt dient te worden vind ik een uitstekende manier om het gebruik er volledig uit te krijgen.

en dan heb ik het nog niet eens over de syntax van de nieuwe foreach loop

Ik zie er het probleem niet van. Het is veel makkelijker dan handmatig itereren (tenzij je tijdens het itereren de collection gaat aanpassen). En wat is nou het grote verschil tussen de volgende 2 stukken code?

Java:

for (Integer i : list) { ... }

Python:

for i in list: .....

Ok, in de ene krijgt i een type, en de in is veranderd in een :, maar beiden zien ze er totaal begrijpelijk uit.

Verder heb ik liever dat Java 1.5 een half jaar beta blijft en daarna meteen ook echt stable is, dan snel een versie uitgeven gevolgd door vele bugfixes. Het is alleen wel jammer dat sommige zaken (enums en formatted output bv zijn al bejaard in C) nu pas komen, maar liever laat dan nooit.

Ik was nog niet zo op de hoogte van Java 1.5, maar ik ga toch echt overstappen zodra hij stable is.

Vraagje trouwens: als je zelf een collection hebt geschreven, moet die dan worden herschreven voor generics?

[Alarmnummer]

Verwijderd schreef op 09 juni 2004 @ 11:42:
[...]
Maar om hier even inhoudelijk op te reageren. Het java platform is veel meer dan wat syntactische goodies, dat klopt. Maar met die opmerking over de open standaarden ben ik het ook niet eens. Ze doen wel een poging, maar op de een of andere manier lukt het Sun niet of niet snel genoeg om te voldoen aan de eisen van de markt.

Ik weet niet of dat te lang op zich laat wachten. Complexe zaken duren gewoon even en ik heb niet de indruk dat Sun achter de feiten aanloopt.

Neem het .NET platform. Toen het uit kwam vond ik dat het gewoon een rip-off was van Java (wat betreft C# en de CLR). Maar als je dan kijkt wat voor ontwikkeling .NET heeft doorgemaakt sinds de eerste release en dan kijkt naar Java, dan lijkt het wel alsof de tijd voor Java heeft stilgestaan.

Java platform > java taal.

Er wordt heel erg veel gedaan aan uitbreidingen op het java platform en daarvoor hoef je nu eenmaal niet veel aan java zelf uit te breiden.

En binnen niet al te lange tijd komt .NET 2.0 uit en die is naar verluidt twee keer zo omvangrijk geworden als 1.0. Kijk dan eens naar Sun die nou al een half jaar ofzo bezig is om de J2SE 1.5 uit de beta te halen, dan denk ik dat Java z'n langste tijd heeft gehad. En dat vind ik jammer. En daarom snap ik dus niet waarom Sun niet eens wat dingen in Java inbouwt die wel zoden aan de dijk zetten, in plaats van static imports

Dit vind ik echt onzin. Het .NET platform is nu volwassen aan het worden en java is dat al tijden. Verder is het voordeel van Java dat ik mijn extra`s zelf kan uitkiezen. Ben ik EJB nodig? Nou dan pak ik bv JBoss. Ben ik een lichte vorm van ormapping nodig? Dan pak ik hibernate. Je bent dus vrij om te kiezen wat je wilt en daarvoor hoef te de taal niet meer uitgebreid te worden.

Misschien is dat wel de kracht van Microsoft, ze kunnen zelfstandig bepalen wat ze nou gaan doen, welke features ze toevoegen of welke herzieningen ze willen doorvoeten. Dit draagt volgens mij juist toe aan de snelheid waarmee MS/.NET de markt verovert. Kijk eens in de JDK API wat een rommel daar nog in rondhangt for the sake of backward compatibility..

Dat zul je met .NET ook gaan krijgen. Dat gebeurt gewoon met alle talen die een tijdje meegaan.

. en dan heb ik het nog niet eens over de syntax van de nieuwe foreach loop

Wat is daar mis mee?


[@iceman]
Alles wat met 1.4 gecompileerd kan worden kan ook met 1.5 gecompileerd worden. Je hoeft dus niet bang te zijn dat je alles nu ineens moet gaan parametriseren. Je krijgt echt wel een hele zooi warnings al je gaat compileren.

[MSalters]

Verwijderd schreef op 09 juni 2004 @ 11:42:
Maar om hier even inhoudelijk op te reageren. Het java platform is veel meer dan wat syntactische goodies, dat klopt. Maar met die opmerking over de open standaarden ben ik het ook niet eens. Ze doen wel een poging, maar op de een of andere manier lukt het Sun niet of niet snel genoeg om te voldoen aan de eisen van de markt.
[...]
Misschien is dat wel de kracht van Microsoft, ze kunnen zelfstandig bepalen wat ze nou gaan doen, welke features ze toevoegen of welke herzieningen ze willen doorvoeten. Dit draagt volgens mij juist toe aan de snelheid waarmee MS/.NET de markt verovert. Kijk eens in de JDK API wat een rommel daar nog in rondhangt for the sake of backward compatibility... en dan heb ik het nog niet eens over de syntax van de nieuwe foreach loop

Vreemd genoeg is de werkelijke situatie andersom. Microsoft heeft .NET (CLR en C#) overgelaten aan ECMA, met een fasttrack procedure naar ISO SC22. Zowel ECMA als ISO geven anderen bindende inspraak. Sterker nog: binnen ISO heeft Microsoft niet eens stemrecht.

Java daarentegen is volledig in handen van Sun. Sun hoeft aan niemand toestemming te vragen voor 1.5 of 1.6. Er is weinig opens aan.

[Janoz]

Verwijderd schreef op 09 juni 2004 @ 11:42:
Neem het .NET platform. Toen het uit kwam vond ik dat het gewoon een rip-off was van Java (wat betreft C# en de CLR). Maar als je dan kijkt wat voor ontwikkeling .NET heeft doorgemaakt sinds de eerste release en dan kijkt naar Java, dan lijkt het wel alsof de tijd voor Java heeft stilgestaan.

En binnen niet al te lange tijd komt .NET 2.0 uit en die is naar verluidt twee keer zo omvangrijk geworden als 1.0. Kijk dan eens naar Sun die nou al een half jaar ofzo bezig is om de J2SE 1.5 uit de beta te halen, dan denk ik dat Java z'n langste tijd heeft gehad. En dat vind ik jammer. En daarom snap ik dus niet waarom Sun niet eens wat dingen in Java inbouwt die wel zoden aan de dijk zetten, in plaats van static imports

Met deze opmerkingen kan ik persoonlijk helemaal niks. Het zou misschine wel komen omdat ik erg veel moeite heb in het aannemen van verkooop praatjes . Wat voor dingen mis jij die sun had moeten inbouwen die MS al wel ingebouwd heeft? En voor de rest mbt die lange beta periode. D'r is nauwelijks verschil tussen een jaar wachten op een stable versie of een jaar wachten op de eerste service packs. Beide duurt een jaar voordat ik het op een productie omgeving neer ga zetten.

[ACM]

MSalters schreef op 09 juni 2004 @ 12:27:
Java daarentegen is volledig in handen van Sun. Sun hoeft aan niemand toestemming te vragen voor 1.5 of 1.6. Er is weinig opens aan.

Dat zegt opzich niet zoveel over de openheid

Zolang Sun alles netjes via JSR's/de java community doet en iig de specificaties volledig vrij houdt is het open, imho. Dat het geen internationale/onafhankelijke standaard is, is weer wat anders.

Verwijderd schreef op 09 juni 2004 @ 11:42:
Misschien is dat wel de kracht van Microsoft, ze kunnen zelfstandig bepalen wat ze nou gaan doen, welke features ze toevoegen of welke herzieningen ze willen doorvoeten. Dit draagt volgens mij juist toe aan de snelheid waarmee MS/.NET de markt verovert.

Flauwe inkopper: Volgens mij stel je nou een definitie van het woord 'monopolie' op, "de leverancier bepaald wat er gebeurt, de klant heeft er niks over te zeggen"

[ Voor 5% gewijzigd door ACM op 09-06-2004 13:12 ]

[whoami]

Alarmnummer schreef op 09 juni 2004 @ 12:24:
[...]


Dat zul je met .NET ook gaan krijgen. Dat gebeurt gewoon met alle talen die een tijdje meegaan.

Hmm, dat weet ik nog zo goed niet.
.NET 1.1 is alleszins niet volledig compatible met .NET 1.0.
Je kan in bepaalde gevallen niet zomaar code die je voor .NET 1.0 geschreven hebt compilen naar .NET 1.1
Gelukkig kan je wel een .NET 1.0 en .NET 1.1 omgeving side by side draaien.

[Robtimus]

whoami schreef op 09 juni 2004 @ 13:20:
[...]

Hmm, dat weet ik nog zo goed niet.
.NET 1.1 is alleszins niet volledig compatible met .NET 1.0.
Je kan in bepaalde gevallen niet zomaar code die je voor .NET 1.0 geschreven hebt compilen naar .NET 1.1
Gelukkig kan je wel een .NET 1.0 en .NET 1.1 omgeving side by side draaien.

Geef mij dan maar backwards compatibility.

Ik heb liever dat ik bij het recompilen van oude code waarschuwingen krijg, dan dat ik straks minimaal 3 omgevingen (1.0, 1.1, 2.0, ....) naast elkaar moet hebben. De oude code werkt nml nog steeds even goed in de nieuwe omgeving.

Ok, deprecated betekent dat het ooit kan (en zal?) gaan verdwijnen, maar dat duurt meestal jaren. Kijk maar naar HTML, veel stijlelementen uit HTML 4.0 (oa FONT) zijn in HTML 4.01 al deprecated. Toch is HTML 4.01 al 4.5 jaar oud (24 december 1999), en wordt FONT nog steeds ondersteund.

[Janoz]

Hier zakt daadwerkelijk mijn broek van af. Moet ik straks als gebruiker 1.0 en 1.1 draaien omdat ik toevallig 2 applicaties heb die met een verschillende versie zijn gecompileerd? En hoe wordt dat waneer ze bij 1.5 zijn? Moet ik dan 5x het dotnet framework draaien omdat office voor 1.5 gemaakt is, Visual studio voor 1.4. IE nog met 1.3 werkt. Outlook voor 1.2 is gecompileerd en 1.1 en 1.0 nog voor andere applicaties nodig zijn?

[kasper_vk]

FF on-oorspronkelijke-topic ,

had je het probleem met die static abstract - combi niet kunnen voorkomen door het Singleton pattern anders toe te passen?
(beetje achteraf praten, maar voor de toekomst dan)

Dus niet door een abstracte klasse met alleen maar statics erin (mij m.i. dan niets meer met OO te maken heeft) die je wilt subklassen (wat dan opeens weer wel een OO-mechanisme is).
Maar door de contructor private (/protected) te maken en dan 1 instantie te maken die je via een static getter beschikbaar stelt?

Voorbeeldje uit een eigen project:

Java:

public class Magazijn{

private static Magazijn magazijn = null;

static {
    Magazijn.magazijn = new Magazijn();
}

public static Magazijn getMagazijn() {
    return Magazijn.magazijn;
}

protected Magazijn() {}

// overige code ... 

}

[whoami]

Janoz schreef op 09 juni 2004 @ 13:38:
Hier zakt daadwerkelijk mijn broek van af. Moet ik straks als gebruiker 1.0 en 1.1 draaien omdat ik toevallig 2 applicaties heb die met een verschillende versie zijn gecompileerd? En hoe wordt dat waneer ze bij 1.5 zijn? Moet ik dan 5x het dotnet framework draaien omdat office voor 1.5 gemaakt is, Visual studio voor 1.4. IE nog met 1.3 werkt. Outlook voor 1.2 is gecompileerd en 1.1 en 1.0 nog voor andere applicaties nodig zijn?

Het enige waarbij ik het tegengekomen ben, was met .NET remoting en delegates die door een remoted object afgehandeld werden.
Daar was er voor security issues iets aangepast; ik zal eens opzoeken wat het nu weer was.

klik

Het is, voor zover ik weet, wel zo dat je applicaties die je onder .NET 1.0 geschreven hebt, niet zomaar zullen draaien onder .NET 1.1.

[ Voor 3% gewijzigd door whoami op 09-06-2004 13:57 ]

[Verwijderd]

Je bent dus vrij om te kiezen wat je wilt en daarvoor hoef te de taal niet meer uitgebreid te worden.

Met deze opmerkingen kan ik persoonlijk helemaal niks. Het zou misschine wel komen omdat ik erg veel moeite heb in het aannemen van verkooop praatjes . Wat voor dingen mis jij die sun had moeten inbouwen die MS al wel ingebouwd heeft?

Ik weet dat er voor Java bergen libraries bestaan die ik zelf kan kiezen, maar dat is nou juist mijn punt. Microsoft biedt gewoon bijna alle functionaliteit in hun meegeleverde standaard libraries en dan weet je dat je iets goeds in handen hebt en dat het van een authorative source komt. Naar Java libraries moet je (in mijn ervaring) altijd een tijd zoeken en dan weet je nog niet of die wat je nou hebt de goeie is, of hij nog onderhouden wordt, of het goed gedocumenteerd is etc.

Flauwe inkopper: Volgens mij stel je nou een definitie van het woord 'monopolie' op, "de leverancier bepaald wat er gebeurt, de klant heeft er niks over te zeggen"

Je hebt natuurlijk gelijk, want ik dacht er eerst ook zo over Maar er is toch een verschil. Het is geen monopolie omdat er alternatieven zoals Java zijn, dus je bent niet verplicht Microsoft spul te gebruiken. Het mooie is wel van de andere kant dat Microsoft spul wel goed met alles integreert juist omdat ze alles zelf in handen hebben.

En zeg nou eerlijk, wat wilt het merendeel van de klanten van Microsoft nou voor iets zinnigs zeggen over wat er specifiek met het product moet gebeuren?

FF on-oorspronkelijke-topic ,

had je het probleem met die static abstract - combi niet kunnen voorkomen door het Singleton pattern anders toe te passen?

Jawel, maar ik vroeg met gewoon af waarom dat abstract static een illegale combinatie van modifiers was. Het is eigenlijk heel logisch waarom niet en ik weet niet waarom ik dit heb laten ontaarden in een .NET vs. Java discussie , vooral omdat blijkt dat ik de class waar het om begon niet meer nodig heb

[bigbeng]

Verwijderd schreef op 09 juni 2004 @ 14:43:
Ik weet dat er voor Java bergen libraries bestaan die ik zelf kan kiezen, maar dat is nou juist mijn punt. Microsoft biedt gewoon bijna alle functionaliteit in hun meegeleverde standaard libraries en dan weet je dat je iets goeds in handen hebt en dat het van een authorative source komt. Naar Java libraries moet je (in mijn ervaring) altijd een tijd zoeken en dan weet je nog niet of die wat je nou hebt de goeie is, of hij nog onderhouden wordt, of het goed gedocumenteerd is etc.

Ik ben het hier ten dele mee eens. Het is waar dat de basisdocumentatie van Java (daarmee bedoel ik een soort van wat staat waar enzo) niet optimaal is, terwijl de MSDN library van microsoft per onderwerp een aardige introductie geeft en ook diverse tutorials beschikbaar stelt.

Echter op de Java website zijn voor de meeste onderwerpen wel tutorials te vinden. Betekent alleen iets meer zelfwerkzaamheid. Ook leer je de libraries IMHO pas echt kennen als je een goed Java boek ter hand neemt die op Hello World niveau start en met patterns en complexe objecten eindigt. Maar dat geldt eigenlijk ook voor VB of VC++.

En blijkbaar zit er in de Microsoft documentatie ook nog wel wat gaten als je kijkt naar de toch wel flinke hoeveelheid MS vragen die op dit subforum langskomen.

[Verwijderd]

Ik vraag me eigenlijk een beetje af wat er dan in .NET zit dat zo fantastisch is dat je niet ook op de een of andere manier in Java hebt.
Persoonlijk vind ik de Standard Edition al een redelijke hoeveelheid middelen bieden voor het bouwen van GUI's, utilities, netwerken enz..

Als je XML nodig hebt dan voeg je de nieuwe XML api's toe en als je enterprise functionaliteit nodig hebt voeg je J2EE toe. Voor 3D programming voeg je dan weer Java3D toe.
Allen zijn beschikbaar op de sun website en zijn standaard dus waarom je je zorgen moet maken over de kwaliteit van de implementatie snap ik niet zo.
Als je de sun oplossing niet vertrouwd dan neem je toch die van een andere.