ikvmc rewrite

[wasabii]

Going to start thinking through a rebuild of ikvmc, the CLI tool. Not the compiler itself.

ikvmc right now does a lot of things that seem a bit dated.

a) Resources get embedded as resources.jar: The end result of this is that there is an embedded resource named resources.jar, which appears on the VFS as a file. Which is then loaded by JarFile/ZipFile through URLClassPath. This is a lot of indirection. I think we should begin by embedding these by default as .NET resources. And I then think we should use ikvmres: to return references to them. Avoiding the VFS and the ZipFile libraries completely.

One benefit of resources.jar is that it enables the -compressresources option. In traditional Java, since all resources are distributed as JARs, they are likely benefiting from compression. So, we don't want to expand the file size for libraries where somebody knows that they need compression. So, we should still support -compressresources. But, I think, we should pick a new algo, and we should directly compress the .NET resource. With some metadata somewhere which indicates that it is compressed.

ikvmres is a level of indirection. So there might be performance impacts there. But we're already running this thing through both the VFS and ZipFile. So I can't imagine that that can be much worse. User's have never been able to obtain benefits like mmap() around this in Java, unless they've not been using JARs.

b) Stub inclusion. This is easy to remove, and work is already being done on it for #540.

c) classes.jar: this is an interesting one. IKVM has been a pretty forgiving compiler, since not all collections of Java classes "work". Which is to say, there are often linking errors in libraries or collections of class files that nobody ever notices because nobody uses the actual code. ikvmc tries to generate forgiving assemblies. If it can't compile a .class file, it leaves the class file in a class.jar file, embedded into the assembly. At runtime the class is still available as a resource. I have one suspicion as to what the point of this is. What about .class files in a JAR that aren't INTENDED to be loaded at runtime, which which serve potentially as templates for byte code modification at runtime? For instance, Trampoline code. Maybe the idea here is ikvmc can issue it's warning, but the original .class file ends up included anyways, as a resource, so it can be loaded at runtime but not executed. I think it's best to preserve this. But, it doesn't need to be in classes.jar. It can be an embedded resource like all the other resources.

d) General cleanup. IKVMC is a mess. We should adopt some command line parsing library. We should get rid of all the statics, and perhaps introduce DI. And we need to clean up it's failure modes.

[wasabii]

Assembly manifest resources that represent Java resources are also name mangled. Certain characters are escaped. And they are prefixed with ikvm_. I'm not sure on this. It means things like resources.jar aren't themselves resources. But it also means any .NET resources aren't really visible to Java. But it would be interesting if they could be. Maybe we need to do some sort of back and forth prefixing?

For instance, cli/{AssemblyName}/{ManagledNETResourceName} could be a path that allows lookup of .NET assembly resources.

Or we could lay out the Java resources directly instead of prefixing them, thus merging the namespaces. This would probably be fine, since there's almost certainly no real overlap.... But everything really ends up in / which doesn't make much sense.