>>>>> "Geir" == Geir Magnusson <[EMAIL PROTECTED]> writes:
Geir> 4) RMI stuff On irc Geir said that he meant "JNI" here. Basically what this means, I think, is that Classpath has an implementation of "jni.h", but the VM has to provide certain typedefs, e.g., "jint". Geir> 2) Are there things that the GNU Classpath model is missing due to Geir> the version of the API it's implementing? (I.e. they don't realize Geir> they need it yet...) Yeah, there are some needed additions for 1.5. E.g., annotations require new reflection info, and in the Classpath model this comes from the VM layer. This will all show up eventually, perhaps on the generics branch. Geir> 3) I was uncomfortable with extending java.lang. I understand the Geir> argument - that as they are package private, the language can be Geir> depended upon to keep them safe from user code using them rather Geir> than some security infrastructure. However, isn't this a bit Geir> dangerous in terms of standard java.lang changes colliding? I don't think there is a killer failure mode. First, note that it is both the language and the VM that implement this protection. This is crucial, as otherwise someone could easily circumvent the protection at runtime. Second, suppose Sun adds java.lang.VMObject to their public API. What then? * A program written against Sun's new release that uses this feature will not work against our old release. But that is already the case -- a program using a new API won't work against an older Classpath that doesn't implement it. The choice of name doesn't matter. * A program written against Sun's new release that uses this feature also won't compile against our old release. But this won't work anyway either. * To implement this new feature we would have to rename our VMObject and thus change the VM interface. But that is also not a huge problem. The VM interface can't remain fixed in general, because sometimes new features (see the 1.5 example) require additions to it. (This does mean some churn for VM implementors, and it is inconvenient. But it only breaks the VM, not anything else.) * Finally, there's no way to compile a program against Classpath that uses the Classpath VMObject, due to the access protection. So failures "the other way" aren't possible. Geir> I'd like to drive to a standard interface that we can all agree on, Geir> and hopefully GNU Classpath will support it. Experience has shown that the Classpath approach is pretty flexible. A wide range of VMs already use it. Also we're pretty open to specific needed changes. Tom
