In yesterday's item I didn't do a good job of explaining the issue, so today I'll try again and respond to the comments as well.
First, let me start by explaining the current situation. There are two ways to get access to a .NET type:
There are several problems with the current approach:
Stuart commented:
Only lowercasing the system namespace isn't really a generic solution, because any .NET namespace that is the same as a Java class in the java.lang package would cause problems. Treating all names in the java.lang package specially feels like a kludge. Using a special prefix like Brian suggets would be a better idea.
In regards to the second point, in .NET you really need to have an assembly qualified name for a type. Searching all available assemblies isn't feasible.
I responded to Stuart:
One of the problems is that all .NET types are loaded by the bootstrap class loader, so they have to have distinct names.
I just had an another idea. It might be a good idea to encode the assembly qualified name in the package. For example for the System.String type:
assembly.mscorlib.1.0.5000.0.neutral.b77a5c561934e089.System.String
This has the advantage that you can use "import" in most cases (although not for String) to use the short name.
I have to think about it, but I think I like it.
After thinking about it some more, I still really like this idea. It has three huge advantages: 1) There is a natural bi-directional mapping between the class name and the .NET type name, 2) Both netexp and Class.forName can use the same naming scheme and 3) The netexp generated classes aren't needed at runtime (or ikvmc compile time).
In response to my response Stuart commented:
Having a class loader per assembly is tempting, but it doesn't solve the issue of finding the .NET type (you still need to know in what assembly a type lives). This would be solvable by introducing a new API to get a class loader corresponding to an assembly, but that obviously has the downside that it doesn't interoperate very well with existing Java code. For example, the IKVM.NET AWT implementation lives in a .NET assembly (written in C#) and is loaded by GNU Classpath using Class.forName(). This only works if Class.forName() has enough information about the assembly.
Brian Sullivan commented:
I don't care for the occasional lowercasing ideas.
It could be that all .NET classes would begin with NET. from the Java perspective.
NET.System.String NET.Some.Other.Class
import NET.*; // import all of .NET
This makes it clear where the class is defined and clearly separates all of .NET into its own package.
The prefixing is a good idea to get around the System name clash. BTW, import NET.* doesn't hierarchically import all packages, but only the classes in the NET package.
Does anyone have anything against the newly proposed name mangling scheme? Obviously the details need to be worked out (my proposed package name above doesn't actually compile), but what about the general idea?
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