4 ms·

What do you mean, now ? annotations (though C# calls them "attributes") he means "Java added attributes, which C# had from day 1, but called them "annotations

What do you mean, now ? annotations (though C# calls them "attributes") he means "Java added attributes, which C# had from day 1, but called them "annotations"" C# has many of the same features as Java ... generics Again, C# had this first, and still does it better since the bytecode is aware of them.

adharmad 17y ago
Java being more widely deployed has to worry about source and binary compatibilities between all the supported versions and thus for them, changing the bytecode would have been a painful decision. As opposed to that C# did not have to worry about these things due to their limited deploy base and could freely change the language and/or the VM without worrying about backward compatibility. That does not mean java is a better language than C# - its just that when Sun woke up and started adding features to the language, it was not easy.
- likpok 17y ago
  I belive that was the original reasoning, and thus led to the Java generics behaving a little weirdly. Then other decisions forced them to change the bytecode anyway, but they never fixed generics.
- cakeface 17y ago
  Actually it does mean that C# is a better language now. If you are developing new applications then all the compromises that were made to shoe horn in new features don't matter to you. You just want something that works well and is simple. I think that C# has that on Java in a lot of respects.
  - adharmad 17y ago
    No arguments there. But the rate at which C# is changing, what is stopping Microsoft from adding yet new features and breaking compatibility with previous language/VMs?
    - fatdog789 17y ago
      That's why they have different releases of the .Net run-time.
    - StrawberryFrog 17y ago
      That's why there are generally several different versions of .Net installed side-by side.
- deleted 17y ago
  [deleted]
- StrawberryFrog 17y ago
  I'm not really disagreeing with you - C# is later, has the benefit of Java being in its hindsight. I don't know how Java does it, but .Net installs framework versions side by side (typically under C:\WINDOWS\Microsoft.NET\Framework) so changes to, say V3.0 don't affect apps that run on framework 2.0 at all. Thus breaking backward compatibility for anyone (small or large installed base, doesn't matter) is not an issue when rolling out a new framework version.

adharmad 17y ago

Java being more widely deployed has to worry about source and binary compatibilities between all the supported versions and thus for them, changing the bytecode would have been a painful decision. As opposed to that C# did not have to worry about these things due to their limited deploy base and could freely change the language and/or the VM without worrying about backward compatibility. That does not mean java is a better language than C# - its just that when Sun woke up and started adding features to the language, it was not easy.

likpok 17y ago
I belive that was the original reasoning, and thus led to the Java generics behaving a little weirdly. Then other decisions forced them to change the bytecode anyway, but they never fixed generics.
cakeface 17y ago
Actually it does mean that C# is a better language now. If you are developing new applications then all the compromises that were made to shoe horn in new features don't matter to you. You just want something that works well and is simple. I think that C# has that on Java in a lot of respects.
- adharmad 17y ago
  No arguments there. But the rate at which C# is changing, what is stopping Microsoft from adding yet new features and breaking compatibility with previous language/VMs?
  - fatdog789 17y ago
    That's why they have different releases of the .Net run-time.
  - StrawberryFrog 17y ago
    That's why there are generally several different versions of .Net installed side-by side.
deleted 17y ago
[deleted]
StrawberryFrog 17y ago
I'm not really disagreeing with you - C# is later, has the benefit of Java being in its hindsight. I don't know how Java does it, but .Net installs framework versions side by side (typically under C:\WINDOWS\Microsoft.NET\Framework) so changes to, say V3.0 don't affect apps that run on framework 2.0 at all. Thus breaking backward compatibility for anyone (small or large installed base, doesn't matter) is not an issue when rolling out a new framework version.