Stuart commented:
On most aspects, you've convinced me. Just a few little comments:
wrt "throws Exception" vs "throws Throwable" - there's no difference. Any Java method can throw any Throwable subclass that isn't an Exception subclass, just as any Java method can throw any RuntimeException subclass. Thus "throws Exception" really does let you throw anything.
Actually, no. Try to compile the following:
class test extends Throwable{ public static void main(String[] args) throws Exception { throw new test(); }}
It doesn't compile. One of the inellegancies of Java's checked exceptions model is that there are two classes that removed the checkedness, both Error and RuntimeException.
Btw, are you arranging that (most? any?) .NET exceptions end up as subclasses of j.l.Exception, or just direct Throwable subclasses?
Throwable, the most important reason is that I don't want to mess with the class hierarchy, if at all possible.
I agree also that remapping things like InputStream is probably too hard. If you have a generic class/interface/method remapping system, though, I can imagine actually experimenting with Collection vs IEnumerable and indexers on List.
One of the goals of XML remapping system, is to enable exactly these types of experiments. It probably isn't flexible enough to do everything you'd want to do, but in the end we'll get there.
When you get IK.VM working on Mono I might even have a try at that myself, since it shouldn't need any deep magic in the VM itself.
I think it'll still be a while before Reflection.Emit in Mono is at the level where it is complete enough.
Oh, and I like the idea of custom attributes to do "throws" expressions on glue code. I wonder if we could persuade the Mono people to get mcs to actually honor the "throws" attributes - ie, compile C# code with Java's 'checked exceptions' semantics. That would be pretty cool :)
It would be cool, but I don't really like checked exceptions. After programming in Java (almost exclusively) for about five years, I finally decided that the cons outnumber the pros. The idea is compelling, but in practice there are too many problems, but I don't really want to start that war, as it has been waged many times already
BTW, I just changed the idiv, ldiv, irem & lrem implementations to explicity check for -1, and for a lame little test I wrote, performance seems to be OK (same as JDK 1.1 and slightly faster than JDK 1.4, HotSpot doesn't like microbenchmarks ).
VS.NET treated "if (false)" on line 1732 of vm.cs as creating unreachable code. I changed it to "if (false.Equals(true))" so that it didn't treat it as a compiletime constant.
And the default compilation options disallowed unsafe code, so I had to change that in order for BigEndianBinaryReader.cs to compile.
It doesn't (seem to) honor CLASSPATH, at least when run from a command prompt. So you have to cd to the directory that contains your classes, and if they're in more than one directory or in a zip file you seem to be SOL right now. Maybe there's a classpath commandline argument, but if so it doesn't tell you so when you run it with no args. Fortunately, for what I wanted to try, all my sources are in one place.
Now the showstopper that I haven't been able to figure out how to get past. As far as I can see the download doesn't include *any* of the GNU Classpath libraries, which means that (as far as I can see) it can't run anything at all. I'm guessing that this is just a simple omission from the zip - is that right?
Interestingly, my take on checked exceptions (after programming in Java for almost as long as you have) is the opposite of yours - I still feel that the omission of checked exceptions is the biggest single problem with C# and the CLR. I'm not going to get into the war either, it's just interesting that with the same length of Java experience (although yours clearly goes much *deeper* than mine if you can write a VM) we've arrived at opposite conclusions.
What would have been really nice, IMHO, would have been for C# to support some kind of *optional* checked exceptions. What I mean by that is something like this:
void foo() { ... } (C#) ==> (Java) void foo() throws Throwable { ... }
void foo() throws FooException { ... } ==> void foo() throws FooException { ... }
void foo() throws void { ... } ==> void foo() { ... }
That way, as long as they were careful about declaring exceptions on all public standard library functions, programmers who like checked exceptions could use them, and programmers who don't wouldn't have to.
If necessary, they could also add a special declaration that would turn off checking exceptions in the body of your method, so that it would be possible to call code that doesn't check exceptions, and give a meaningful throws clause, but not have to put an exception handler in to catch everything else.
Remember Me
I apologize for the lameness of this, but the comment spam was driving me nuts. In order to be able to post a comment, you need to answer a simple question. Hopefully this question is easy enough not to annoy serious commenters, but hard enough to keep the spammers away.
Anti-Spam Question: What method on java.lang.System returns an object's original hashcode (i.e. the one that would be returned by java.lang.Object.hashCode() if it wasn't overridden)? (case is significant)
Powered by: newtelligence dasBlog 2.3.12105.0
© Copyright 2021, Jeroen Frijters
E-mail