IKVM currently handles a magic entry in JAR files named --ikvm-classes--/. Upon seeing this in a ZIP, the classes mentioned in the files are are inserted into the ZIP file as stubs. This is used, as far as I can tell, in one place: resources.jar.
Resources.jar is embedded into the IKVM assembly to hold the original resources. The --ikvm-classes-- entry causes this embedded JAR to appear to hold the .class entries as well. Side by side with the actual resources. So classes can be loaded as resources. This check happens before the VFS link is returned during FindResources.
I think this might predate the VFS, though I'm not completely sure. The VFS itself holds .class stub entries generated on the fly, and FindResources already returns references to those if they are missing from the original resources file.
This seems like two paths to the same thing. But, the magic ZIP entry is harder: it requires a pretty sever local fork of the ZipFile class to insert these magic entries. I think if we remove them, we'd be fine. Lookup would fall back to the VFS and work fine.
Alternatively, we can circumvent the VFS for this completely by returning ikvmres URLs. That's probably the better long term plan. I can't imagine this not working, since embedded resources in a JAR already requires that all user code does not touch these files by hand.
IKVM currently handles a magic entry in JAR files named
--ikvm-classes--/. Upon seeing this in a ZIP, the classes mentioned in the files are are inserted into the ZIP file as stubs. This is used, as far as I can tell, in one place: resources.jar.Resources.jar is embedded into the IKVM assembly to hold the original resources. The --ikvm-classes-- entry causes this embedded JAR to appear to hold the .class entries as well. Side by side with the actual resources. So classes can be loaded as resources. This check happens before the VFS link is returned during FindResources.
I think this might predate the VFS, though I'm not completely sure. The VFS itself holds .class stub entries generated on the fly, and FindResources already returns references to those if they are missing from the original resources file.
This seems like two paths to the same thing. But, the magic ZIP entry is harder: it requires a pretty sever local fork of the ZipFile class to insert these magic entries. I think if we remove them, we'd be fine. Lookup would fall back to the VFS and work fine.
Alternatively, we can circumvent the VFS for this completely by returning ikvmres URLs. That's probably the better long term plan. I can't imagine this not working, since embedded resources in a JAR already requires that all user code does not touch these files by hand.