Ok, I'll just put things down as I got through.
You don't disginguish between checked and unchecked exceptions (apperently C# has no checked exceptions).
Compilation for C# seems to require annoyingly longer commands
The finalizer discussion doesn't mention runFinalizersOnExit(), the shutdown hook system, or indeed even show that the author understands the Java garbage collection system. The truth is that it is much uglier than this in Java. Fortunately I have never felt limited by the lack of a good Java deconstructor system.
One might notice from the above code samples that there is slightly more granularity in the C# Reflection API than the Java Reflection API as can be seen by the fact that C# has a ParameterInfo class which contains metadata about the parameters of a Method while Java uses Class objects for that which lose some information such as the name of the parameter
I can imagine this being useful for Microsoft's C# IDE, but otherwise it sounds pretty useless.
float fArray = new float; //valid, but isn't clear that fArray is an object of type float
Cute. I haven't commented on ugly looking C# syntax. Where was that one on sychronized methods...
Oh yeah, this article doesn't seem to differentiate what is possible and what is a good idea.
Fall-throughs are explicitly disallowed because they are a leading cause of hard-to-find bugs in software.
Another amusing one. So they've debilitated 'switch' and you call it a feature? Go figure.
By this point (IO operations) it is indeed quite clear that Microsoft has not done anything to hide the fact they are making a Java clone.
By default Java supports serializing objects to a binary format but does provide a way of overriding the standard serialization process. Objects that plan to override default serializations must implement methods with the following signatures
private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException;
private void writeObject(java.io.ObjectOutputStream stream) throws IOException
Since the above methods are private there is no interface that can be implemented to indicate that a Java class supports custom serialization
Not true. Libraries like JSX and others provide third party serialization to XML, and while I don't know in what version of Java it will come standard, XML object persistance is about to become an official part of the library.
What about doclets? C# doesn't seem to have much of a documentation system at all, and as with most of Java's cool features you don't give any examples of properly commented Java classes.
You refer to the individual restrictions of file vs. namespace based package definition to make Java look more restricted instead of just stating it flat out. You don't mention that you always know what file a certain class came from.
First the needed libraries must be referenced somewhere in the source file which is done via the using keyword in C# and the import keyword in Java. Secondly, there must be a way to tell the compiler where to find the location of the needed library. Specifying the location of libraries that will be used by a Java program is done using the CLASSPATH environment variable or the -classpath compiler option.
What about the classpath for the virtual machine? Jar files? Class Loaders? Are you trying to hide something else about C#?
list of languages retargetted for the Java Virtual Machine
You mean implementations, not retargettings.
The non-deterministic nature of finalization has long been bemoaned by Java developers, it is a welcome change to see that this will not be the case when using C#.
Ah, you didn't ignore the problems some people have with finalization after all.
Wait.... Why am I reading this article anyway? I got work to do. If i'm bored later maybe I'll continue. (note to self: at delegates)