A programmers comparison of C# versus Java


News: A programmers comparison of C# versus Java

  1. A programmers comparison of C# versus Java (44 messages)

    An excellent overview of similarities and differences between the language features and libraries of the C# and Java programming languages has been posted, with illustrative code snippets tested on Microsoft's .NET Framework Beta 2 for C# and J2SE version 1.4 Beta 2 for the Java.

    Check out C#/Java Comparison, by Dare Obasanjo.

    Threaded Messages (44)

  2. Who cares? I thought this was a J2EE community? Do you happen to work for Micro$soft?
  3. Well..I think we should care. This was posted on /. (slashdot.org) earlier this week and I was amazed to see that the majority of the opinions on this rather open-minded community were embracing the idea the MS has created a superior product with C#. There are even ideas that most of the C++ programmers would move on to C# and that it's "more" OO than Java, as well as it requires less code and effort to get things done.
    I think the Java community has to pay attention. As someone noted, MS has been very good at catching competitors "sleeping at the wheel" and crushing them.
  4. I thought this article was extremely interesting too, and as Java developers we <i>should</i> care about good M$ technologies (do like that dollar sign thing? I invented that :-) not only because their a potential threat but also because they can be learned from.

    I call C# a "good" technology because last week I was brainstorming about how I'd change Java if I could, and of the half-dozen or so things I came up with (like explicit resource deallocation without having to use a finally{} block, or a foreach loop) it turns out that C# offers all of them, more-or-less. Granted, it includes a few relics from C++ that I'm <i>glad</i> Java doesn't support, too, but all-in-all it seems like a step forward. I don't know if Sun's planning on evolving the Java language much anytime soon, but I hope so.
  5. Although Dare has done a pretty good job in comparing the technologies, a number of the Java examples don't really show the best use of the language. Additionally, a number of the features included in C# were specifically omitted from Java due to their potential for abuse and/or obscuring the meaning, for example operator overloading, goto statement and enumerations (enum). Usually, a similar thing can be achieved in Java, sometimes with additional benefits - for example, Dare's discussion of enumerations seems to imply that this is a weakness in Java; however, one can use the typesafe enum class pattern which actually provides a much more powerful, extensible, mechanism than C# enums (e.g. for a basic example, see http://www.hio.hen.nl/~akkersdi/java/enum.html).
  6. I wouldn't worry about it - he didn't show C# in the best light either (eg, implying that dynamic class loading is something Java has but C# doesn't).
    The enum pattern you mentioned is interesting. Why do you think it's more flexible/powerful than C's enum construct?
  7. RE: typesafe enums in Java[ Go to top ]


    For a discussion of typesafe enums in Java and a comparison to C enums, see:

  8. RE: typesafe enums in Java[ Go to top ]


    Thanks, I meant C#, not C! C# enums are type-safe. I guess I see C#'s main value add over Java as being the formalisation of various patterns/idioms that emerged in Java (but haven't been built into the language). Things like properties (which formalise the get/set idiom), type-safe enums (OK, so you can't extend an enum, but it's a value type, which I like), indexers and (especially) events. The counterpoint to these "additions" seems to be either that Java doesn't need them or that they were left out for safety reasons. Well, to each their own, but a language feature isn't always "bad" just because it's a source of problems. Usually it's the implementation that's at fault. Java left out enums (some would say) because they're not type-safe. C# made them type-safe and left them in. Sun balked at delegates because "any implementation of bound method references will either be inefficient or non-portable" [0]. The CLR made them efficient (through native compilation) and they're naturally portable because it's a greenfield framework. Java disallows operator overloading (although special-cases it for use under the hood..), C# allows selective overloading (and it's nice to be able to overload things like + and - when warranted). Anyway, I'm just adding to the noise. Ta ta!



  9. I whole-heartedly agree - more is not necessarily better in a language (and the article seems to draw that conclusion even though, on the whole, it is a very good, balanced article).

    Java's big attraction has always been that it is "simple". It is true that it does not contain certain features such as:
    + Operator overloading
    + Code Pre-processing
    + Value Types
    + Aliases
    + Variable length parameter lists.
    + multitude of signed/unsigned sizes of integers
    + enums

    But I dont lose any sleep over this - nor, it seems, do most developers (as far as I am aware). In general, I would say that Java leaves less rope lying around to hang yourself on.

    One particular thing I dont like in C# (so far) is the way polymorphism is handled. True - the C# way is "safer" as it prevents inadvertant overriding - but I cant say this problem has ever occurred to me yet. However, inadvertantly NOT overriding was a common occurance in C++ - which (unless I am mistaken) is still possible in C#.
    The lack of checked exceptions is also very, very ugly - I hadnt realised this until I read the article.

    Also, there is some (for me) unintuitive bahavior in situations where there is a combination of overloading and inheritance.
    If there is a method that takes a short in a base class, and an overloaded method that takes an int in the derived class, and on an instance of your derived class you call the method with a short - the derived class method is called because the run-time chooses to cast before searching the inheritance tree!
    I like the simple, always-override behaviour of Java.

    Having said that, there are some nice features in C# (simple things, I admit, but nice):
    + overflow checking, using a checked {} block
    + more safety in Switch statements (you have to explicitly declare a fall-through)
    + support for stings in Switch statements
    + the "as" operator that performs an "if (a instanceof A) {obj = (A)a}"
    + foreach
    + deterministic Object cleanup (though, this is a bit of smoke and mirrors - the developer has to do all the work! this can be implement in Java - though it is good to see it standardised)

    I think that Java vs C# debate is somewhat of a tired horse - however, I also think the language is somewhat important if you are making a decision on which platform to standardise. C# will be the language of choice for .Net, in my mind - so you would want, at least, to be satisfied that the difference (should it be negative) is small between the primary implementation languages. (Not too many people would eagerly choose .Net if C# was as unpleasant as C++ to work with?)

    However, my first impressions are that they are very similar - but Java is simpler.

  10. Sun spent considerable time and effort removing the land mines from C++ when they created Java. Now MS has put half of them back in with C#. Are there any Java developers really want to use pointers again?
  11. I first got into java in 1996, after completing a unix port of a windows product - ie c++, motif, X-windows. It took a year, and the compilation for HP, SOlaris, AIX etc was a complete nightmare. Before this I has tried to do some graphics stuff with MFC and was amazed at just how bad microsoft class libraries were. X-windows was actually easier.

    And then came java. Suddenly windows programming was easy, and it worked with only a little extra effort on the unix platforms.

    Then the internet came along and we all turned web. html became the gui language of choice and the server side becomes important. Java still ruled, you could develop on your home PC, and then shift up to the production box on unix.

    And now we have c#. People are saying it is better than MFC and C++ - which is actually very easy to achieve. They may be saying it is better than java.....

    I'd say this now gives us a little more choice, i.e. if you believe your server side architecture will always be MS then maybe you should choose it. If you think you may EVER ship to a client with unix/linux, or you may need to change your server side architecture then Java remains your only choice.

    I'd say choice is the key to this. If you want to protect your right to choose then you must ignore c#.

    If you want to get a departmental project out the door and run the server from your desk, and build up your CV, then c# is probably it... Wierdly, departmental projects could always be done with VB, the only difference now is the CV building.

  12. One question that pops into my mind is;
    Are Microsoft beating Sun with the Sun's own Stick?

    IMHO.......and extra Blah blah.......
    MS Marketing Policy with C# is not to offer the world a choice but is;
    "If you can't beat them, join them, then we are sure of some success" policy.

    If you present me with a "choice" of A(Sun Java) or B(MS .Net) and both A and B do more or less the same thing does B have a better or same chance as A?
    As we are all individuals the answers are many but both will exist.

    However, from a "delivery-to-you" point of view MS have the luxury of been able to take a very long term Strategy. Combined with a widely dispirsed OS they can think they can mould, (an interesting word with multiple meanings). The Internet Rev-olutionis still in it's early stages so the stakes are high.

    But if we are aware, all in all, for the Java community .Net will have a very good effect.

    On the ground Java does needs a new PR exercise.(Many non-tech persons have still got a this image of Java, "it's slow, buggy, unsecure and doesn't work").
    We need the Guru's to re-awaken, explain why Java was/is made like it is. In other words we DON'T need a new language we need to re-value what we have. These Guru's need to put the language further on top, again. They can start using something from the MS policy, what good in MS .Net, what can Java take from it?
    Think, use the MS Strategy to improve the value of our lives ........
    MS are masters of the inverse but you, you live in a Universe!

    So, if your a Java Guru I would say learn .Net, take the free Beta copy, BUT REMEMBER, make sure you tell the java community all about your experience, what you've learned......so we can keep this community up to date in the ways that are best.

    We should never move to into a Mono-Soft environment. In life you have two eyes and ears to give you two different points of view. Cover one and see how your life changes.

    (Who sometimes wish he had two heads)
  13. i agree with you absolutely about shutting eyes and ears.
  14. This is a long one.
    This is one of those interesting replies where a lot of sense is spoken in an emotional way.
    I notice that Stephen sometimes wishes he had two heads.
    I can't resist plunging in here. Stephen, realise that these comments are not directed at you.
    Schizophrenia is often thought of as being in two or multiple minds, but it has been pointed out that it really means broken hearted (schiz as in schism and phrenos as in love or heart).
    It is also often thought that people who become disturbed in this way are responding to emotional wrenches in their (childhood) environment, that pull them in different directions.
    Now I'm going to tell you some further facts of human psychology.
    It is a fact that we respond to being nurtured.
    It is a fact that in being nurtured we identify the source of nurturance as parental figures.
    It is a fact that we expect a lot (often more than is possible) from those so identified figures.
    And it is also a fact that many so identified (the recipients of the projections) feel uncomfortable with this and find it difficult to respond appropriately.
    Finally it is also a fact that groups can behave as an individual (in some respects) and can be identified in either of the roles I've just outlined, the parental one more likely being an organization.
    Now, given these facts, to the reality we are addressing here.
    It is a sad fact that one cannot have two heads. One may be nurtured in the way of Java or one may be nurtured in C#. It is true that a programmer can be expert in both, but two things. Such a person may find it difficult and experience the feeling that they are being disloyal and also, over time, programmers will tend to be trained in only one of the technologies.
    This suggests some further points. That the economic battle between Java oriented commercial organizations and MS oriented commercial organization is experienced by the programmer as a rift between mother and father, with one side staying loyal to one parent while one's siblings are "disloyal" by supporting the other figure.
    Everyone in the commercial environment thinks it is a place where no hostages should be taken and no tears shed.
    I'm not convinced.
    I'm not convinced that a viable commercial strategy can be followed through without taking some prisoners and shedding some tears. In other words, without reflecting thoroughly on what one is doing and what affect it will have.
    MS have a monopoly that guarantees the desktop real estate and vouchsafes a revenue stream. Look at how little their shares have suffered recently.
    They are a powerful adversary with very deep pockets.
    The attraction to programmers, who are the "children" in this scenario, may be irresistible. They want to be nurtured, they do not want the burdens of the world on their shoulders.
    But, of course, we are adults. While we may want to be nurtured, unavoidably, we also do have the burdens of being adult.
    Stephen says "We need the Guru's to re-awaken, explain why Java was/is made like it is."
    I have come across this sentiment many times. We want our parents to take a greater interest in us, to look after us and to protect us.
    But the crucial thing is, how can they?
    It is clear that the way in which they do is how they shall be measured henceforth.
    Consider this.
    Twenty years ago Microsoft would openly say that they are not looking for "well rounded" personalities when they hire.
    You would never find them make a statement like that now as corporate life and the drive for respectability have taken over.
    So have they lost the ability to attract the brilliant maverick?
    What we know about open source is that (unless you are being employed to write this code) it is unpaid work. What ever the benefits to the individual in terms of becoming expert, they must have some alternative source of income. And that can only work if projects are plentiful enough.
    Nevertheless, and it is part of the appeal, there is a maverick side to open source. Some large companies hope that not only will they contribute to it but that they can draw from the pool when they need the talent and skills.
    Obviously, if the market is poor, just like anyone else, they will not be hiring.
    Microsoft, on the other hand, does not support open source. But they are pump priming the market to gain market share.
    Of the two communities, Microsoft is far more hierarchical and structured, with control issuing from Redmond, and, therefore, any desire to really innovate also mainly remaining in Redmond.
    Where does this leave us?
    Well, I hope it shows that there are strategic decisions that need to be made, that can only be made by large corporations and that it is better to have a thought about these issues than to carry on unthinkingly. After all, whether or not to pursue C# is a free choice with long lasting consequences for the individual. Better to try, at least, to think about this.
    While I cannot conclude as to what large corporations should do, a guru who takes a higher profile may take air time from one of his or her colleagues who wish to announce something. Spending more on open source development may not be wise when the market is down, and so on, I can identify two points.
    The first that I think applies particularly to Sun, is that some are borne great and some have greatness thrust upon them. Sun should not shy from the, often very uncomfortable, role of leadership they have.
    The second is that it is, dare I say it, the subversive appeal of being a developer that drives many. It leaves them wanting the collegiate feel of the Java community that is less hierarchical and structured than many. But it may also leave them feeling venerable and unprotected in a way that may not be the case of developers in the more structured MS community. Also notice the conflict in this point with the role of leadership that I identify Sun as having.
    My final point is that, when you strip everything away, it is people's attitude to their perception of this conflict that sells or does not sell an MS or Java based solution. It may be less relevant here to point out that MS leads to an homogenous solution (that may be the appeal) than that within the commercial Java community there is healthy competition which leads to improvement and innovation. And then continue to fulfil that promise.
    Adam Saltiel
  15. Hi Adam,

    The debate over Java Vs C# should be discussed at both a technical level and also at a psychological level..........

    May I take it you are part of the open source community....?
    If so one thing I would like the open source community to point out to the developer world more effectively is, the benefit one can get from doing something, something for yourself and others, not your everyday employer, and even something done for nothing. This type of work leaves a longer lasting print on the mind!

    I understand your comments about how easy it is for developers nowaday when making or working with technology choices, for them to feel like they are battling with their parents, aka. I would like to stay with this one technology and let it mature with me but I am forced to work with many, because my parents, (employer) may insist that this be so.
    With a new technology like C# in the mix the java community that is exposed to the corporate world is about to get it's biggest trauma to-date. As long as the java community in general is aware of this fact it will may be a problem. I would like to see some assistance from the likes of Sun and similiar Enterprises on how these programmers should approach the C# issue. How should C# be work with it in conjunction with Java, because in the corporate world for a lot of developers their employer will not let them sit there and ignore it. You can be sure Microsoft will publishing lots, lots for Java Developers on how to use C#.
    One approach that I sugested was to look at C# as a mechanism to help improve what we already know. Like you say we all like to be nurtured...but this can only happening if the guardians of Java are on board.

    Java and C# may be both good technologies but with this "similiar-technology" era now unpon us, if we don't start to figure some way to combine or isolate we may all end up a bunch of Schizophrenic Developers with no real sense of direction, just waiting for the next new thing to come along so we can get our High.......to climb you need to be below!

    If C# is "so like" Java doesn't this statement in itself indicate that Java is a right technology for the developer community?
  16. I've written non-trivial programs in both languages. I see C# as basically Java with a bunch of small improvements - mainly improvements that make for more elegant, self documenting code. Here a few feature that I like in C#. Each of these allows for cleaner, more elegant code (as compared to Java) in my opinion.

    - Enums. I know you can create Java enums using a number of design patterns but these are a hack IMO. Enum support in C# is very elegant. Try this in Java: System.out.println(myNode.getNodeType()) and then try the same thing in C#. In Java, you'll get a number in C# you'll get a word.

    - Property procedure. VB has had this for years. These are more elegant, readable and terse than Java's get/set conventions:

      In Java: obj.setLength(10);
      In C#: obj.Length = 10;

    - Delegates (event handling). These are C#s way to do type safe call backs. In Java, an event handler is an "object" (a dumb idea in my opinion). In C#, an event handler is a "function". A delegate is sort of a one-method interface. In C#, you won't see anything as ugly as, say, WindowAdapter.

    - Overrides must be declared. In Java if you override a method, and misspell the method name in the subclass you will find out after the program ships. In c#, you find out at compile time.

    - Attributes: What do java.rmi.Remote and java.io.Serializable have in common? Neither have any methods! What a hack! C# has the ability to "tag" methods and classes (and other stuff) with meta-data:

      In Java:
        class MyClass implements Serializable{
      In C#:
        class MyClass{

    - Stack based objects (or value objects).

    - Indexers.
      In Java:
        x = myArray[4];
        y = myList.get(4);
      In C#:
        x = myArray[4];
        y = myList[4]; //more consistent IMO
    - Everything is an Object. No need for those "wrapper" classes:
      In Java:
        Integer I = new Integer(10);
        x = I.intValue() + 50;
      In C#:
        int I;
        x = I + 50;
    These are all improvements over Java. C#, IMO is Java ++ :). One thing I like better about Java: When I install a JDK, my browser and web browser don't get automatically update to version 6.0 beta. This is not the case with DOT NET.
    Dave Ford
    Smart Soft - The Developer Training Company
  17. ..and one more thing the Java community has to expect:a targetted, systematic, well guided and motivated campaign to turn over to C# development. Expect this in every form and shape, from every side you can imagine, for example a bunch of "nice guys", well-intended, who worked with both technologies but they can convince you that C# is better. Don't forget that MS is betting their very own company on this technology. And they do have resources.
    For Sun it will be more and more difficult to cope on its own against this targetted campaign. After all, the big difference is the Java community and the multitude of vendors in this space. So it's up to the technical architects who decide the future enterprise architectures to decide the future platform. And of course there are plenty of VB projects that have to be re-written.
    C# is definetly better than VB.NET ;-)
  18. What good is C# if there are no commercially available application servers that support it? We can write EJB 2.0 applications on Weblogic, IBm, iPlanet, etc.. app server today and deploy them on humungous Unix servers.

    Will C# ever support the volume that Java currently supports? The answer is not in the software. It's the hardware. Does any one really think Sun, IBM, and HP will abandon their Unix for MS XP? Will XP ever be as reliable as Unix?

    C# may be a better a language but where's the hardware and OS to support it. There's no way I would trust a MS server to house mission critical applications. There's a reason why large, important databases are hosted on Unix and mainframes and not MS servers: reliability and scalibity.

    Ultimately, its the hardware and OS that will determine the market penetration of C#. Until MS fixes and improves XP to perform as well as Unix, there's no comparison on the high end market. MS has been trying to break into the high end market but their OS keeps holding them back.

  19. Dave,
      I don't think you understand how callbacks work, or how the event model was built in JDK 1.1. Here's what you said:

    "Delegates (event handling). These are C#s way to do type safe call backs. In Java, an event handler is an "object" (a dumb idea in my opinion). In C#, an event handler is a "function". A delegate is sort of a one-method interface. In C#, you won't see anything as ugly as, say, WindowAdapter."

    Everything in Java is an 'object', and if you don't like OOP, perhaps you should look to another language to program in. Event handlers are particular TYPES of objects, and the type of event handler an object is depends on the interface it implements. I have no idea why you think that they are not type safe!? If you add a event listener to a component it is checked to ensure that the proper listener is added to the component. How is that not typesafe?

    A 'WindowAdapter' is a default implementation of a 'WindowListener' and it defines the different types of events that you can listen for (opening, maximizing, minimizing, resizing). The WindowAdapter's purpose in life is to save programmers time in implementing a WindowListener, so that they can subclass a WindowAdapter and just override the methods that they care about. You don't NEED a WindowAdapter to handle window events, just implement the WindowListener interface on your class and you have your event handler.

    Delegates (due to their one-method per instance nature) do NOTHING to describe the types of events a particular listener can recieve. In my opinion, delagates are very un-OO and one thing that Java shines at is it's consistency (which makes it more readable).

    Then you go on to say:
    "- Attributes: What do java.rmi.Remote and java.io.Serializable have in common? Neither have any methods! What a hack! C# has the ability to "tag" methods and classes (and other stuff) with meta-data:

      In Java:
        class MyClass implements Serializable{
      In C#:
        class MyClass{

    Did you know that the [Serializable] tag tells the class to implement that interface? Again, it's a matter of consistency: If you want to denote that a class is of a particular type, you tell it to implement an interface...In the case of serializable, you are indicating that a class can be serialized...in the case of Remote, it indicates that the class can be called remotely. They are using the language properly for these functions.

    Your next gem is:
    "- Indexers.
      In Java:
        x = myArray[4];
        y = myList.get(4);
      In C#:
        x = myArray[4];
        y = myList[4]; //more consistent IMO

    There is a definite distinction between arrays of objects and 'maps' of objects, and it is important to know what type of object you are dealing with....myList[4] makes it look like you are dealing with an array, but does that mean that I can call System.arrayCopy(myList,0,myNewList,0,myList.length)? No, because myList isn't an array...It's confusing especially from a standpoint of a third party looking at the code. This is the same argument as operator overloading, it makes perfect sense to the person who wrote it, but the new guy who needs to take ownership of the code now needs to decipher what an operator really does (instead of just spelling it out in the code).

    Many of your comments (and comments from other posters like yours) seem to stem from either 1) 'cuteness' (I want a preprocessor! It's cute!) or 2) an apparant lack of understanding of proper programming designs in Java. If you take a veteran C programmer and tell him to write code in Java, you'll get a Java program that has C structure (which is typically a POS). Trust me, I've seen this many times when cross-training C developers. If you want to program in C#, think like a C# developer. If you want to write in Java, think like a Java developer. Most of your comments stem from a C programmers perspective looking at C# and Java, and you identify some things in C# that were pulled from C and you tout that as 'better'....Whatever.

  20. This
        class MyClass{}

    is horrible looking. I have to say it looks very contrived.

    "Everything in Java is an 'object', and if you don't like OOP, perhaps you should look to another language to program in"

    int i;

    "This is the same argument as operator overloading, it makes perfect sense to the person who wrote it, but the new guy who needs to take ownership of the code now needs to decipher what an operator really does (instead of just spelling it out in the code)."

    ComplexNumber c1(1, 5);
    ComplexNumber c2(2.2, 5);
    ComplexNumber c3 = c1 + c2;
    if(c1 < c3) {...}

    This is so much better than the Java way. And it is more OO. Objects are just data and their related methods.
    Overloaded operators are just methods. If it makes you feel better you can write it out (c3.operator=(c1, c2) or whatever).

    Heck, they made '+' and '+' work for String. That's not consistent with the rest of the language.

    "Many of your comments (and comments from other posters like yours) seem to stem from either 1) 'cuteness' (I want a preprocessor! It's cute!)"

    It's cute? It's highly useful. It can be used as a form of "pass by name" to extend the language. Granted, a good bit of it is used for platform independnent building which is not needed in Java but Java would still be better if it had it.

    "If you take a veteran C programmer and tell him to write code in Java, you'll get a Java program that has C structure (which is typically a POS). Trust me, I've seen this many times when cross-training C developers."

    Maybe, just maybe true with some C developers. My experience (from C to C++ to Java) is that Java developers are the worst by far. Knowing an OO language does not mean knowing anything about OO. The only decent Java developers I've ever known are ones who know C++.

  21. "int i;" is a counter example?!? If you don't want to use native types, then don't. Typically, tho, it isn't worth the object creation to create a class to wrap an integer object....this would be insane:

    for (Integer i = new Integer(0); i.valueOf() < 10000; i = new Integer(i.valueOf() + 1))
      // do stuff

    Save yourself the object creation and use the native type. Is this un-OO? I don't think so.

    And as far as operator overloading, what do you think the following code is doing:

    myList >> aList;
    myList <
    Don't know? How about this:


    You save yourself 10 keystrokes, but which is more readable? The old '+ operator' argument is so lame, it's like the exception to the 'operator overloading sucks' rule (which is why they actually overloaded + for Strings in Java.)

    You say:
    "It's cute? It's highly useful."

    I say:
    "It's just cute."

    As far as C++ being the best OO progammers for Java, I've seen many C programmers use g++ to compile their C code and call themselves C++ programmers to know that just because they claim to be C++ programmers doesn't mean squat. Proof is in the pudding.


  22. A programmers comparison of C# versus Java
    Hi Stephen,
    I should have got back to you in this thread sooner, but I guess you're still tracking it as your last post was 5th Dec.
    "May I take it you are part of the open source community....?"
    I greatly admire the open source community, well actually I admire any developer who (and developer teams that) sits down with the drive and patience to tackle the technical problems of coding, whether they receive remuneration per hour or the less tangible benefits of learning stuff or doing really original work. Anyway Open Source != unpaid as e.g. IBM pay their own developers to contribute to Open Source quite massively, and then there is also &#8220;open research&#8221;, again e.g. IBM.
    I'm a developer/consultant in J2EE, having moved into this fairly late in my life. I also take an interest in the way things unfold, as I do I can't help but draw on my past career (don't hold your breath) as a psychoanalyst. I am conceivably one of the only, if not the only, person to be both a psychoanalyst and Sun Certified J2EE.
    Does this help me with understanding coding detail?
    I doubt it.
    Could it help others?
    Well, I would like to think so, but others must and will be the judge of that.
    "If so one thing I would like the open source community to point out to the developer world more effectively is, the benefit one can get from doing something, something for yourself and others, not your everyday employer, and even something done for nothing. This type of work leaves a longer lasting print on the mind!"
    Yes. I noticed on JBoss.org the phrase "... the right to develop."
    I visited one of the better London secondary schools a short while ago on an open day in respect of one of my daughters.
    I asked if they teach any programming languages. I was told they do not, anyway Cambridge, where one of their girls is going, prefer them not to take the A level (final school exam prior to uni.) in Information Technology.
    Would this sort of thing be said about any other subject?
    The person taking over the Linux core is just 18, started at 14.
    Programming is a passion for many people, a skill analogous in many respects to being a musician.
    What distinguishes the activity of the developer is that there are so many skilled people operating on an intense intellectual working level who currently depend on commercial organizations for their income as opposed to musicians, who depend an audiences. (Interestingly there are grey areas.)
    &#8220;With a new technology like C# in the mix the java community that is exposed to the corporate world is about to get it's biggest trauma to-date. &#8230; we all like to be nurtured...but this can only happening if the guardians of Java are on board.&#8221;
    I think what you say here must be right. High profile figures can&#8217;t just ignore or bad mouth C# and, on a different level there needs to be thinking about how the two technologies interface and inter-operate. Being defensive wont stall the inevitable.
    The article that inspired this thread looks at the issue as a comparison on the syntactic level of the languages.
    Dare doesn&#8217;t tell us why he draws the line at the point he has, by the way nor does he, in every case, compare like with like. (Treatment of Attributes, Runtime Code Generation, Pass by Reference/Value seem inaccurate or not even handed, his statements are often extremely tendentious.)
    In comparing the language he doesn&#8217;t look at support in the following areas: -
    1. package
    2. component library
    3. design
    4. architectural including language extensions
    5. tool, including code generators and modelling
    6. training
    7. literature
    8. app vendors of add on services such as components, monitoring in both development and deployed environment etc., etc.
    What ever makes up a good environment will include a mix of all eight points (these could be broken down further) plus actual performance of the platform, people skills available and people costs. There is much work to be done here in generating accurate or at least benchmark metrics.
    Then one has to project a trajectory through those points to take a view on the reliability of one&#8217;s supplier(s). One would then be in a position to make a more thorough Cost Benefit Analysis (CBA), which is really what is needed here.
    The notion of DLL Hell was introduced to me in Byte several years ago. I&#8217;ve just been looking for the reference, but cannot find it (what I did find is, perhaps, more interesting, see below). Ironically, this term has been adopted by MS and even appears in their technical dictionary.
    However, with respect versioning, there are solutions for Java, though not part of the language, for instance MetaDyne&#8217;s, Metanix and ComponentDNA (http://www.metadyne.uk.com/).
    Dare also uses Java 1.4 beta to compare with C# beta, but he does not mention assertions which are supported in this release, one of the features added as a result of discourse with the developer community in the JCP.
    Similarly, in the Java world, Attributes are being looked at under the guise of aspects (aspectj.org) and other Software Engineering developments such as Hyperspace and MDSOC (IBM, Separation of Concerns computing). These are an extension to Java 2, which I should think could implement the functionality of Attributes. I notice that Attributes function more like directives and depend on the compiler, isn&#8217;t this more like running a script? whereas, aspects are built into the language (extension of aspectj), this approaches the problematic from an architectural perspective and thus really furthers engineering concepts and understanding, whereas Dare is just looking at a one off functionality attribute point of the language (plus IDE plus OS).
    This touches on another issue barely mentioned, that of the future of the languages.
    As can be seen, actually Java is a dynamic and growing language contributed to by both the JCP, which is open to inspection (and participation) so that movement can be anticipated, and by other projects such as the example of aspect.org that extend its functionality in different and important directions.

    To return to the eight points mentioned above, issues of e.g. early or late binding, though leading to a technically significant exchange ending with &#8220;but if the value of your enum affects the behaviour of the method which uses it, you should ReplaceTypeCodeWithPolymorphism&#8221;, it is a tiny factor in all of this.
    I predict that increasingly projects will only be given assent where the metrics are present and correct in terms of a thorough CBA.
    So, once again, industry slanging matches will not halt the inevitable, they will just make the purchaser rightly seek independent opinion.
    &#8220;If C# is "so like" Java doesn't this statement in itself indicate that Java is a right technology for the developer community?&#8221;
    You mean imitation is the sincerest form of flattery? If we mean in some technical sense, then if C# vindicates Java it must also, in the process, vindicate itself and we are still left having to compare points. On pure syntax, C# seems to score. After all it has been designed to capitalize on some of Java&#8217;s perceived weaknesses (not including error checking was justified on the basis of a study that indicated it would not impede large projects, but I think it was adopted for the tactical reason that it shouldn&#8217;t impede VB programmers, needed to come on board).
    There isn&#8217;t a right technology, there is a market place for technologies and making any intelligent assessment of the situation at the moment, let alone extrapolating into the future on the basis of that assessment, must go back to points I have already raised.
    I mentioned I found something interesting looking for the Byte article. This is The Significance of Dot Net by Bertrand Meyer (http://www.sdmagazine.com/documents/s=738/sdm0011l/0011l.htm).
    This is an article very favourable to .NET, but is well worth reading for its clarity (as ever with Bertrand Meyer) and well reasoned argument. But note, his support is for the .NET framework because it support Eiffel# not C#!
  23. I apologise for the way ' and '' have been converted.
    You will know the reasons, incompatability between Windows char set (I like to spell check in MS Word) and ISO 8859-1. So it is! Seasons greatings!!
  24. Good article, but language comparisons are rarely fair. For instance, lots of the painful omittions in Java are due to the portability-before-usability and portability-before-speed strategy. Fair enough.

    C++ is often thrown into these discussion, but posters never seem to reckognize that C++ was designed 15 years ago as a system-biased OO language with C compability. I'd say Stroustrup succeeded!
  25. It seems that C# has added some features that Java left out. Some of these things, however, seem extremely contrived. An example is the stacked-based objects.
    Java is a third-rate language. And C# is a third-rate language.
    If it weren't for platform issues Java would be totally worthless. It has too many important things missing:

    1) Stack lifetime objects. When design decisions are made because "we can't use too many objects because of memory" and "the garbage collector is too resource heavy to have to invoke on a regular basis" then something sucks badly.
    Moving the stack pointer takes, what, 1 machine instruction.
    If you're going to make me construct an object on the stack then let me delete it when I'm done.

    2) Not having deterministic object lifetimes. See 1 also.

    3) No generics. Nice little things like the Iterator interface become useless because casting is required. Collections require casting, etc. I want to catch my errors at compile time.

    4) No operator overloading. String s1 = "hello"; String s2 = "world"; if(s1.equals(s2)) ... UGH!

    5) (minor) No defaulting of parameters.

    6) Putting constants in interfaces. This is a hack because of no multiple implementation inheritance. An interface with only constants is OO blasphemy. And with good reason.

    7) No preprocessor.

    8) No enums.

    As a language C++ is far richer and far more powerful than Java or C#. It does not have built in support for threading and exception handling is added in an awkward manner but it is so much better. And the speed....

  26. Exactly how do you propose removing a variable from the middle of stack with one machine instruction? Your post smacks of someone who bandies computing terms around without fully understanding what he is talking about.

  27. did I say remove anything from the middle of the stack?
    Here's a simple example of how it works:

    class X {
    int x;

    class Y {
    void foo() { X x; print("hello, I don't know what I'm talking about"; }


    main() {
    Y y = new Y();

    y is created, stack pointer value is saved, foo() gets called, stack pointer is 'moved' the size of X, X's constructor gets called(with stack address of beginning of X), print() gets called, X's destructor gets called, stack pointer gets value of what it was prior to call of foo(). The memory that used to be X is now reclaimed stack memory.

    Get it?
  28. Quote from your previous post; "If you're going to make me construct an object on the stack then let me delete it when I'm done. "

    Since Java doesn't allow one to construct objects on the stack and C# does then the only way the above statement makes sense is if you are asking for a way to DELETE stack objects when you are done with them which would involve being able to remove objects from the middle of the stack.

    Now if all you had said was that you wished Java had the ability to create stack based objects like C++ or C# then the meaning of your comment would not have been misconstrued.
  29. "If you're going to make me construct an object on the stack then let me delete it when I'm done. "

    Replace "stack" with "heap".
  30. I just have a short comment on what you write in your point 7 (and I have also seen others commenting on this):

    7) No preprocessor.

    This seems a bit inaccurate, since it definitely is possible to write Java preprosessors.

    SQLJ from Sun, AspectJ from aspectj.org and iContract from reliable-systems are good examples on Java preprosessors.

    So, there might not be built-in support in J2SE for preprosessors in Java - but they most definitely exist!

    Knut Erik Ballestad
  31. Interesting article. Here are some issues that I've noted:

    1) First of all, in many places, the comparison goes well beyond the initial goal of comparing two programming languages. For example, JVM is compared with .NET Framework in some respects, like:
    - bytecode vs. IL format
    - java libraries vs. .NET (language-independent) class libraries
    - JAR files vs. .NET Assemblies, etc.

    Anyway, the distinction is blurred by the fact that the name "Java" is used interchangeably by either the language or the runtime. Also, more confusion is added by the fact that several features of C# language (for example attributes or cross-language interoperability) are dependent on the .NET Framework.

    But we should at least be aware about this distinction between the discussion that compare C#/Java programming languages AND the comparison between JVM and .NET Framework.

    2) In my opinion C# looks closer to C++ than to Java (and even Java borrows a lot of things from C++). From that respect, I expected initially a comparation that shows first the differences between C# and C++, outlined in parallel with the differences between C# and Java. Anyway, even under this point of view, the language-related comparisons are mostly correct.

    3) About Java Extensions: I am not sure about the following phrase:

    >>> A C# parallel would be the ability to create assemblies that are treated as if they are part of the System namespace contained in the System.dll assembly.

    It is very easy to extend the System namespace with a custom class, for example:

    using System;

    namespace System {
      public class Test {
        public static void HelloWorld() {
          Console.WriteLine("Hello World!");

    You can then generate an assembly can be made "shared" by giving it a strong name, then install it under the Global Assembly Cache so that other apps can use it.

    4) About dynamic class loading: I don't guite understand:

    >>> C# and the .NET Remoting mechanism also enable remotely downloading classes from one machine to the other but the client has to publish the assembly and the server can then load it via a URL.

    In reality, in .NET Framework approach, no code needs to be transfered from server to client (as opposed to RMI) or from client to server. That's because, even if you create a proxy at the client side all the needed information is provided by the object metadata. Obviously you still need remote (i.e. server) object metadata when you compile the client (but probably even that is optional, given the reflection support in .NET). Here is a quote from the ".NET Remoting" article that can be found at:


    "When the object is registered, the framework creates an object reference for this remote object and then extracts the required metadata about the object from the assembly. This information, together with the URI and assembly name, is then stored in the object reference that is filed in a remoting framework table used for tracking registered remote objects. It is important to note that the remote object itself is not instantiated by the registration process. This only happens when a client attempts to call a method on the object or activates the object from the client side.

    Any client that knows the URI of this object can now obtain a proxy for this object by registering the channel it prefers with ChannelServices and activating the object by calling new, GetObject, or CreateInstance. The following code snippet shows an example of how this is done.

          ChannelServices.RegisterChannel(new TcpChannel());
          HelloServer obj = (HelloServer)Activator.GetObject(

    Here "tcp://localhost:8085/SayHello" specifies that we wish to connect to the remote object at the SayHello endpoint using TCP on port 8085.
    The compiler obviously requires type information about the HelloServer class when this client code is compiled. This information can be provided in one of the following ways:
    - Provide a reference to the assembly where the HelloService class is stored.
    - Split the remote object into an implementation and interface class and use the interface as a reference when compiling the client.
    - Use the SOAPSUDS tool to extract the required metadata directly from the endpoint. This tool connects to the endpoint provided, extracts the metadata, and generates an assembly or source code that can then be used to compile the client."

    5) Anonymous inner classes: The article correctly points out that these are used in Java in order to implement callbacks. But in C# the callbacks are natively exposed/implemented using .NET delegates.

    Another usage for anonymous inner classes pointed by the author is the "State Design Pattern" but here nothing stops us to use a set of an non-anonymous inner classes instead. Besides, it is safer to define the NOT_LOGGED_IN, NO_OPEN_DOCUMENT, etc. as derived classes from ClientState and even define their unique instances as static members of the ClientState class. In conclusion I'm not sure if anonymous inner classes are really needed.

    An example below. BTW, note how the derived classes are members of the base class - funny, isn't it?

    public class ClientState {
        ClientState() {} // prevents inheritance
        public class C_NOT_LOGGED_IN : ClientState {}
        public class C_NO_OPEN_DOCUMENT : ClientState {}

        public readonly static C_NOT_LOGGED_IN NOT_LOGGED_IN;
        public readonly static C_NO_OPEN_DOCUMENT NO_OPEN_DOCUMENT;

    Anyway, even with these issues, the article is worth reading.

  32. BTW, another comparative overview of the C# language is located at:

  33. C# more OO than java? I must admit, when I read that sentence in one of the reactions above, I considered moving to C# for about 20 seconds until I discovered that C# has late binding (= methods are not virtual by default).

    My conclusion:

    - C# eliminates Java's crappy protected, hurray!
    - C# introduces some nice features (see elsewhere)
    - C# introduces some crappy features (see also elsewhere)
    - If I do .Net, my language of choice will be Eiffel, a true OO language

    PS: Can someone explain me how enums are type-safe in C#? The sample code in the article still has an if-test in it, so it doesn't seem type-safe at all to me...
  34. "late binding (= methods are not virtual by default). "

    not virtual by default means it's early bound by default.

    "PS: Can someone explain me how enums are type-safe in C#? The sample code in the article still has an if-test in it, so it doesn't seem type-safe at all to me... "

    Good point. Shouldn't the compiler discover whether the passed parameter is of type Justification?
  35. Good point. Shouldn't the compiler discover whether the passed parameter is of type Justification?

    I presume this check would slow the compiled code a lot, since you must check every time if the current value is a defined value. If you have hundreds of enum values then you will have all that useless comparisons executed every time you set the value of an enum variable.

    However, you still have the System.Enum.IsDefined() method that tells you if a value is defined as a enum constant or not - and you can use that whenever you want.

  36. I don't understand that at all. Enums are checked at compile-time. If I tried to compile a call to an unspecified enum, it would fail. The call to IsDefined is not needed in the article's example.
  37. I see your point now. I was talking about type safety at runtime, not at compile time.

    A type safety at compile time would severely limit the usefulness the Enum types/values across languages. Since .NET code is language independent, this would imply that every usage/assignment of an enum value was checked at compile time regardless of the language, which is not possible.
  38. Adi,

    Of course it's possible. When you compile C#, you're compiling against MSIL libraries. When you compile VB.Net, you're compiling against MSIL libraries. All code in dotnet assemblies is MSIL, and a dotnet-targeting compiler checks against those compiled types. The *source* language is irrelevant
  39. Plus the assembly/namespace would give that particular enum uniqueness.
  40. Hi Jim,

    You are making a very strong assumption here: that using the .NET enums in the generated IL should be already type-safe, so you don't need any runtime spupport for that. But this means that every language supported by .NET must not allow casting an scalar/integral value to an enum. Otherwise you MUST have runtime checks generated by every compiler, in order to maintain enum type-safety at runtime - and this is clearly inefficient.

    While this restriction is easily enforced for languages that you've mentioned (C#, VB), there are serious problems with lanugages that don't have an type-safe enum concept (for example Java, Perl, Python, Smalltalk, Lisp, etc.). In this hypothesis. porting, say, an existing Java module to the .NET platform might not be a trivial thing to do, if we assume that there is a Java.NET language that forces you to use only type-safe enums.

    It make sense that the .NET programming model was designed as non-intrusive as possible, by being a common denominator between all relevant programming languages. Therefore you may not have there all those high-level language concepts that can be found in one language or another.

  41. Egg on my face :o) The official recommendation is that you should use IsDefined to check enums at runtime. I agree that using an enum as a parameter isn't much safer than using any other primitive type, but if the value of your enum affects the behaviour of the method which uses it, you should ReplaceTypeCodeWithPolymorphism ;o)

  42. The call to IsDefined is not needed in the article's example.

    It is. Casting enums is valid in C#, so I can do this

      Justification titleJustification = (Justification) 19029;

    which would break the code if the check was not there.
  43. Semantically there's really not much revolutionarily different between C++, Java and C#. A good developer should easily migrate from Java to C#, just as most of us did from C++ to Java. Hence I don't think this is really a question of "competition" and "turf"; in the end, we will all be writing in the best langauge available, whether it's from Sun or Microsoft.

    However, what caused people to migrate from C++ to Java are points that I do not see there (yet) for C#. I think the major factors are:

    1) open API - those who struggled pre-STL know what I'm talking about. And what Java library can't you get for free on the web?

    2) GC - Since Java, I don't think I remember how to write a destructor anymore! Memory management is a BIG reason why many of us switched

    3) HotSpot (2.0) - I think this is the most pressing, revelent issue right now for Java. C++ is a faster COMPILED language, but Java is a faster RUNTIME language simply because of HotSpot 2.0. Does C# have anything close to this? (This is not a rhetorical question; I haven't read up enough to know, so someone please answer! :-)) I believe runtime performance is one of the most important issues on server-side development (and client-side to an extent). Until C# can come out with a better solution (and I'm willing to give it time, since it took Sun 5 years to get this right!), I think most companies will stick with Java.

  44. Of course the big question is;

    Do you want all your objects to inherit from

    a) java.lang.object
                        / \
                       / \
                 myObject1 myObject2


    b) ms.object
                          / \
                         / \
                    myObject1 myObject2

    Maybe in the future MS will link ms.object into passport.net to make it secure??
  45. Maybe in the future MS will link ms.object into passport.net to make it secure??

    Or have ms.object inherit from outlook.contacts so all of your friends can know what you are developing?